|
I have yet to hear an argument for not including closures from someone who actually understands what closures are.
Now come on, you can't argue that people that do not want closures are to stupid to understand them. So they must be to stupid to use Ruby or Groovy!?
The problem is not that closures are not a good feature, but that Java gets overloaded with more and more esoteric features that are not needed but greatly extend complexity, bring very little effective gain and do not fit in a very mature language.
C++ has very few features that are stupid (in my opinion) but the problem is that it is too overloaded with features to express the same problem in a different way to be really handy.
And you can bet that no simple and elegant solution would be chosen for closures in Java (as the one from Mr Bloch). Look what they specified for Generics, just to provide type-safe containers. Closures will add another equally complex chapter to Java, just look at the proposal of Mr. Gafter. And no end is in sight; operator overloading per se is no stupid feature too as is aspect oriented programming and so on. You cannot include every smart feature from some other language because this results in a confusing mess. Java is no elegant but has been a handy and effective language. This was the reason many developers chose Java. (Ruby or Python were already available at this time). I think it is better to have several programming languages, each with some distinct smart features than to have another C++: If you want closures and Java, use Groovy. Why force everyone to use closures just because it is the idiom of the season?
In my view closures are mainly an elegant (and currently hip) idiom for iteration but you cannot do anything with them that can't be already done. Yes, they can reduce boilerplate but if examples are given, exception handling should be included! Here the devil is in the detail. Thats different to Ruby or Groovy where you need not to do exception handling. |
java.net RSS Feeds
