Book Review: Programming Groovy

Let's cut to the chase: Groovy Programming by Venkat Subramaniam is a great book.

Venkat really nails this one on several dimensions...

1. The audience is skilled Java developers. Java is the baseline. We don't need an explanation of String, or ArrayList, or any of the Java types. We don't need reams of pages on what closures are. This book launches right into why Groovy improves Java, rather than dwelling on how the syntax works or what the library methods are.
2. The presentation work great. It's a Pragmatic Bookshelf book, so it's gonna be an easy read. Whitespace, font size, margins, text to graphics ratio; the Prag team knows how to make a trade paperback inviting and easy to read. Maybe you've never thought about this stuff before, but look at a Prag book side by side with another publisher and you'll see my point. Another thing, this book thankfully has no fictional personas you follow through the life of a project. I hope they've retired this style for good.
   
3. The cool concepts are covered quickly and with examples. If you combed the GDK and Groovy docs for all the cool, weird features, listed them all out, and tacked on examples, then you might be pretty close to the table of contents for this book. There is a lot going on in groovy-core, and I think some of the other titles might have aged a little since their release. (On this note, it looks like Definitive Guide to Grails 2nd Edition is due in October, yipee!)
   
4. 100 pages on meta-programming. What more do you need, someone to hold your hand and show you all the current techniques? Oh wait, that's what this is.
   
5. The pacing and chapter choice are excellent. Each chapter is standalone and would make sense whatever order you read them. Skip right to "Working with XML" if you want then read the rest of the book in order. However, the book took me less than 10 hours to read, so you'll get there quickly reading linearly too.
   
6. It's still a good reference. When writing Groovy code, I've reached for this book twice in the last three days instead of going for the usual Google search for help. There are a ton of examples and I find myself saying, "I know this is possible, let's check out how Venkat did that."

The book does a great job balancing quick explanations of concepts, code examples, and insights into the implementation of Groovy. Even in chapters on topics I'm familiar with, I found myself impressed with everything Venkat found that I hadn't seen before.

So the book is great, now let's talk about edge cases.

On finishing this book I was struck by one thought, "Holy crud there are a lot of edge cases". I can't find a source for the quote, but someone once described Dungeons & Dragons as a training school for young lawyers. D&D is a large system of rules, which usually appears consistent but are oftentimes conflictory. If you can memorize all the rules you can usually find a loophole, game the system, and get what you want. See, it is exactly like our legal system! All those hours of reading the Player's Guide and DM Manual in my childhood reminds me of the hours I now spend looking into the corner cases of Groovy... for instace:

Did you know the semi-colon is not always optional? The last line before an instance initializer block will require one or the interpreter will think you're trying to pass a closure as a parameter. Oops! Think invokeMethod() is called before every method call? Only if the object invokes GroovyInterceptable. The method dispatch chart is sweet if you're into these weird, complex rules like I am. Think all classes have an ExpandoMetaClass? Actually, none of them do (at first). EMC is one possible implementation of metaClass, and by default objects have a MetaClassImpl, but once the metaClass property is read, the underlying implementation gets switched to an EMC. Wow, crazy. I have a feeling this will be fixed in the future.

Here's an edge case that is useful to know about: Stubs and Mocks do not intercept constructor calls. So when you mock a FileWriter (which takes a string parameter on the constructor and creates a file with that name within the constructor), you'll find that your file system actually does have files getting created on it. Can't say I've ever had a test fail because of that, but it is good to know!

I'll leave you with another quote I can't attribute. Someone commented once that Ruby doesn't have a Ruby Puzzlers book because it would be 10,000 pages long. Maybe the same can be said about Groovy, but it's no bad thing. This book is filled with cool, puzzling language tricks. That's part of the fun! And this book is a fun read too... it'll be on my shelf Monday so stop by my cube and borrow it for a few days.

Viva la Groovy!