Monday, July 5, 2010

Book Review for "Groovy for Domain-Specific Languages"




Book Review of "Groovy for Domain-Specific Languages", or how to teach a Java guy Closures and Meta-Programming

Are you an accomplished Java Coder, but not very experienced with the 'dynamic' languages like Python, Ruby or Groovy? I am.

Sure, I know a little about all those languages, especially Python. For quite a while now, I've used Python for scripting and even for quick Hadoop jobs. But the way I used Python wasn't much different than how I'd use Java-- mostly plain Object Oriented technique at the fanciest, more likely just plain old procedural scripting for quick-n-dirty text manipulation jobs. I'd read the occasional article about dynamic language features (like closures, metaprogramming, and built-in builders) but I didn't really have a good idea what those meant.

That all changed after I read "Groovy for Domain-Specific Languages" from Packt.

Groovy, it turns out, is a language built on top of the JVM and it offers really easy integration with Java. (So much so that your Groovy code compiles to JVM bytecode, so all the current Java code you have available to you is also available to your Groovy code.) The book goes about introducing Groovy in terms a Java coder will easily understand, and I think the author did a good job in this respect.

Groovy can be an easier Java. Language verbosity is relaxed, so coders can drop parenthesis, semi-colons, and variable types where it makes sense. This saves a few keystrokes at code-writing time, but more importantly it produces code that's a lot leaner so it can be much more readable. But that's not what helps in DSL construction.

DSLs, for those of you impervious to the growing dev-space din, are "Domain Specific Languages", or little languages meant to serve a single purpose. Never heard of that, you say? How about 'Regular Expressions', 'Make', and 'Ant'? I'm sure you've heard of those! They're all examples of little language that are designed to perform some very specific task, and make the user's life easier than if they had to use a general purpose language like C or Java to accomplish something like compiling a .jar.

This book goes about explaining some of the features a dynamic language like Groovy has that make DSL authoring an easier task. One such feature is the 'Closure' something Java doesn't have at this time. So what's a closure? I'd call it a method, except it's packed up in such a way that you can send it to other methods as a parameter. Confused? Check this example:

def islanders = ["Skipper", "Gilligan"] // This is a List in Groovy
def aClosure = { println "Hello, ${it}" }
islanders.each (aClosure) // This will print "Hello, Skipper" "Hello, Gilligan"

Another DSL-friendly feature of Groovy is Meta-Programming. Meta-Programming is writing code that can change it's behavior at runtime. One flavor of this is Reflection, which I knew from Java-- given the String name of a class, I could conjure up an instance of that class. I'd also seen in Python how you can add properties to an object 'on the fly'-- if that property wasn't there, the class just somehow put it there as soon as you accessed it, and the code went chugging along. But that's just the tip of the iceberg! In Groovy you can have your class respond to method calls that you didn't write at the time the class was authored. Weird! Yet very handy if you're writing a DSL, as the book explains.

The book is really a double-whammy, covering both Groovy-for-the-Java-Coder and Best-Practices-in-Writing-a-DSL. IMHO, it covers the first topic in more detail than the second, but I liked what I got from both.

The book can be found here.

There have been several times in my career where I've written a little language, probably with mixed levels of effectiveness. The next time this topic arises, I have a new weapon to bring out, so I'm waiting on it now!

'Till then,

Happy Coding!

1 comment:

Anonymous said...

How come every one of your Packt book reviews is super-positive, with almost no negative comments, despite Packt's well-known, and well-deserved, reputation for publishing the most editing-error-prone computer books on the market?