Sponsored Link •
Ruby and Groovy are contrasted. Despite high hopes and best wishes for the Groovy project, in this author's eyes Ruby turns out to be the winner for most scripting tasks.
It has taken me quite a while to decide to share these thoughts. I really like the folks who are implementing Groovy. I found them to be extremely helpful on the mailing list, and I like their basic concept. A truly portable scripting language is a terrific idea. Unfortunately, that portability seems to be acquired at the expense of the two features that make scripting languages so seductive: Minimal coding and fast write/test/revise cycles.
On the other hand, even if Groovy eventually turns out to be terrific, it would still make sense to learn Ruby today--if only because so much has been written about it. That abundance makes it possible to become familiar with the strange new constructs like closures that are so unfamiliar to most Java hackers. So understandnig both Java and Ruby should make it possible to easily transition to Groovy, when it makes sense.
I began looking at Groovy with high hopes and great expectations, but reluctantly had to conclude that it's going to be the technology of choice only in very limited set of use cases--primarily ones in which the VM is already running.
For general purpose scripting, the time it takes to crank up the VM and intitialize the interpreter is a deal killer--as much as 30 or 40 seconds on my machine. I get better performance compiling and testing Java code in an IDE, especially if it supports incremental compilation in a background task.
The start-up delay is sufficient by itself to rule out Groovy as a general purpose scripting language. But unfortunately, it gets worse:
- Things are still in flux, to the point that many discussions on the user list are aimed at deciding how the language should be implemented. That's terrific, from the agile methodology perspective. It means that user needs are feeding into the design. But it also means that the basic language design is not yet complete.
- Lack of documentation. It's to be expected at this stage of its evolution, but given that things haven't entirely settled down yet, it's pretty scary to contemplate using it for anything important.
- Mostly unhelpful ANT integration. Ruby got this one right with Rake--super simple syntax plus the power of the language when you need it. Groovy has (so far) missed a serious opportunity here. You can call ANT tasks from a Groovy script, and you can invoke a Groovy shell from inside ANT, but neither one of those alternatives has anything like the expressive power or sheer convenience of Rake. (For more on Rake, see Martin Fowler's article at http://www.martinfowler.com/articles/rake.html)
- Dependence on the Java library. It provides a lot of power, but utilizing those libraries means the language hasn't provided the kinds of one-line operations that make it easy to do the simple things you can do with Ruby--for example I/O and XML parsing. (For more, see Make, Mailing Lists, and Ruby at http://www.artima.com/weblogs/viewpost.jsp?thread=152464)
- Ruby has some really cool features like modules and structs. Maybe Groovy does, too. It's hard to say, given the documentation. But more likely the requirement that compiled Groovy scripts must function as JVM classes will be a limiting factor in this area.
- Then there are features inspired by Unix command shells--the ability to expand variables inside of a double-quoted string, and the ability to execute a shell command inside of back-quotes and get back the return string. Of course, shell commands are platform=dependent. But in Ruby the very definition of a method is determined at runtime, so it's possible to code multiple-platform versions with no significant overhead--because the conditional branch that determines how the method operates only occurs once, when the method is first read.
- Rake may well be taking advantage of the dynamic behavior when it implements the kind of cross-platform commands you typically need in a shell script: Commands like cd, mkdir, and mkdir_p (to a make a directory from a path, and all directories that need to be made to get to it). To tell you the truth, I don't know any language intended for scripting can do without such things. (To my mind, those functions should be part of the standard library.)
- And speaking of dynamic, runtime behavior, Ruby has lambda functions: the ability to generate code on the fly and execute it. Those turn out to be useful when defining Rake tasks, as Jim Weirich describes so nicely: http://onestepback.org/index.cgi/Tech/Ruby/EckelAndFowlerOnBuildSystems.rdoc http://onestepback.org/index.cgi/Tech/Rake/Tutorial/RakeTutorialAnotherCExample.red
Ruby sure isn't perfect. There are many Perlisms I'd rather not have seen, and it has too many ways to do things, imo. That flexibility is great when you're writing code, but it makes things harder when you're reading it, because you have to master the idioms favored by whoever did the writing. (You can alias things in Ruby and you can even overload operators--so you could conceivably write something that /nobody/ could read.)
|Eric Armstrong has been programming and writing professionally since before there were personal computers. His production experience includes artificial intelligence (AI) programs, system libraries, real-time programs, and business applications in a variety of languages. He works as a writer and software consultant in the San Francisco Bay Area. He wrote The JBuilder2 Bible and authored the Java/XML programming tutorial available at http://java.sun.com. Eric is also involved in efforts to design knowledge-based collaboration systems.|