In the comments section of my last post, user sanity makes the following astute observation, re: my closing remark about Java being a Turing complete language:
Well, pretty-much every programming language is Turing complete, so by that argument, why bother adding any feature to any language?
To which I reply: "Bravo!" and "Well said." I'll even take it one step further: anything that can be done in a high-level programming language can be done in assembler language, or even machine code. I know from hard experience, having implemented an encapsulation/data-hiding scheme using IBM mainframe assembler language, and having patched code using the raw machine opcodes in the same environment. Ah, the good old days!
So I'll go back to programming in assembler language, and the rest of you can either join me or take a well-earned break. Thanks for playing.
All right -- as much fun as the reductio ad absurdum game is, all it does is reduce the argument to an absurdity. It doesn't really point to a constructive resolution. Although, in this case, it does raise the question (note: notice I did not say, "begs the question," which is a solecism that I will reserve for another post) of the degree to which the effort involved in constructing a higher-level language offsets the effort involved in writing code in a low-level language.
I think we can all agree that programming in C or C++ is more pleasant and more efficient in terms of our time than programming in assembler language. You give up some flexibility (e.g., the ability to stuff a specific value in a specific register, direct access to all non-protected memory), but you gain recursion, stack management, register coloring -- all that good stuff.
Move up to Java, or Objective-C (version 2.0; coming soon!) and you get the added relief of automatic memory management (allocation and garbage collection). With Java and its ilk, you also get checked exceptions, which you may or may not appreciate.
Move up to Ruby (JRuby), or Python (Jython), or LISP, and you get dynamic typing and language/runtime-level support for first-class functions/blocks/closures.
So switching between these flavors of Turing-completeness makes sense. If you need close-to-the-metal performance with some measure of portability, use C. If you need rapid prototyping, use Ruby or Python. If you need to justify spending $300+ on IntelliJ IDEA, use Java. (Sorry, couldn't resist).
My point (and I do have one) is that the difference between Turing-complete-Java and Turing-complete-Java-now-with-closures! is just not worth the effort it looks like adding this nice-but-not-essential feature to the language will require.
Closures in Java will muddy an already-dense syntax even further. They will require more code butchery and internal gymnastics on behalf of the compiler. They will be devilishly hard to add in a way that makes sense, given Java's baked-in typing restrictions and flow control. And, in the end, they're going to satisfy the demands of a vocal minority. The masses will still take the path of least resistance, and will probably avoid closures like the plague. And those of us who make a point of being aware of non-Java programming idioms will appreciate the differences between the many available languages, and will continue to strive to use the best tool for the job at hand.
2 comments:
The hard bit seems to be in deciding how to do it, not actually implementing it. We can have endless discussions on what 'return' should mean inside a closure, etc.
The BGGA and FCM proposals both fit in Java's current typing system, they don't require anything grossly new, except a 'throws' kind of generic parameter, but even that might not survive discussion.
The non-vocal majority that you speak of would use closures in Ruby or Lisp, no problem, so what reason is there that they would never use closures in Java? Simply that it's new?
Excellent questions. I think people who are comfortable with closures in Ruby or Lisp will use them if they become available in Java, but they will not be impressed with how cumbersome they are. I would characterize that group as bein a "non-vocal minority", and I would include myself in that number. My life will go on whether or not closures are added to Java.
But I expect that group to be small compared to the number of Java programmers who know only Java, and who therefore have not been exposed to the idea of closures until now. I think closures will be difficult to grok for those who first experience them in Java; that's the group that I expect to be the "non-vocal majority" that you refer to.
Post a Comment