Groovy For Domain-Specific Languages 81
RickJWagner writes "This is a book targeted primarily towards the Java programmer who doesn't yet know Groovy. Groovy is a dynamic scripting language that runs on the JVM and offers easy integration with the Java language. Groovy also offers dynamic language features that lend themselves to the creation of DSLs (Domain-Specific Languages). This book attempts to simultaneously teach the reader how to use Groovy and how to build a DSL." Keep reading for the rest of RickJWagner's review.
DSLs are something of a hot topic these days. A DSL is a 'Little Language' or a language written just for one business domain. As programmers, we're familiar with DSLs whether we realize it or not-- each time you use 'Make' to build a C project, or use 'Ant' to make a Java project, you're using a DSL. A DSL is a purpose-built language, with it's own verbs, rules, syntax, etc. It's made for one purpose only, and is meant to make things as easy as possible for the intended user. If the user has a need outside what the DSL can provide-- they're just tough out of luck! General purpose languages are for doing whatever the user needs-- DSLs are for doing only one task, but making that one task exceedingly easy for the user.| Groovy for Domain-Specific Languages | |
| author | Fergal Dearle |
| pages | 312 |
| publisher | Packt Publishing |
| rating | 7/10 |
| reviewer | RickJWagner |
| ISBN | 184719690X |
| summary | a practical tutorial, walking the reader through examples of building DSLs with Groovy covering meta-programming with Groovy |
The book does a good job of making Groovy understandable for a Java coder. Programmers of other stripes would be able to use the book, but the author aimed squarely for the Java sweet spot and I think did a good job of hitting it. Where language integration was to be shown, the JDK was the reciprocal part in the examples, and the classes singled out for interfacing were ones that would be well-known to a Java coder.
Writing DSLs has been done for many years, but was largely an undocumented process until just recently. I think the rise of dynamic languages has something to do with that. Dynamic languages offer some key features that make DSL creation a little easier. A few of these features the book covers are closures and meta-programming. Closures are anonymous methods, packaged in such a way that they can be passed as parameters to other methods. Meta-programming is using code to write other code, and can be used to perform some neat tricks like allowing the user to call methods that don't have a previously written definition. (If that sounds really strange to you, I agree. But it turns out this is something very handy if you're writing a DSL!)
The book is written in a way that thoroughly the breadth of features offered by the Groovy language, but not a lot of depth in all of them. For this reason, I found myself sometimes referring to external sources when I was encountering some language construct that seemed a little less familiar than most. It wasn't a problem-- the book did a fine job of letting me know of the existence of some language feature and how it might be used in writing a DSL. If I didn't immediately grasp the use of the feature after the typical single example of seeing it used in sample code, I'd just pop out to the internet and get a few more examples. The book is nearly 300 pages as it is, and very little of that is wasted. I give the book good grades for technical content.
Style-wise, I found the book reasonable to read but not great. As well as the author does spelling out the nuances of the Groovy language, the DSL parts are interspersed among the chapters and sometimes could be hard to find unless you read a lot of surrounding technical content. Maybe this is the only way to cover two meaty topics at once, I don't know. But I found myself doing quite a bit of paging when I wanted to refer back to DSL-specific advice, sometimes falling back to the chapter-by-chapter summary in the front of the book to get myself in the right neighborhood.
The book has plenty of sample code, which I found well constructed and easy to read. The author adapted the practice of writing small snippets of code, then used assertions to demonstrate the behavior the reader would expect if the code were to be executed. I really liked that. The code itself was always cleanly formatted and minimal in length, which made it very easy to read.
So, did the book hit it's target? I believe it did. The strengths of using Groovy for Domain Specific Languages are drawn out, and the Groovy language is given a thorough overview. Java coders will find this book a reference that will let them start using dynamic features while still staying on the JVM. (By the way, Groovy compiles to Java, so all your existing Java code is usable from Groovy. So you might write an application that's 95% Java and 5% Groovy, and that's just fine with Groovy.) I think this book covered a lot of ground and did it well.
You can purchase Groovy for Domain-Specific Languages from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Re:Well, not quite... (Score:5, Insightful)
Not to mention Lisp, which has been around since the 50s as a tool for solving problems by building domain-specific Lisp variants.
Re:Well, not quite... (Score:2, Insightful)
And there's plenty of DSL material for groovy online already.
Other seriously questionable sentences :
"Groovy is compiled"
"Closures are anonymous methods, packaged in such a way that they can be passed as parameters to other methods." - this is like describing a porsche by stating it generally has 4 wheels
"Meta-programming is using code to write other code"
"and can be used to perform some neat tricks like allowing the user to call methods that don't have a previously written definition."
All extremely misleading statements
Re:Well, not quite... (Score:4, Insightful)
You seem to be equating the reviewer's poor grasp of the subject matter to trying to equate that Java and .NET developers as a whole think they invented or discovered the notion of a "minilanguage" (or DSL in this case). This is simply not true. Secondly, the term "domain-specific language" was being used almost a decade before C# even came out and long before any such things were being built on top of the JVM.
Re:Dynamic Languages? (Score:3, Insightful)
That's a major oversimplification. Groovy is not all that Ruby-like in the end. It has closures, and there's a library that resembles Ruby on Rails on it, but it's not really the same kind of animal. I'd say it's closer to a version of Java that tries to look like a scripting language than it is to a version of Ruby that tries to interact with a JVM.
In newer versions of groovy, you could copy Java code, paste it in a .groovy file, and the groovy compiler will treat it as groovy.
Re:Well, not quite... (Score:4, Insightful)
Re:Well, not quite... (Score:2, Insightful)
Re:Groovy vs Scala? (Score:1, Insightful)
Groovy is dynamicly-typed but it also supports several features from functional programming languages. Programming functionaly in groovy is actually pretty idiomatic.
Re:Parser generators (Score:4, Insightful)
Back in the early 80's, I wrote a control program for a HIPOT tester (in FORTH) which read in a file that looked like:
Test1: Pin 5, 10000 volts, 10 seconds;
Test2: Pin 3, 15000 volts, 5 seconds;
etc.
The control program ran the tests, determined pass/fail, printed failure tickets, etc. The test engineers never knew they were "writing programs", they just thought they were describing a series of test steps to perform.
Re:Let me get THIS straight..... (Score:1, Insightful)
Extremely simple and logical. ITS is a possessive pronoun. Something belongs to the it, whatever the "it" is.
In the same class of words, hers, his, ours, theirs. Yet no one ever writes hi's, her's, our's or their's, do they?
Possessive pronouns are ALREADY possessive, so you don't need an apostrophe. Simple. Logical.
IT ' S is a contraction. The apostrophe shows some letters have been elided. IT IS or IT WAS.
So? Take the it's, replace with IT IS. Does it make sense? No? Then you want ITS.
End of lesson.
Re:Well, not quite... (Score:1, Insightful)
. When I run Grails and change class A, groovy needs some time to recompile, and then complains it can't cast class A to class A.
Thats Grails, not groovy. Grails has its upsides, but the auto-recompile stuff doesn't quite work cleanly yet.