Plan B

BGGA closures and the principle of least surprise

Due to paucity of time (and that's an understatement),  I wasn't able to post an elaborate rebuttal to comments on the previous post on closures. But Prof.Cay Horstmann's post on java.net has stirred up enough interest to warrant another post. I concur with one of the comments (that of Mikael Grev) in the blog.
While we all completely agree that Closures are important, one mustn't forget that code is written and (more importantly) read by developers. Humans, that is. And for newbies (and unsurprisingly, for java old-timers too), the principle of least surprise applies. Take a small survey of university students (even those that have started with C) and ask them if (and if yes, why) they prefer Java for application programming - and they'll tell you its the easier learning curve and intuition. When you read a certain segment of Java code, you can make an intelligent guess (knowing just the very basics) as to what the developer was trying to achieve. Its not the "generality" of the language that makes it ubiquitous - can java do a good job of playing various audio formats, or detect your USB drive and launch an application in response to it in a cross platform fashion? No. I hate to admit this, but Java remains dominant on the server side (and on mobile devices perhaps). It still has a long way to go (=>there're plenty of growth opportunities, which is good) on the desktop front. Which means it isn't yet a jack of all trades. A the ease of learning it remains one of its key strengths.

Speaking of readability and intuitive languages, there're very few "gotchas" in the JLS. (As much as one is tempted to compare the BGGA spec to the JLS, the latter is a delight to read.) And you won't hear Java developers talking about how their job interview involved "tell me what this piece of code does" kind of questions or other puzzlers. The fact that after more than a decade, there's just one seminal Java puzzlers book is a tribute to the language's simplicity. While developers are still grappling with changes to the type system brought about by generics (despite the excellent non-reified approach adopted). As one commenter pointed out, there're now entire sites and books devoted to generics. At such a point, how do you explain to a newbie (and we needn't debate how important it is to get more developers to take up Java) that for the sake of completion transparency, you need a new type Unreachable that's a subtype of all types, and of which null is a subtype? And I'll let you make a judgment on which of the following two pieces of unrelated code, each having a different level of conciseness and clarity, appears closer to the existing Java syntax:

{int=>int} plus2 = {int x => x+2};

and  

new Thread(Runnable(){ foo(); }).start();

For the former, should the developer be asked to go lookup the BNF in the spec or understand how closure conversion works, to get a better understanding? On similar lines, as useful as it'd be to similarly have first class XML support or embedded SQL in Java, it brings with it clutter and code-obscurity. When you expect to read Java code, you should get to see just that - and not ruby style blocks and or contortions like the absence of semicolon in the last line of a block. Also, I disagree with the argument that only API developers need to be aware of Closures with the rest of the world blissfully using it. As Josh Bloch pointed out, if you code extensively, you're more likely than not an API designer. So there's hardly any escaping the cognitive load of syntax like that of BGGA function types. In conclusion,  and IMHO, as a user of the language - I'm no language expert - I'd prefer readability of code and preserving of the existing type system at the cost of feature-richness. It's great to have control abstraction API, expressiveness and conciseness, but it's better achieved in a way that doesn't complicate the type system. I'd rather see the the CICE with ARM blocks or the FCM proposal enhanced to address this need instead of a sledge-hammer panacea proposal. The Java community surely needs Clourses and has asked for it in several polls, but let's make no convenient assumptions about what form of closures it seeks.

P.S: If you found it painful to go through this "rich and expressive" post due to excess of hyphens, brackets, commas at unexpected points, I'd compliment myself for having highlighted the importance of readability (of prose and of code).

P.P.S: Next post : when time permits.

Update: Stefan Schulz notes that there is indeed a proposal to extend FCM to accommodate control abstraction API.

Posted at 01:33PM Apr 14, 2007 by Bharath Ravikumar in Java  |  Comments[1]