In my last post I drew a diagram showing how I viewed the main proposals in terms of complexity. It has since been pointed out to me that I didn't clearly identify whether the JCA part of FCM was included or not. So I'll redraw the diagram and express my opinon.
The three key proposals in the 'closure' space are - BGGA from Neal Gafter et al, CICE from Josh Bloch et al, and FCM from Stefan and myself. FCM has an optional extension called JCA which adds control abstraction [1].
Control abstraction [1] is that part of the closures language change which allows a user to write an API method which acts, via a static import, as though it is a built in keyword. This is an incredibly powerful facility in a programming language. However, reading many forums, this is a facility that many Java developers also find concerning.
Given this, I'll redraw the diagram from yesterday:
--------------------------------------------------------------------------
Simpler More complex
--------------------------------------------------------------------------
No change Better inner Method-based Method-based Full-featured
classes closures closures and closures with
control abst. control abst.
--------------------------------------------------------------------------
| No control abstraction [1] | Control abstraction [1] |
--------------------------------------------------------------------------
No change CICE* FCM FCM+JCA BGGA
--------------------------------------------------------------------------
* It should also be noted that Josh Bloch has written the ARM proposal for resource management that tackles a specific control abstraction [1] use case.
So, what is my preference?
Firstly, I believe that Java should be enhanced with FCM-style closures (where the 'return' keyword returns to the invoker of the closure).
Secondly, I believe that control abstraction [1] would be a very powerful and expressive language enhancement. Personally, I would like to see Java include control abstraction, but I am very aware that it is a real concern for others in the community. I am also not yet fully confident of the risks involved by rushing into control abstraction [1].
Thus, my preferred option is FCM+JCA for Java 7. However I would also accept a potentially lower risk option of including just the FCM-style solution in Java 7 and adding JCA-style control abstraction [1] in Java 8.
Feel free to add your preference to the comments.
[1] Update: Neal Gafter has indicated that I am using conflicting terminology wrt 'control abstraction'. Neal uses the term 'control abstraction' to refer to any closure which can abstract over an arbitrary block of code including interacting with break, continue and return. Whereas, in this blog post I have been referring to control abstraction as adding API based keywords (described in paragraph 3), which Neal refers to as the 'control invocation syntax'. Apologies for any confusion
FCM+JCA sounds like a reasonable choice. Although I haven't really had the chance to compare the JCA to BGGA control abstraction. But I do like FCM method literals though, which hopefully will be extended to support other kind of currying. I was originally on the fence with regard to adding closure to Java until I saw the beauty, elegance, and power of control abstraction as offered by the BGGA proposal, then I became a convert. So to me any proposal that falls short on the control abstraction support is a non starter, and IMO is just a short term fix, equivalent of putting lipstick on the inner class pig. It's just not worth the hassle. I would recommend everyone to check out the control abstraction use cases that you posted on your blog. I found them very useful in showcasing the great potential of control abstractions.
ReplyDelete... As someone once said: Go Big or Go Home!!.
ReplyDeleteI would vote for CICE + FCM. Control Abstraction would be good for me and you, since we are willing to learn, but hard to swallow for all those corporate developers. They learned Java in uni and aren't interested to go back to school to learn a hole new type of Java programming, which true closures represents.
ReplyDeleteCheers,
Mikael
Thanks for the clarifications of the current status, by the way. And I stick to thinking that control abstraction is pretty vital. It's not for clever language people. It's so everyday people can do everyday things more easily and correctly. (And if other FCM or BGGA stuff gets in, I really don't see a need for CICE, unless we like Perl-style TIMTOWTDI.)
ReplyDeleteAnd by "control abstraction", I also meant BGGA's "control invocation syntax". (But it's not a complete misuse from FCM/JCA perspective, since that's the only control abstraction you get, if I understand the clarification correctly.)
ReplyDeleteMikael, you keep saying that adding control invocation syntax will make the language harder to learn. In fact I would argue it's the opposite. It's a step toward simplifying the language, particularly the API usage aspect of it. I think when talk this supposed added complexity you are confusing those two aspects: writing an API and using it. Writing API is always a trickier problem, and the control invocation syntax does not really make this any more complex. As far as simplifying usage is concerned I would only refer the JSR draft where it lists 5 scenarios where we can expect improvements. Again, with version 5, and generics we saw the Java language trending toward more complexity. I see the invocation syntax as a push in the opposite direction, toward conciseness, expressiveness, and simplification.
ReplyDeleteI vote for CICE and strongly reject BGGA or FCM. Not that they are bad proposals but they add a level of complexity that it is simply not worth it. I think a very widely used language like Java is the totally wrong place for such experiments. Why use a proven tool that serves very well to so many people as a test bed for freaky language constructs. I think CICE easily provides all that is commonly needed from closures. Especially Mr Gafter should know better how easy one can "overdesign" a language, as he is part of the C++ language board I read. It is very stupid to ruin Java (language) by throwing in intelligent and stupid features just to please a percent or so very vocal developers. Especially when you consider that most of them will nevertheless quickly move to the next cool scripting language that comes along. Where comes this missionary eagerness from, to force a vast majority to follow the vogues of a small minority? Especially as no boundaries are in sight: Today the most complex of all thinkable closure implementations, oh and lets add control abstraction, properties, operator overloading then tomorrow aspects, continuations and so on. Stop it!
ReplyDeleteUse Groovy, Scala, Nice, port C# to the Java (platform) or create a new "Java++" language.
That would be a much cleaner and also a very democratic solution: If the proponents of endless feature addition are correct, than "Java++" will replace Java just as Java replaced C++ in many fields of application development.
Perhaps Java, Java++, Groovy and some others can fruitfully coexist, giving every kind of developer what he needs to get his work done and still have fun.