I started out nervous with the idea of adding
closures
to Java, and I think I’ve slid firmly into the “contra” camp. One reason is
that it seems increasingly a bad idea to add anything to the Java
language.
On a related subject, my brief sojourn in Ruby-land has changed my thinking
about closures entirely.
Java and Closures
A good place to start is Bharath’s
BGGA closures: The end of many Java careers.
Clearly he’s a contra too, but he links to both sides’ arguments.
My argument is simple: Java worked so well because it hit the
80/20 point; for my
money one of the loudest, cleanest 80/20 technology
victories ever. Subsequent attempts to fill in the 20% were, well,
mostly harmless. Until generics, which are a disaster; they have made Java
harder to learn and to understand, and you can’t avoid them.
So I’m really scared about trying to chip away any further at whatever’s
left of the 20%. Also, I look at the motivating examples for closures and I
think that the conventional alternatives aren’t that bad. Also, I look at the
proposed code and I think that on balance it’ll make Java harder to read.
Also, as Bharath points out, if you really need closures and and
functional-programming goo and suchlike, there are at least two excellent
Java-platform languages that have elegant, well-tested designs: Scala and
JRuby.
But you know, I could be wrong. Maybe there’s a way to build closures into
the Java language in a way that’ll add power smoothly with no real downside.
If that’s true, we need to discover it and prove it, and the JCP isn’t about
discovering things; it’s about the worst possible place to approach this
problem. Now that Java is Open-Source, anyone can go cook up whatever loony
closure facility they want, and if it’s good enough, people will start using
it whether the binary build has “Java” stamped on the outside or not, and then
start shouting that it should be in the standard distro, and only
then should the JCP consider going near this tar-pit.
My favorite place to start improving Java wouldn’t be with the language at
all, it’d be the
Multi-Language
VM project. The motivating use-cases for that aren’t theoretical in the
slightest, they have names and addresses and are screaming for love.
Ruby and Closures
Ruby calls ’em “blocks” and you basically can’t write any code
without ’em. When you first see how they’re used, you think “Hey, that’s a
nice clean way to do iteration”. Then when you want to write one of those
functions, you dig in and find out about yield, and you nod your
head “of course”.
They have to be closures because they look like (and are) chunks of code
embedded in your classes and methods, which can naturally use those
classes’ and methods’ variables. So there’s nothing in the slightest strange
or surprising.
Later on, when you get a little deeper into Ruby, you find out about
&block arguments and procs and lambdas, but by that time you’ve
internalized the notion that a few lines of code have an independent life even
if they don’t have a name, so the mental effort in figuring it all out is about
zero.
But even in Ruby, to my eyes the most readable of languages, code that uses
procs and lambdas is often hard to read. (Code that uses ordinary blocks
is trivial to read, the closure-ness is implicit and invisible).
And at the end of the day, the number of times an application programmer is
going to really need a proc or a lambda, to the extent that it’s a win
to suck up the readability cost, probably isn’t that high.
Yes, it happens; I’ve done it myself. But as I said, not often.
Conclusion
Sorry, I don’t have one. Ruby proves that it’s possible to get closures
right and make them accessible to grunt programmers. But if they’re going
into Java, they need to earn their way and be field-tested in the open-source
ecosystem first.