Slashdot Mirror
Groovy For Domain-Specific Languages
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.
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
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.
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.
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.
"Writing DSLs has been done for many years, but was largely an undocumented process until just recently."
Not to discount the review, but that's a bit misleading. There are plenty of books dealing with lex/flex and yacc/bison, which have been used for years to do the same things in a precompiled manner. .Net and Java "just recently" discovered this and have popularized the term DSL for it.
Doesn't anyone remember FORTH? That's pretty much nothing but a domain specific language.
You CS guys and your "layers" of abstraction! I tell ya.
So does birth control to a CS guy mean banging some chick you met at the bar and telling your wife that the bar chick was just an abstraction and you were really making love to her? The bar chick was just a layer in your relationship?
The more important question is, does it work?
RIP America
July 4, 1776 - September 11, 2001
Far out, man!
"A DSL is a purpose-built language, with it's own verbs, "
You software lunatics are continually re-inventing dozens of languages, each looking like an explosion at a typesetter company, but are unable to grasp the simple distinction between it's and its?
Scala also runs on top of Java and is purported to be useful as a DSL.
I eat only the real part of complex carbohydrates.
Perhaps a candidate for the latest "revelatory" term. IMHO tailoring languages like Groovy or BSH is a lot of fun and can be pretty easy to do, but it's far from a true "dynamic language". Poster above is right about lex / yacc / bison. Also in the C++ world I can recall reading about boost's "spirit" library. Although I think more of these as "parser generators" (perhaps a less revelatory term), at least that is what they were intended to be. Groovy and BSH are mostly nice cause of how they so cleanly interface with java at runtime (both are capable of resolving references via the classloader). I've always found that using them has been a pretty ugly exercise.
"Domain-specific language" is nothing more than a marketing term, most frequently used by those wishing to sell books, and by consultants wishing to sucker you into taking expensive courses that "teach" you stuff you already know.
Like "cloud computing", "Ruby-on-Rails" and "NoSQL", it's just a re-branding of old, if not outright ancient, technologies and techniques.
However, they are useful when hiring people. If you're interviewing somebody and they start talking about how they need to develop some domain-specific languages while creating a NoSQL-backed Rails app running in the cloud, you know right away that they're packed full of bullshit, and shouldn't be hired.
But she's nothing compared yo your mom!
Slashdot's rate-of-post filter: Preventing you from posting too many great ideas at once.
Parser generators are a well-studied problem, and there are good solutions. Unfortunately, the "dynamic scripting language" people don't seem to be much into parsing theory. Trying to get a complex grammar to go through yacc or bison isn't easy, but at least once the parser generator will accept it, you know you've hammered out the ambiguities. It's much easier to get parsers from systems like "pyparsing" to sort of work, but you have to run many test cases to get them to work right.
(I'm currently writing a parser with "pyparsing" for US postal addresses. There's a trivial one available, but it doesn't handle the hard cases, and I had to essentially rewrite it. This is not fun. Some current fails: "969 Edgewater G370", "32545B Golden Lantern 147", "3853 7 Trees Blvd". It's not too hard to get to 98% success; then there's a proliferation of special cases.)
Best. Comment. Evar.
lex/flexx are front ends for domain specific languages. they parse things you then have to implement a backend for. THey are great achievements but not stand alone. I think the point here is how you implement the end to end DSL. There have been other books for example that talk about using yacc/lex with objective C to make a complete app.
As for groovy, I've never used it since python and perl I know and they are more mature. But I have to admit when you look at groovy it seem to me to be the holy grail of scripting languages. The one thing all scripting languages lack is a really seamless way to go from your script prototype with duck-typing to a faster compiled version with real static/dynamic typing. All the approaches in python are a kludge (c-python, jython etc...). You can call C or fortran from python and perl (i.e. swig boost, f2py, ...) but it's an interface with a deep moat. in groovy the syntax stays almost the same as you move from the script to the compiled java. THe way you import things is so similar it makes tweaking a script into a compiled version trivial and more importantly can be done incrementally as needed. And it comes with all the legacy libraries of Java for free.
It seems like the ideal modern script language. You just have to get over Java-phobia.
Some drink at the fountain of knowledge. Others just gargle.
I've used BeanShell for scripting in Java, so I'm just wondering what advantage Groovy would have.
Is this an example of a domain specific language? I'd imagine it'd run on the English VM but would probably cause a core dump in the brain pan.
I'll have to add the Domain Specific Language to my proposal for cloud computing to be presented at the management consultant meeting.
try { do() || do_not(); } catch (JediException err) { yoda(err); }
There should be two questions asked before any new language is undertaken:
1 - Does it allow you to do something that couldn't be done before?
2 - If not, does it allow faster development or better performance than an existing technology?
3 - If not, are all alternatives in licensing you don't agree with?
If not... don't... fucking... start. Seriously, we don't need yet another way to do the same crap we've already been doing.
"There should be two questions asked before any new language is undertaken:"
Make that 3. Yay for proofreading.
I'd just like to point out that each of Wagner's other Packt reviews were highly favorable. This is unusual for a Packt book, particularly when it comes to their editing process--most of us play "which is the first page with an error", and it's always within the first dozen or two pages. Every single one of his book reviews is a Packt books. Every single one of them is a good review with essentially no negative comments whatsoever.