At the SPA conference on Monday I took part in two sessions and one BoF on Domain-Specific languages.

First up was Juha-Pekka Tolvanen with a 150 minute tutorial on Domain-Specific Modelling for Full Code Generation.

This session was pretty wide-ranging beginning with the motivation for using DSM, differences between Domain-Specific Languages and conventional programming languages and conventional modelling languages like UML (according to JPT most UML constructs don’t raise the level of abstraction).

Benefits of DSM were presented with supporting case studies - 5 times faster to develop applications in one case, 3 times faster in another case, 10 times faster in another case. An increase in application quality is also commonly found.

JPT also described different roles on a DSM project - with experienced domain developers designing and creating the DSLs and Generator(s) and less experienced developers, and in some cases business experts, using the DSL to model new applications.

A nice part of the session was a chance to design a DSL for an interactive TV application. We had to put ourselves in the position of a developer supporting a programme producer who wanted to add elements like menus, text and polls as interactive content on their programmes. The problem comes from an earlier OOPSLA Designfest. (Note - at time of writing the link to the actual problem description from 2004 was broken but I have contacted the DesignFest webmaster to get them to fix this).

To solve this problem we had to think about the objects, relationships, roles, attributes, states and actions that had to be modelled to create such applications i.e. we had to create a DSL for the producer. One useful heuristic I use when tackling these types of problem is to imagine what elements would be included on a palette in the tool to be used byt the producer. This tends to help me identify the major domain elements while also helping eliminate elements that are too implementation-focussed from the DSL.

One point JPT noted was that users of such languages often complain about the notation - this can be solved by allowing them to define the notation themselves - not (really) possible when using standard modelling languages.

Finally, I asked JPT whether some languages were harder to generate than others. He noted that any language with global structure would be harder to generate. Similarly languages where indentation is significant (such as Python) are harder because you have to keep track of your indentation depth. At the BoF session later (described below) I hypothesized that increasing use of DSLs to generate code would cause such languages to become less popular.

Later that day I attended Peter Bell’s session Domain-Specific Languages: Design and Evolution. This was a shorter session than JPT’s and it covered some of the same ground although from a different perspective.

Like JPT’s session a good part of Peter’s session looked at creating a DSL for a small problem domain - in this case each group had to tackle the problem of creating a DSL to specify import transformations for data coming into a content management system.

I must admit I struggled a bit to identify exactly what was required but my heuristic of identifying what would be in the user’s palette helped us eliminate database tables from our completed DSL. Other groups were more successful.

From 21:00 I ran a Birds-of-a-Feather session on DSLs. I’d spoken about this possibility with JPT and Peter before the conference and happily they both agreed to participate. The plan was to run the session for an hour or so, depending on the level of participant interest. At 21:05 it was looking as though there wasn’t going to be any interest but people gradually started drifting in and I think we ended up with around 10 people attending besides ourselves.

The idea was to make the session as informal as possible so we gathered in the sofa area with a beer or two. To get things started I had a few questions to ask JPT and Peter:

• What is a Domain-Specific Languages?
• What is the difference between a DSL and a general-purpose programming (or modelling) language? (You work at a higher-level of abstraction)
• Why is there a growing interest in DSLs? (Microsoft are working in this area, developers are interested in being more productive - Java, C++, UML etc. haven’t raised the level of abstraction much)
• How do you get started with DSLs? What do you do with legacy code? (Build a reusable framework from your legacy assets, start with a small domain. Can be hard because this often requires the best programmer.)
• How do you sell the idea to management and the rest of your team? (There are now plenty of successful case studies. Get a small problem working first, grow your language)
• Does the approach scale? (Yes, huge models have been built. (And anyway, why would it have more problems scaling than a conventional language given that DSLs work at a higher-level of abstraction?))

By 23:30 I was pretty tired so called a halt to the BoF. We’d managed to stay on-topic for most of the 2.5 hours and I certainly felt the BoF was worthwhile so thanks to JPT and Peter for agreeing to share their experience.

I have a copy of JPT and Steven Kelly’s new book Domain-Specific Modeling: Enabling Full Code Generation on order so expect more on DSM later…