My Experience with Corporate DSLs
Tuesday, 2 December 2008
Michael Feathers provides some guidance how to mitigate the downsides of a custom DSL.
They are
- Open sourcing it, preferably to industry group
- Pay developers higher wages – implicit is the dead-endedness of this particular technology careerwise
- Using embedded DSLs (embed interpreters?)
The DSLs I’ve come across are a configuration language for deploying applications to desktop, a forms language for report-writing.
Initially, the application deployment case was simple, just a list of filenames. Over time, it grew
- error handling,
- version checking,
- platform checks,
- if-then-else flow-control,
- logging
- and application tracing
The language for report writing ended up being a language for writing general forms, then scripting reads and writes to a custom database. In both cases, developing a custom interpreter also required a custom runtime and a custom debugger.
Microsoft’s modelling initiative using M promises to make IDE development for the custom DSL easier, but in the key area of debugging, there appears to be no solution.
I believe this to be a fundamental problem. There are no debuggers for declarative languages. HTML cannot be debugged. Neither can Excel (although it’s auditing features come close).
This is bad news for DSL’s which require flow-control that does not match conventional imperative programming, since most embeddable interpreters are imperative engines. Want to write a workflow DSL interpreter using an existing interpreter? Good luck. Want to write a data flow DSL using an existing interpreter? No chance there. You’ll have to roll your own, and provide all the debugging facilities yourself.
You should follow me on twitter here