Functions rising

Thursday 27 May 2004 at 09:31

I begin with three non-sequiturs.

Can I weave them into a coherent story?

I have an imaginary origin for Groovy, whether or not it actually happened this way in reality. First, I need to set the stage. I've been lurking around James Strachan and Bob McWhirter since meeting them through Jason van Zyl and Turbine and Maven. I've been subscribed to James' and Bob's blogs since I started blogging. In fact, James introduced me to the blogsphere, both because it was his blog I read first and because he was among the first to blogroll mine (thanks, James, on both counts).

When I met James he was developing Jelly. Around that time Jelly replaced Ant at the heart of Maven. In those very early days of Maven, I remember Bob complaining somewhat loudly about programming in XML. Also at that time Jason was evangelizing Avalon, Inversion of Control, and also Aspect-Oriented Programming. Coincidentally I was introduced to Jython at about the same time by Scott Shattuck, with whom I was working at PlanetCAD. Jython led me to python. Python and blogs lead to PyBlosxom (PyBlosxom just released version 1.0) A lambda in PyBlosxom lead me to finally read On Lisp. Through On Lisp I groked closures. With closures in JavaScript and SVG, I recreated my animation of a vanishing point and rekindled my interest in an animation language. Now the circle is complete.

Back to Groovy. I imagine that it was friction between James' interesting and useful work on Jelly and Bob's rightful distain of programming in angle brackets which spawned Groovy. Clearly there's some Jython, Python, and Ruby mixed in too as evidenced by the excellent use of closures and other functional goodness.

If Java brought C++ programmers half-way to lisp, I think Jython, Python, Ruby, and Groovy are going to take Java programmers another quarter of the way. XP and unit testing will help this along because unit tests do more for your code than the compiler and these dynamic languages make programming faster.

Moreover, Aspect Oriented Programming will take Java programmers another eighth of the way to lisp. CLOS has a notion of before, after, and around methods which I think map nicely to various things I've seen in AOP. But I made the assertion at work today that what people are trying to do with aspects in Java would probably be done primarily with macros in lisp. Of course I'm speaking primarily from my intuition having done vanishing little with either aspects or macros.

I suppose I'm just projecting my own programming growth path onto the Java programming community as a whole. I only recently groked closures. Understanding macros and continuations came rather quickly after that, though actually groking those will be a while unless I start doing real work in lisp.

In the past week at work, I've been rhetorically asking why not just throw out all this perl code and rewrite it in lisp? It's a lot of code to rewrite. No customers are asking us to program in lisp. None of our problems specifically demand it. Perl is a much larger community, therefore there are probably more useful libraries available, broader documentation. One thing new customers fear is vendor lock-in. When they don't know us yet, they don't trust us yet. If the code they pay for is in perl, it will be easier for them to find someone else who can work on it than if it were in lisp.

My other imaginary story is that the Java community (and by competitive pressure the VB and .NET communities too) will collectively learn different ways to think from Groovy and Jython and AOP. Those ways of thinking will lift the veils of mystery from lisp and make it into a popular enterprise programming language. Of course it could work out differently. Maybe Service Oriented Architectures will teach us all to think in terms of messages like Smalltalk programmers.

James Strachan commented

27 May 2004 at 12:22

Hey Eric. Thanks for the mention! You're guesstimate of where Groovy came from is pretty close to the truth :)

Also I agree, we're all getting ever closer to lisp/scheme - especially if/when groovy gets macros - just a slightly different style of lisp with a more popular feel & no parethesis hell :)

I think the one missing ingredient was - I thought it was time to try come up with a language which assumes a JVM / .NET runtime like environment already exists, and layer the language on top - rather than start from some ivory tower (or port an existing designed-in-a-vacuum language) to avoid having leaky abstractions at the language layer as it binds to the underlying platform.

But yes, my experience on Jelly, Ant & Maven tought me the value of scripting without leaving the underlying platform