JavaOne – DSLs and Dynamic Languages

09 May 2007 JavaOne – DSLs and Dynamic Languages

Big day at JavaOne today with the keynote. There are a lot of people here. Mark’s already covered the keynote, so all I’ll say is this: that room was so big I reckon you could fit at least two Boeing 747’s end-to-end in it.

Straight afterwards I went to a presentation on Domain-Specific Languages (DSLs) by Neal Ford of ThoughtWorks. Thanks to Martin Fowler I already had a basic understanding of these, but this talk helped flesh things out for me. And it also explained how dynamic languages can build better DSLs.

First, some background. For those who don’t know, DSLs are small psuedo-languages targeted at very specific problem domains. Put simply, they aim to make the code for solving a particular type of problem more natural to read.

There are actually two ‘types’ of DSLs: internal and external. Internal DSLs are built on top of some existing language – for example Java or Ruby – and leverage that language’s syntax. External DSLs are full-blown languages in their own right with their own dedicated syntax and are built using compiler generators like Antlr. I’m going to be talking about internal DSLs here.

You can build a DSL in Java, although it’s not the best language for it because it’s so highly structured. Good examples of Java frameworks that provide a DSL are JMock and Hibernate’s Criteria Queries. Each of these APIs is still Java, but in each case the API has been contrived to make reading the code a little more natural to the particular problem domain.

DSLs are often used for things that are better expressed in a declarative manner instead the standard imperative approach that most popular languages promote. Whereas up until recently we all used XML – with all of its attendant problems -for declarative coding, now we have the opportunity develop more customized solutions on a case-by-case basis.

One of the key messages I took from Neil’s talk was that as we move along the spectrum of language ‘dynamic-ness’ – from Java through to Groovy, then on to JRuby and Ruby – the ability to construct concise, natural and expressive DSLs increases.

Ruby has already proven itself as an excellent language for constructing DSLs, a prime example being Rake and XML Builder. People are even referring to Rails as a DSL for web applications. Furthermore, with the growing popularity of JRuby, new frontiers have opened up.

One of these has already been pointed out by Julian Doherty when he asked whether JRuby can save Swing. A JRuby DSL for declaratively building Swing interfaces could be a compelling alternative to explicitly assembling them yourself. It could also provide a more natural co-existence between the declarative code used for describing a view and the imperative code that describes what an event handler should do (having seen Flex‘s rather disturbing use of XML with ActionScript embedded in CDATA tags, I think this is definitely worth keeping in mind).

Neal conceded that building DSLs can be hard, but that using them should be easy – that’s the whole point. Furthermore, he advised that in building one, you first write down what you want it to look like, and then work upwards towards that goal. This stops you getting too bogged down in the implementation before you’re clear what you want to achieve. And finally, he urged us to keep them as tightly focussed as possible.

Whilst DSLs may seem a little esoteric to you, we’re already using them everyday without knowing it. When you construct a UI with a complex API like Swing or write an Ant build script, you’re already using a DSL. It’s just that, in each of these cases, the language that the DSL is built on (Java in the case of Swing and XML in the case of Ant) has been stretched a little too far. So why not start thinking about how to make it more natural? Creating DSLs with more dynamic languages could well be the way to go.