Computerworld is undertaking a series of investigations into interesting programming languages. In the past we have spoken to Larry Wall, creator of the Perl programming language, Don Syme, senior researcher at Microsoft Research Cambridge, who developed F#, Simon Peyton-Jones on the development of Haskell, Alfred v. Aho of AWK fame, S. Tucker Taft on the Ada 1995 and 2005 revisions, Microsoft about its server-side script engine ASP, Chet Ramey about his experiences maintaining Bash, Bjarne Stroustrup of C++ fame and Charles H. Moore about the design and development of Forth.
We’ve also had a chat with the irreverent Don Woods about the development and uses of INTERCAL, as well as Stephen C. Johnson on YACC, Steve Bourne on Bourne shell, Falcon creator Giancarlo Niccolai, Luca Cardelli on Modula-3, Walter Bright on D, Brendan Eich on JavaScript, Anders Hejlsberg on C#, Guido van Rossum on Python, Prof. Roberto Ierusalimschy on Lua, John Ousterhout onTcl, Joe Armstrong on Erlang and Rich Hickey on Clojure. We most recently spoke to Martin Odersky about the darling of Web 2.0 start-ups and big corporates alike, Scala.
In this interview Groovy Project Manager, Guillaume Laforge, tells the development story behind the language and why he thinks it is grooving its way into enterprises around the world. Groovy, he says, is ultimately a glue that makes life easier for developers — and it has nothing to do with Jazz.
If you wish to submit any suggestions for programming languages or language authors you would like to see covered, please email kathryn@computerworld.com.au
How did you come up with the name Groovy? Is it a reference to counter culture or are you a jazz fan?
There's a little known story about the invention of the name!
Back in the day, in 2003, after suffering with Java and loving the features available in dynamic languages like Ruby, Python and Smalltalk, lots of questions arose of the form of, "Wouldn't it be 'groovy' if Java had this or that feature and you could replace said feature with closures, properties, metaprogramming capabilities, relaxed Java syntax?” and more.
When it came to choosing a name, it was obvious that a new language with all those great features would have to be called ‘Groovy’! So it's not really a reference to counter culture, nor about jazz, but just about the dream of having a language close enough to Java, but more powerful and expressive. That's how Groovy came to life.
What are the main differences between Groovy and other well-known dynamic languages like Ruby, Python and Perl?
The key differentiator is the seamless integration with the Java platform underneath. It's something no other languages provide, even alternative languages for the JVM (Java Virtual Machine), or at least not up to the level that Groovy does.
First of all, the grammar of the language is derived from the Java 5 grammar, so any Java developer is also a Groovy developer in the sense that the basic syntax is already something he would know by heart. But obviously Groovy provides various syntax sugar elements beyond the Java grammar. The nice aspect of this close relationship is that the learning curve for a Java developer is really minimal.
Even at the level of the APIs, aspects such as the object orientation and the security model are all just what you would be accustomed to with Java. There's really no impedance mismatch between Groovy and Java. That's why lots of projects integrate Groovy, or why companies adopt the Grails web framework.
What led you to develop Groovy — was it to solve a particular problem or carry out a particular function that you could not do in another language?
Back in 2003, I was working on project that was a kind of application generator where there was a Swing designer User Interface (UI) to define a meta-model of the application you wanted to build, and you could define the tables, columns, and UI widgets to represent the data and layout. This meta-model was deployed on a web application that interpreted that model to render a live running application. It was a pretty powerful system.
The project also allowed some customised UI widgets to render certain fields, like autocomplete fields and such, and you could develop your own widgets. But those widgets had to be developed in Java, compiled into bytecode, archived in a JAR file, and — the biggest drawback of all — you then had to deploy a new version of the web application to take this new widget into account.
The obvious problem was that all the customers using those generated applications had to stop using them for a moment, for a maintenance window, so that only one customer could have access to that new widget he needed. It was at that point that I decided a kind of scripting language would be useful to develop those widgets, and have them stored in the meta-model of the applications, and interpreted live in the running server.