What is Wrong with Groovy?
Mike Spille has written a long essay on "How Groovy Lost its Groove Thang". Now, unlike Mike, I really haven't been keeping abreast of the ongoing development of Groovy. However, I've got a couple of observations that I believe I'm qualified to make. For starters, in a previous life I developed a Java based language using ANTLR. For seconds, I've played a little bit with Groovy to know how it feels from the user perspective.
The first thing I noticed about Groovy was that the parser was written by hand without the benefit of a parser generator like ANTLR or JavaCC. I've been involved in designing a language before, and take it from experience, there's no substitute for using a parser generator to pinpoint your ambiguities. It was really a exasperating experience when the then CTO requested a new grammar feature without ever testing it through the parser generator. The parser generator is a grammar developer’s equivalent of a JUnit test. Its absense is equivalent to flying blind. The mere fact that even a formal EBNF wasn't available was the first red flag.
Unfortunately, I was real fan of James Strachan's work, after all he put together Jaxen and Dom4J. These are two libraries that I use on a daily basis. Furthermore, Groovy is an idea that holds so much promise. I was then willing to give it the benefit of the doubt. My only public objection at the time was that I thought a group more skilled in language development should participate in its development (see "Scala the Groovy Killer").
There's no substitute to getting your hands dirty. So that's what I did, I put together a couple of Groovy scripts to extract information from the del.icio.us collaborative bookmark system. That's when I realized that Groovy was really heading off a cliff. That's when you realize that many Java language features were not implemented. That's when you realize that error handling was a complete oversight and for all intents and purposes completely neglected.
Error handling in language development is one of those tasks that's not only difficult but an extremely mundane tasks. It's critically important for the usability of a language, unfortunately its a job that nobody is going to get any visibility performing. Combine this thought with that of the open source nature of Groovy and you'll quickly realize that nobody is going to volunteer to take out everyone's garbage.
So what now, how can we salvage this debacle? Should restart the development beinning with a new ANTLR grammar? Can we leverage existing open source Java interpreters like DynamicJava (built using JavaCC) and extend it? Can we start from a theoretically stronger foundation like Scala and bolt on scripting to improve usability? Can Jikes Parser Generator be leveraged to gracefully handle errors?
Unfortunately, the problem is beyond technical but more organizational. Is there a group of people who are willing to make the sacrifice and have the perseverance to build a usable scripting language for Java? In the absence of a individual with the focus to complete this effort, are there corporations willing to fund this effort?
My ultimate recommendation is to rename the entire project to "Scoovy" and then re-boot the project.
Last modified 2005-01-10 03:09 PM