Domain-Specific Language Engineering (2007) [pdf]

[bbrazil]

The main challenge I've observed with DSLs is maintaining and growing them over time. It's not unusual for a DSL to grow organically based on individual use cases that seem like a good idea, and the end result is a language that's not quite consistent or orthogonal.

"A foolish consistency is the hobgoblin of little minds" is the rallying cry of those who only have to deal with a small number of libraries/languages/tools/systems, and don't realise the true externalities of having to memorise hundreds to thousands of special cases. Small consistent languages are good languages.

[sklogic]

To avoid this issue DSLs must be highly modular, which is easily achivable if you're implementing them as eDSLs on top of a meta-language (i.e., mixing DSLs is trivial and interop is not a problem).

[taeric]

If the language reflects the domain of the problem being solved, and it still grows; not sure there is really a better way.

Artificially constraining it to a consistent API is just going to get you into the same problem many functional advocates are having. Which is the confusion of everything being covered by a few names.

[ExpiredLink]

Not only maintaining and growing a DSL is challenging but also designing it at first. You need a lot of both domain and technical experience to achieve a half-decent result. That's why the "hype" around 2007 didn't lead to widespread practice. DSLs are costly.

[sjorsvb]

Funny, I was a student of his and as soon as I read the title, I thought it might be his work :)

[gronkh21]

Interesting article