It's nice to be right. Not to toot my own horn too much, but today Sun announced a proposal for closures in Java, in the Dolphin (JDK 7) release. I uncovered the hints of this in the JSE6 documentation about a week ago.
I suppose that isn't a really stunning scoop. The writing was on the wall anyhow. Almost every other modern language either always had support for functional programming, or already had plans to support it. Therefore it could only be a matter of time before smart people like Gilad convinced the pointy haired bosses to listen to reason. I have to agree with him when he say's "what took so long".
I haven't had a chance to review the whole spec yet, but if you'd prefer it in non-HTML format, Neal Gafter, one of the other co-authors has a copy (Updates: 0.1, 0.2).
Anyhow, this is great news, even if you use other languages like Ruby. Making functional programming a standard language feature, as ubiquitous (or more so) as the class, can only make it easier for all developers to communicate.
The only downer is that JDK 7 is a long way off still, so there will be a bit of a wait.
Posts
8 comments:
Another tiny step to Lisp. Cool!
I have one year of ML behind me. That one year made me comfortable with closures.
That other languages have closures does not intself convince me that Java needs closures. What will closures do for you? What will they facilitate doing?
I personally do not miss them from ML, nor do I need them in Java.
[closures] "can only make it easier for all developers to communicate."
I believe the contrary. Adding closures will muddle conversations amongst java developers. Another language feature that only a subset of developers will absorb.
That's an interesting point of view. My point was more about all developers, not just Java developers. Or more specifically a Ruby developer talking to a Java developer.
It does touch on a very interesting topic however, and that is the developer caste system. I don't believe that right now there's a "Blub" language where all developers are dumb, and there's no one smart, but there are differences in distribution's and averages.
It seems that if that subset which never absorbs is holding back the upper echelon developers, many or most will simply defect. If that means going to different languages then you have a bigger problem developing, because now you have this immense gap for beginning developers to cross from "Blub" to better.
It's not that hard to teach a developer a new trick in their existing tools, but it's often nearly impossible to convince them to try another tool. The good developers will have less resistance, but it will still be much higher than it needed to be.
So either we end up with this fairly rigid caste structure, or we all settle for "Blub". Or.. we evolve our languages upwards and keep recreating Blub when our languages get too complicated for those developers.
Actually that third option's not so great either... hmmm. But it seems to reflect history fairly well, and has kind of worked, though painfully slowly.
Closurs seem to be an excuse for not designing your code properly.
I don't believe that it actually lets you do anything that you cannot do now.
It's an interesting tactic to imply that all good programmers will agree with you and that all those who don't are bad programmers.
I have only come across this issue recently and have not missed closures despite using Java in commercial applications for 8 years. I can see how it may be easier to do some things using closures but that does not mean it is needed in the Java language.
If closures are the answer, what is the question? It seems we forgotten to ask ourselves "why?" And "should we?" instead of "can we?"
I think the proposal is actually a bit messy and hides some of the detail of the closure design from the casual code reader. I would like to see a way of defining the closure that is more like the current method specification.
This seems to have come from developers who like using scripting languages wanting to polute the Java language with their favourite features from those languages. The idea that scripting languages are suitable for anything but the simplest application is a bit strange to me.
The above comments against closures appear utterly silly to me. Closures are easy to understand and apply; they're just difficult to implement cleanly. They add tremendous expressive power when used properly.
The idea that we should leave out a powerful language feature because it can be done "another way" is silly --- that's like saying, you can do everything you can do with object-oriented programming using procedural programming. Yes, but so what? You can do everything in assembly language, too.
Computer languages should make it simpler and easier to express programming constructs, to get us farther along the path of making software more quickly and compactly. Ruby is famously terse, yet also readable. Java is still rather verbose, but adding closures is a step in the right direction.
What we really need in the long term is the ability to quickly build DSLs ... that's where I think we're going in the far future. But for now, I'll take closures...
Still confused as to what advantage they have over the current use of annonymous inner classes.
Show me five good examples of how closures will make my life easier as a programmer. Seems like a 'neat' idea, but maybe unnecessary and just make for a steeper learning curve in order to understand software libraries and how to use them.
Regardless, It seems there is a need for 'closure' and I wish this topic would die by it being denied or properly implemented.
I think closures may open up sloppy programming practices as variable boundaries are opened up to inner functions... it is as dangerous as :
final Answer[] answerHolder = new Answer[1];
new Algorithm() {
public void run() {
...
...
answerHolder[h] = new Answer();
}
}.run();
very dangerous as multiple threads modify the holder variable. closures makes this construct even easier. you no longer need a container.
Think on this though. Look at the example you've written, then write the same thing with a container.
Then ponder, in which of these two cases is the error more obvious? If the error is more obvious, it will make it possible for less skilled developers to spot the error more easily.
If you're contention is that the more difficult to write container is raising the bar for entry to a club where some developers don't belong, you should also realize it's raising the bar for exit, meaning it's harder to get it right once you're in the door.
Post a Comment