So, to see how far the closures rabbit hole goes I decided to make a list of all the languages in the top ten on the Tiobe index which have no closures support or no confirmed closures support in an upcoming version.
The initial list consists of these languages:
Oops I forgot about C++0x and it looks like it has closures support, remember I said confirmed closures support in an upcoming version.
Oh and lets not forget PHP 5.3 and the closures rfc that's already in HEAD.
Therefore the refined list looks as follows:
Now what about C. It's true that ANSI C forbids nested functions but as it turns out GCC has a few extensions which allow you to do closures. It's also worth considering if C belongs here since it's modern use case and characteristics tends to place it in a different category to the rest of the languages on the index. On those grounds I'm going to apply Occam's razor and remove C from the list.
The final list looks as follows:
This means that after the next iteration of language versions, Java will lack in capabilities compared to competing languages. Now I can carry on coding without closures - albeit somewhat unhappily. But bear in mind that Java increasingly has to compete with other languages. And if Java is perceived to be obsolete it's going to be a harder sell in the enterprise.
Now I know that time is running out for finalizing Java 7.0 but for goodness sakes Sun you really need to do something.
Now purely from my point of view I wouldn't be upset with either of the following:
- Pushing out the Java 7.0 time line in order to add these language features.
- Make another language such as Groovy a required part of the Java 7.0 spec.