Due to a recent discussion I had to spend some time thinking on who should build a DSL (Domain Specific Language) and why, as opposed to who should use it.
Let’s start from some basic assumptions:
- Good abstractions must be intuitive and make life easier, not harder.
- DSLs are a must-have for most application scenarios (I’m not thinking only to software)
- Finding the right abstractions for defining a DSL is hard and time consuming
- Domain experts basically care about maximizing their productivity in working in their domain, but do not probably willing to spend huge amount of time defining methods and tools for that.
That’s why good DSLs do not come out of the blue everyday. And despite I can be a fan of language design and open DSLs, I think this is fine as it is.
The final goal of MDSD (Model Driven Software Development) is not to make every developer a language designer. The goal is to have good DSL designers that build good DSLs for the right audience.
Our experience with DSL visual languages in the Web context (WebML, see http://www.webml.org) is that it took years (together with tens of industrial experiences and thousands of users) to refine and polish a good language. That’s why I’m saying that a process like this can’t be in charge of any developer or designer.
Then, obviously a good DSL should be open for extensions and closed for modifications (ahh, the good old open-close principle!).
Finally, about tools: good tools must go with good languages. And I think that domain specific architectures (shall we call them DSAs?) should pair DSLs. As we say that one language does not fit all needs, I would say that an architecture may not fit all languages.
This could give you the impression I’m somewhat skeptical with respect to generic model-based tool/editor generators (and that’s actually true). Tools, design interfaces and publishing architectures should be tailored to the users, otherwise we fall back to the problems that should have been solved by abstraction and simplicity of the DSLs.
