I begin with three non-sequiturs.
- Am I just more aware of functional programming thanks to my recent study of On Lisp? Or am I witnessing a fashion shift in popular programming techniques?
- Guy Steele recently defended his work on Java "we were after the C++ programmers. We managed to drag a lot of them about halfway to Lisp. Aren't you happy?"
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).
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.
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