At OT2004, I ran a workshop on domain specific languages. OT is where the UK experts in software development gather each year, and so the people attending a workshop generally know more than whoever is running it. It's a great way to get some good ideas about a topic you're working on.
So here's a brief intro to the topic, and some of the ideas that came out of the workshop part.
What's a Domain Specific Language, and Why is it Important?
A domain specific language is, well, a language specific to a domain.
If you happen to be writing software for phone switches, you probably use a Call Processing Language, which describes the process each call goes through -- the state changes from dial tone to dialling, to ringing or engaged, etc. There is some kind of compiler or generator that creates the code for the phone switch from the CPL statements; generally, the generator will produce a mixture of code, tables, database schemata, etc. The benefits of using CPL rather than writing the code directly are:
Domain Specific Languages can be thought of as an extension of the idea of Software Product Lines. The generic framework provide the architecture that encompasses a wide range of solutions; the language provides a medium for specialising the framework to a particular set of requirements.
DSLs aren't new, though they have tended to be more visible in horizontal domains: SQL, regular expressions, HTML, workflow, scripting languages. We believe that, just as in the case of call processing languages, they can be equally useful in vertical (business specific) domains such as financial processing.
In fact, designing a DSL can be a useful strategy on any 'big' project. Designing a phone call processing language pays its way even if you only have one phone switch to develop: partly because of the separation of implementation detail from requirements; and partly because the process of designing the language forces you to think about the key concepts in the requirements domain.
Learning points from the workshop
The workshop took the form of a series of exercises performed in groups. Participants were asked to develop DSLs for two different domains (baggage handling and fast food). (benjaminm said some nice things about it.) These are points that came up in the ensuing discussions:
Designing a DSL :