Preface

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.

Comparing the Languages

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.)

Bottom Line

If you need a scripting language, Ruby is a great one.

When it comes to building an application with multiple authors and long term maintainability, I'd say there's a lot of decision-making to do before going with Ruby. If you're going agile with a small team that can easily teach each other its favorite idioms, Ruby will probably work. If you adhere to a more structured methodology and have a large, long term project with many lines of code--so you can expect a fair amount of turnover among the people who will be maintaining it--then Ruby probably isn't a good fit.

Once the problems of documentation and open design issues are resolved, Groovy may yet find a home in that sort of application-building environment. It will provide dynamic flexibility, like Ruby, but with full JVM integration so you can build and use Java classes.

But when we begin to drag in all that machinery, we're not talking about something that feels like a "scripting" language, anymore. We're talking about something that lies somewhere between a scripting language and an application programming language. So Groovy may yet find a home, but for the kind of fast development cycles I was looking for, Groovy simply isn't the language. At least not yet.

I still think that a truly portable dynamic scripting language is a great idea. I just don't see how it can be done in the JVM, except in some sort of server-side setting where the JVM is kept running and initialized, and there is some mechanism to feed it a script on the fly.

But to rapidly develop those scripts, an "on the fly" mechanism is needed for testing, as well. In other words, the JVM has to be effectively part of the operating system--wholly integrated into it so the startup time disappears. Until that's done, I don't see how Groovy can provide the same kind of immediacy that Ruby provides. The other problems can eventually be resolved. But that startup hurdle seems insurmountable in theory, as well as in practice.

Then again, maybe there are some viable usage scenarios I've overlooked. That would be nice.