Plan B

More on the "unteachability" of the java language

Elliotte Rusty Harold writes about yet another fancy feature proposed for Java SE 7.  For the record, here's my comment posted there: 

I'm glad you brought up the topic of the increasing "unteachability" of Java. If you want to do the language a favor, next time, please laugh off (to put it lightly) anyone who tries to profess fancy versions of closures, a new property syntax or other such forms of geek entertainment. The Java language is not some kind of a guinea pig on which you try out various experiments and, if they fail, throw it away and just pick up a new specimen. If they want to experiment with the language, ask them to use the kitchen sink. But please let them not come up with complicated and absurd proposals just to kill time.

I'd like to reaffirm that I'm not against well thought out, beneficial features being added to the language without complicating its type system or compromising on its ease of learning. (Talk to Jonathan Schwartz if you think its unimportant to reduce barriers to entry or make it easier for new developers to pick up your language and tools.) You do not have to design for fools, but your needn't make it a playground for theorists either.

P.S: Cay Horstmann in his post makes a fleeting mention of how his students lapped up CICE immediately, but took a lot more time (and required guidance) to comprehend BGGA. Need I say more?

Posted at 11:36AM Apr 20, 2007 by Bharath Ravikumar in Sun  | 

Google adds Java powered office product

Tonic systems (some name, huh?) is the latest addition to Google's repertoire of online productivity products. What's more, its Java based. While ThinkFree was always around on the text editing front, Power Point equivalents weren't getting enough press, imo. But hey, Tonic or ThinkFree may be some of the first Java based online products, but if you consider webstarted programs, the honor of getting there first probably goes to Gosling's Huckster. :-) (Really, check it out. You won't be disappointed.)
And you thought Java as a web based rich client platform was long dead...

Posted at 07:15AM Apr 18, 2007 by Bharath Ravikumar in Java  | 

Ruby on rails bites the dust

Interesting post on how twitter has found it hard to scale its ruby on rails infrastructure. While Java EE  is often called bulky (true of EJB 2.x), clumsy(blame it on struts) and such names, ruby and its cousins are often lauded as the silver bullet for all web development problems. Though I've found ruby on rails awe inspiring (first saw it demo'd by Charles Nutter) for rapid prototyping and building lightweight applications, I've always doubted its ability to scale. Contrast twitter's case with the scale that eBay has achieved using servlets, custom connection pools etc., and you'll see why Java is leagues ahead in building large-scale server applications. And we haven't even started talking about the wide range of F/OSS middleware and tools available in the Java ecosystem.

Posted at 11:01AM Apr 17, 2007 by Bharath Ravikumar in Java  |  Comments[4]

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]