Saturday, 13 June 2009

Groovy and Language Design

I was a little surprised to read Elliotte Rusty Harold’s recent comments on Groovy, calling it the ‘Edsel of programming languages’.  It’s an amusing comment, but pejorative and challenging enough to motivate a response. 

The past few years have been interesting and fruitful from a programming language perspective: Ruby, Groovy, Scala, F#, and the evolution of C# are those which spring to mind.

Many of these developments have been about finding a way to push functional-programming idioms (lambda expressions, currying) or dynamic language features (type inference, closures) into well-established imperative languages like C# and Java. I think the results have been mixed: imperative languages are essentially assignment-based, not expression-based, so you end up with a hybrid which, from a language syntax point of view, is neither one thing nor another and arguably suffers as a result.  But it’s difficult to argue that these efforts don’t deliver real positive utility.

An example of this is how C# has evolved support for lambda expressions, expression trees and implicit typing. First (in v1) we had simple delegates, then (in v2) we were able to drop the delegate syntax and declare anonymous methods inline, and finally (in v3) we can use a compact lambda syntax which looks a bit like ML. But because all this has been added to what remains fundamentally a statically-typed, compiled language, you still have to put up with all the nasty explicit declaration of types (and type parameters) on the l.h.s. of every assignment, just to keep the compiler happy.  So the final step was to introduce the var keyword and bring implicit typing into the language. Not dynamic typing, just implicit typing: we get to trim away the ugly declarations but keep the compile-time type safety. 

The confluence of these developments enabled things like LINQ: blending a query sublanguage into the primary language syntax. The best exposition of this I have read is by Ian Griffiths, in his excellent post on expression trees: see the example code just over half-way down, under the section ‘Expression Trees, LINQ, Deferred Queries, and Databases’. It’s all so superficially appealing – just look at the motivating use-case in Ian’s post. But still there’s a small, nagging voice in my head saying this isn’t quite right...

It feels as if we’re trying to pretend there’s no boundary (or intermediary) between the program text and the resource we’re querying. This is similar to the way we tried to pretend that remote procedure calls were really local calls in the old (and now largely discredited) distributed programming models such as CORBA and DCOM. Recall the fallacies of distributed computing and the tenets of SOA: these are essentially warnings about the dangers of implicit or flawed assumptions.  Although the tenets have been challenged (and were threatened with retirement) most of what they said is timelessly valid.  In the context of LINQ, I think my nagging voice is pointing to the boundary-crossing in a LINQ query and muttering “private implementation technique, not primitive construct”.

What’s this got to do with my starting point for this piece, which was Harold’s ‘Edsel’ jibe?  I suppose it’s this: whatever we may feel about the virtue of purity in language design, in the end productivity and usability are the bigger drivers, and with skill it is possible to combine language features without creating a monster.

Technorati Tags: ,,

Sun, Java and Innovation - reflections

My previous post on the Sun acquisition was a rather naive and misty-eyed piece of sentimental warbling. The truth is that Jonathan Schwartz’s vision hasn’t delivered quickly enough for the market: the share-price has suffered and Oracle has picked up something of a bargain. Pity, because (perhaps looking through those rose-tinted spectacles again) I rather like Schwartz’s ideas for growing the business, essentially giving away the technology and then ‘monetizing adoption’.  But it’s not happened nearly fast enough and one wonders whether it ever could. 

An editorial in SD Times sums up Sun’s difficulties nicely as ‘too much vision, too little execution’.  It’s not enough to give away tools and hope the next generation will adopt them. You need to innovate and to lead, because the brightest and best of the next generation want to climb the mountain, not travel for free in the foothills. To innovate, you need great scientists and engineers; to retain those folk, you need to pay them adequately and provide them with the facilities and resources they need to be brilliant. To do all of that, you need money.  And that comes from sales.  It’s as simple as that.

Just look at Microsoft Research: you just can’t foster this quantity and quality of innovation unless you have a lot of money to invest, and you only get that by doing a lot of very effective monetizing.  Microsoft and Oracle: we don’t like them very much, do we? But they’re really good at monetizing.

As for Java, most seem to agree there is no threat to its future as an enterprise platform: it’s open-technology now and well embedded in the enterprise.  What about the future of the Java language? Do we really need to worry about that? The language itself matters much less than the JVM, which surely has a very bright future given the newer languages targeting it, especially Scala and Groovy.  Should we care whether (e.g.) closures make it into the Java language, if we can use newer languages like Scala and continue to leverage all the existing Java libraries, components and infrastructure?

Technorati Tags: ,,,