JAX 2009: Practical Domain-Specific Languages with Groovy

(Disclaimer: this text was written while listening to the presentation – please be forgiving with errors that might result from both listening and writing)

Guillaume Laforge is my next stop in the JAX presentation route. He talks about “Practical Domain-Specific Languages with Groovy”. I’m a huge fan and supporter of DSLs believing them to be the next big thing in truly enhancing developer productivity. Since I also believe that we are just scratching on the surface of what we can achieve with DSLs I was curious about what Guillaume would have to show, especially since Groovy seems to be a pretty natural fit for many types of DSLs.

Sadly the acoustics were not that great from the start and only later on improved, so this presentation was more challenging than it should have been thanks to Guillaume otherwise great presentation skills. But back to the presentation… Guillaume BTW seems to be one of the few JAX presenters who has read Presentation Zen, one of my favourites. Nice slides, Guillaume!

Guillaume startet his actual presentation by addressing the typical communication problem between subject matter experts and IT specialists – we just don’t understand each other very well causing all kinds of problems during requirements engineering and ensuing implementation attempts. Thus DSLs seem to be a natural idea to be able to express business requirements in a more natural way. One important and often neglected bit of advice was to allow subject matter experts to participate in DSL design – because they must be able to win something by using it later on.

His first basic thesis is that DSLs are about readability which I strongly support. He started out with an example from an actual project (although the “bad example” in Java was not real). Guillaumes estimate for the (typical) Java example was that about 20% of the actual characters related to the domain problem and the rest was boilerplate. With a nice Groovy conversion he raised that rate to more than 80%. That example then served as the red line to illustrate various Groovy capabilities for building DSLs. He also rightly indicated that Groovy is used for textual DSLs, IMHO a minor but important point, because sometimes graphical DSLs are a lot more helpful (just think of musical notes).

Guillaume proceeded to present the various Groovy syntax features that make Groovy scripts a lot shorter than Java as the first layer of DSL building. Nothing new here, you can gain that information from about any Groovy tutorial. But then he proceeded to show examples like “take 1.pill of: Chloroquine, after: 6.hours” – and that’s really nice. Additionally he showed nice examples with closures, operator overloading, etc. to show how to build much more readable expressions.

Then he proceeded to the second layer of DSL abstraction – using the meta object facility which routes calls to properties through specific methods in order to resolve them. After that he illustrated the use of the ExpandoMetaClass as a DSL for class extensions. From there he went over the builder pattern (e.g. used in the MarkupBuilder) that can be used to build nice textual DSLs of a certain structure by intercepting all calls on the meta object facility level. Then he showed how to express things like “100.meters” using the concept of Category. He additionally explained compile time AST transformations introduced in Groovy 1.6 which allow you to completely modify the abstract syntax tree resulting from your source code before it is compiled. It allows for very tricky and powerful transformations. Due to the high flexibility of this approach the old rule holds: With great power comes great responsibility – although you probably could exchange all minus signs for something else you probably do not want to do that. Guillaume also showed helpful annotations like e.g. @Delegate, that allow introducing implicit AST transformations into the code in a very readable manner. As an example he demonstrated the use of the Spock framework which changed the meaning of labels to be used in specifying test cases with a behaviour driven approach. Very neat.

Next Guillaume provided hints about how to integrate Groovy DSLs into your program, mainly consisting of the following three approaches:

  • Using the Java Scripting API
  • Using the GroovyShell or the GroovyClassLoader
  • Using Spring namespaces

He provided the following important advice for designing DSLs:

  • Start small and focus on the most important concepts. No overengineering, please.
  • Involve the subject matter experts and allow them to shape “their” language.
  • Create a tight feedback loop.
  • Stay humble and don’t believe you can solve all problems on your own.
  • Play it safe in the sandbox by preventing users of the DSL from doing evil stuff (e.g. by using security managers, the classloader, etc.)
  • Test, test, test.

Overall a very solid presentation that gave a very efficient overview of the most important concepts and served as a great starting point for individual experiments.

Comments are closed.