Not so Groovy

I can’t believe my last post is from before when I started my MSc course in London. Anyway, without making up more excuses for that, I’ll move to the actual topic of this blog post: the Groovy programming language. Which turns out not to be so groovy …

From the Groovy website, it “is an agile and dynamic language for the Java Virtual Machine”. An agile language? Ahm … whatever. Unfortunately, things don’t get better.

First of all, you almost find no information on groovy outside their official website, and the stuff on their is badly organized and rarely of any use.
Then, there is still all that Java stuff. Want to create a collection of something? Oh yeah, there’s Map, List, Array, ArrayList, Collection, Set … I mean, seriously? Probably there even more types, but it’s hard to find out in the docs. Oh how I love JavaScript: Object. That’s it.
But the thing that bugs me most is the language itself: It feels so extremily fragile and buggy. I never thought of a programming language in these terms before, I would have used those terms for software only. I think one reason for this is Groovy desire to be smart or”groovy”. Let’s have a look at an example: The type system and meta programming.

Say you have this class:
class A { void print(String message) { println message } }
With meta programming, you can add another method like so:
A.metaClass.shout = { message -> println message.toUpperCase() } }
Oh, actually, it’s a closure and not a method, and Groovy has extra syntax for closures … Anyway, not going into that, let’s try it:
def a = new A()
a.print("Hello World") // prints "Hello World"
a.shout("Hello World") // prints "HELLO WORLD"

Okay, so long this is nice, but here things become weird. Say we want to replace a method (which would be very useful in unit tests):
A.metaClass.print = { message -> }
def a = new A()
a.print("Hello World")

If you would expect that nothing gets printed now, you’re wrong! Calling print still gives you “Hello World”. Hmm … Too bad. Why is the method not replaced? After some time, I changed my class to this:
class A { void print(message) { println message } }
Notice the difference? message is not typed anymore. Applying the meta trick again now results in:
A.metaClass.print = { message -> return "" }
def a = new A()
a.print("Hello World") // prints "Hello World"

Yep. Really. Okay, to be honest, it works if you type the closure as well. But here’s the thing: This weird mixture of handling type very lax but then again very tightly is a constant source of confusion. Either have a static type system, or have a dynamic one. But please, not both! I can’t count how often I stumbled upon this and similar issues in the last days … Unfortunately, Groovy is full of this “smart” behaviour that is destined to get in your way …

Dear language designers: Leave it to the programmer to be smart and make an easy language with only a handful of concepts. Not a myriad of concepts and hundreds of “smart things” to remember. Actually, that’s something that JavaScript gets completely right …

And dear programmers: Spare yourself some hair pulling and avoid Groovy.

posted on March 30, 2011

2 Responses to “Not so Groovy”

  1. Claudius says:

    Hi Michael, thanks for sharing your opinion about Groovy which I didn’t use before. Now I have some impression of this language and will follow your advice not to use it. Your advice towards the language designers seems wise: a handful of concepts. This reminds my of the philosophy of Python: “There should be one—and preferably only one—obvious way to do it.” Did you mean this, too, by your advice?

  2. admin says:

    @Claudius: Yes :) I think both thinks work together: The fewer the concepts that are available, the more obvious it is which one to choose. Even better if there is only one solution, yes, although I believe that there are almost always several design choices possible …