« What should we call "agile" languages? (warning: troll) | Main | Massachusetts starts open source repository »

Groovy JSR: I don't doubt it

And we hold the world ransom for... One Millllyyon Dollars.

Simply put: Groovy is a very real threat to Java. - Otaku, Cedric Beust

Groovy is not a threat to Java. But Groovy and its ilk are a sea-change to how our industry goes about producing middleware (much of it built around J2EE), right down to the business models. Those of us who have been using Lisp, Ruby, Smalltalk, Python et al to build systems alongside Java already know this. These 'scripting' languages are not just toys for building and deploying code folks, not anymore. There seem to be fewer and fewer interesting technical arguments pro Java The Language (JTL) [Java the Virtual Machine (JVM) is different entirely]. Worried about performance? Well, compiled Lisp has been always been faster than Java, and I imagine commercial Smalltalks are there or thereabouts. And after all, who isn't using JSP? The best argument pro JTL is that it is a market - both for middleware and developers and offers economies of scale and lowered risk for the customer as a result. But a certain class of languages seem to be far better suited for managed middleware components - by being more expressive, more maintainable. more flexible. Faster, cheaper, better. Add to that an economic imperative for developers in the US and Europe to become 3-5 times more productive in order to compete with developers elsewhere... well, Donald Rumsfeld put it best:

If you don't like change, you'll like being irrelevant even less.

Now, I can imagine Sun rejecting this JSR, but I don't think they will and I think Cedric is underestimating their vision. Sun will take it on board, or risk missing a big wave in middleware development (here's a clue: it's not Grid or Webservices). I don't think they'll act with the same inertia they did with XML. Opening up the JVM to dynamic languages would keep them years ahead of .NET while letting IBM/Eclipse duke it out on the tools front (did I mention that tools matter less with the right language?). It's not hard to see a Jython, JRuby or Smalltalk JSR following in its heels.

[eels: beautiful day]


March 18, 2004 07:33 PM

Comments

foo@bar.com
(March 19, 2004 07:13 AM #)

> Now, I can imagine Sun rejecting this JSR

I can't (totally independent of what Sun folks might actually think of Groovy), because it's not possible ... accepting JSRs like this is based on a majority vote of the SE/EE Executive Committee of the JCP. If you're confused about the *actual* process, please review:

http://jcp.org/en/procedures/jcp2

rather than believing rumors and innuendo, or thinking that someone else who blogs actually knows what they are talking about?

Bill de hra
(March 19, 2004 09:58 AM #)

I'm deeply unconfused about JCP process, having served on a number of JSRs. The actual process involves people deciding how to vote, most of whom are representing a vendor. But, if I had said wanting to reject this JSR, would that have helped?

bryan
(March 21, 2004 03:03 PM #)

'Add to that an economic imperative for developers in the US and Europe to become 3-5 times more productive in order to compete with developers elsewhere'
I really don't understand this theory, it's the third time I've encountered it. Do you think developers elsewhere are culturally incapable of learning these languages? Do you think there is some sort of governmental restriction on them learning a dynamic language? Surely not. Why make the argument then?

Perhaps you should just say that it will help make developers everywhere 3-5 times more productive. That should be incentive enough.

Bill de hra
(March 21, 2004 11:09 PM #)

[[[
Do you think developers elsewhere are culturally incapable of learning these languages?
]]]

No.

[[[
Do you think there is some sort of governmental restriction on them learning a dynamic language?
]]]

No.

[[[
Why make the argument then?
]]]

I believe the economics of outsourcing leans towards market optimal, technically suboptimal language choices. That is, the median leans toward mediocre programming languages because it's easier to find someone who knows a mediocre language and programmer intererchangeability suits the business models. Personally I think this is misguided but there's an entire industry that clearly disagrees with me. So I believe there's a competitive edge to be had in choosing the right language for the job. And yes that edge is as good as the number of people that aren't using the language. But then again, I don't see the incentive for outsource providers to be more efficient in language choice as they can compete solely on cost. Contrariwise, those being outsourced cannot (obviously) compete on cost so need to seek an alternative. A new programming language is one such alternative.

[[[
Perhaps you should just say that it will help make developers everywhere 3-5 times more productive. That should be incentive enough.
]]]

History suggests otherwise. Anecdotally, Lisp has been 5-10 times more productive that C++. The world chose C++. Sometimes you need more persuasion.

bryan
(March 22, 2004 02:08 PM #)

okay, good points but:
'I believe the economics of outsourcing leans towards market optimal, technically suboptimal language choices. '
It seems as though the economics of programming as a whole has leaned towards market optimal, technically suboptimal language choices. The argument now being proposed is that with outsourcing the economics of programming no longer leans towards this, I just have the sneaking suspicions that should the economics of Programming as a whole change then the economics of outsourcing will probably change with it.

Trackback Pings

TrackBack URL for this entry:
http://www.dehora.net/mt/mt-tb.cgi/1191

Listed below are links to weblogs that reference Groovy JSR: I don't doubt it:

» Groovy: A Threat to Java? from Stefan Tilkov's Random Stuff
Bill de hÓra, Cedric Beust, and various more or less clueless folks on TSS add their comments to the Groovy JSR debate. I hope that the JCP executive committee will accept it — in my opinion, Groovy would be simply a great addition to the JV... [Read More]

Tracked on March 18, 2004 09:31 PM

» Sun, the Groovy JSR and concerns over implementations from James Strachan's Radio Weblog
Multiple Implementations of Groovy There's been another concern expressed recently over how many implementations of Groovy will there be - what if there's only one? Just to be clear, its the EG's responsibility to make a great spec and a reference impleme [Read More]

Tracked on March 19, 2004 09:36 AM