These days everyone seems to be writing about some of the "new" languages on top of the JVM - or podcasting that's absolutely awesome what A does with groovy or B does with Scala. So I decided to take a look at these "new" languages, too.
In the last weeks I read a lot about Scala, worked through the examples and started to play a little by myself. Basically I like the language very much, mainly because it blends the best of Java with functional programming - and some memories from my college Scheme classes are coming back.
However there are a few things I don't like. Type inference, at least how it is implemented in Scala, is one of it. I can perfectly understand that
Map<String,List<Map<String,Long>>> map =
new HashMap<String,List<Map<String,Long>>>();
is awful. In Scala you use type inference and write
val map = new HashMap[String,List[[Map[String,Long]]]();
which is much shorter. However this has one drawback: map is inferenced as being of type HashMap and NOT Map. This violates one of the basic programming principles I learned and am defending passionately: Program against interfaces and NOT against concrete classes.
(BTW: Neil Gafter made a proposal how to combine type inference with programming against interfaces: http://gafter.blogspot.com/2007/07/constructor-type-inference.html)
On a side node, did you notice how a immutable value is declared in Scale? With val. Guess how a mutable variable is declared? Right, with var. How stupid is that? Just one character difference between two fundamentally different types of variables? The difference is quite important as the first type allows for the purely functional share nothing approach, which makes concurrent programming so much easier, while var stands for the "traditional" approach of shared variables which must potentially be protected against concurrent access from different threads.
Subscribe to:
Post Comments (Atom)
2 comments:
Your type inference example doesn't violate that principle. That you think it might demonstrates that you don't really understand the reasons behind the principle. You could probably learn a lot by trying to construct a situation where this aspect of type inference leads to a problem. Both about what the actual problems are that can come from violating that principle, and about why type inference can't cause them.
Hi Greg,
I have to admit that I haven't much experience with type inference and therefore might misunderstand some things about it.
Also I understand (or at least think so), that type inference cannot 'escape' from methods via the method signature.
Also HashMap was probably a bad example, as it AFAIK doesn't expose any public methods different as Map.
But can you explain to me, why this example doesn't violate the principle?
var coll = new LinkedList[String];
coll.getFirst();
Of course, this violation is very 'local' and change cost, if I want to exchange the concrete implementation, is probably low. But it is still a violation.
Post a Comment