Yesterday I blogged ten pleasant surprises with Groovy and Grails. Let me reiterate that overall, I am impressed. But there are a still a few issues that make JRuby a more promising alternative at present.

1. Groovy classes are not open. I understand the reasons for this decision, but I want the productivity boost possible in a language where this is legal:

   class Person {
     def firstName;
   }
   p = new Person();
   class Person {
     def lastName;
   }
   p.lastName = 'Halloway'

   My example here is trivial, but the concept isn’t. For more on both sides see here and here.

2. Grails is not written in Groovy! (For the most part.) I went looking for the implementation of the chain method, and it was a whole Java class to itself. I am hoping that the Java bias is legacy, and that the Grails team is now more comfortable eating Groovy dog food.
3. The “optional static typing” argument is a red herring, until somebody produces some compelling examples. Groovy advocates point out that they have the best of both worlds–dynamic typing with static typing available on request where needed. This sounds good, and it may be good, but show me some significant examples. Better yet, articulate some rules of thumb for when to use dynamic typing, and when to use static typing, within a single Groovy project. This is a serious request, not flamebait. Instead of debating “static typing–yes or no?”, let’s debate “static typing–when?” in a language with a clean syntax for both.

– Stu Halloway

Tags: Stu Halloway

After meeting Graeme Rocher at JavaOne, I decided it was time to give Groovy and Grails a second look. Here are the ten items that jumped out at me, as a Java and Ruby developer learning about Groovy and Grails:

1. While new languages often introduce gratuitous syntactic differences, Groovy’s differences are often appealing. I think I could come to like the syntax for case equality (===), hashes ([x:'y']), and open ranges (1.<10) better than their Ruby counterparts.
2. I have often wished for the safe dereference operator (e.g. org.person?.name) when writing Ruby code. I am sure people will use this to paper over Demeter violations, but it is nevertheless worth having.
3. Grails defaults to an in-memory HSQLDB database for development. This is even easier than Rails, setup-wise.
4. Grails follows Rails’ lead in providing a flash scope, and goes a step further in implementing a chain scope. I will be adding this feature to my Rails projects.
5. Grails has a built-in dynamic scaffold, more like Streamlined than a static scaffold.
6. Grails generalizes the notion of a builder library with reusable support for building arbitrary nested structures.
7. Grails’ model saving support (save/validate/discard) is more complex than Rails’. On first glance, I feared this was unnecessary complication, but actually it is quite nice. The common case is simple, and parallel to Rails. The other cases are there if you need them.
8. As applications become more complex, Grails makes nice use of Spring’s autowiring to inject supporting classes. (I find that excessive autowiring obfuscates relationships, but the Grails examples I have seen so far look just right.)
9. The Groovy MetaClass (and its use in Grails) is very powerful. As Graeme points out, the MetaClass brings Groovy much closer to having the whole language there, all the time. Groovy still does not have open classes, but open invocation is a workable alternative for many use cases.
10. The Definitive Guide to Grails is a very good book. If you are coming from a Java or Ruby background, this book is a perfect jump start for both Groovy and Grails.

– Stu Halloway

Tags: Stu Halloway