Domain-Specific Language Engineering (2007) [pdf]

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.95.8432&rep=rep1&type=pdf

by davidjnelson • 11 years ago

38 30 11 years ago

citeseerx.ist.psu.edu

gronkh21• 11 years ago

Interesting article

bbrazil2• 11 years ago

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.

sklogic13• 11 years ago

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).

bbrazil2• 11 years ago

I'm not following you. I'm thinking of things like https://github.com/prometheus/prometheus/issues/482 where core elements of a language don't behave in a predictable manner (in this case == has two distinct modes). That's a simple example, more structural issues can be compound by workarounds and lead to a lot of complexity growing over time.

ExpiredLink5• 11 years ago

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.

scottious• 11 years ago

I'm currently developing a DSL. I definitely agree with what you're saying. Domain and technical expertise are needed in abundance. Writing a spec is HARD. It takes a certain perseverance to learn good parser design (I've written a great parser generator and I still feel inadequate in this area sometimes).

DSLs are costly. My concern is that the cost will outweigh the benefit and people won't like it and we'll be suck with it. My hope is that it'll stabilize and be expressive enough to fit everybody's needs.

Did you ever write a DSL used in a production environment? How complex was the DSL, more declarative or closer to a general purpose language?

zapov3• 11 years ago

I actually find compilers for transformation of DSL AST to target languages much more costly then designing the DSL syntax.

But that's probably because I don't think using templates for code generation is good enough. At least if you want to do something interesting with it.

Language workbenches cut down the cost of DSL design to minimum, but more interesting problem is providing valuable output from it.

sklogic13• 11 years ago

Not only maintaining and growing a DSL is challenging but also designing it at first.

It's not that challenging if you do it the right way.

DSLs are costly.

Plainly wrong. DSLs are the easiest and cheapest way of eliminating complexity. You simply have to follow a proper discipline and use the right tools.

When I build a DSL, it's rarely more than 100 lines of code including literate comments, and the resulting DSL is a proper optimising compiler with debugging support, and this new DSL is immediately supported by an IDE (at least with syntax highlighting, autoindentation and autocompletion).

taeric• 11 years ago

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.

sjorsvb• 11 years ago

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

Domain-Specific Language Engineering (2007) [pdf]

Related Stories