How to do E/DSLs successfully?

It seems to me that there are some E/DSLs which work well (well enough, sometimes debatable) such as Makefiles. Then there are situations where people have E/DSLs that maybe even sound good, but end up not really working out as intended; the abstraction cannot fail to be come leaky but fast. I wonder if "business rules" tend to fall into the latter category.

Might anybody have thoughts on what tells you when an E/DSL can work? Or what approach one should take given the nuances of a particular situation? Or at least what are the aspects involved? There are some situations where you really can hand it over to non-programmers and live to tell the tale, and others where doing so is a quick route to doom.

Thanks for any thoughts.

Error messages can suffer

Error messages can suffer without careful effort. This happens in the public version of Flapjax (firebug helps describe the lambdas used under the covers in stack traces, and I think the reported message queue backslice in traces are potentially a benefit). Based on conversations with one of the architects, Fortress struggled a lot with its library approach.

Unless I misunderstood the 'E' in E/DSL.

By lmeyerov at Fri, 2008-08-22 07:09 | login or register to post comments

Makes sense

Since E/DSLs (E == embedded, which means it is a library/macros in a more 'common' langauge, which means you could mix and match rather than being solely restricted to the DSL) are hopefully trying to raise the abstraction level, it makes a lot of sense that the whole error thing could be complicated; ideally the errors would be about the appropriate layer with relevant terminology. (concrete example, not to pick on anybody: Clojure's errors include stack traces of the compiler which is a Java program. those errors are not really about the Clojure syntax error i made and i think they overly greatly obfuscate things, they are really just frustrating noise to and end-user like me.)

By raould at Fri, 2008-08-22 18:57 | login or register to post comments

DSELs

We usually used the acronyms DSL and DSEL... Anyway, I suppose that E makes quite a bit of difference.

The issue you raise can be divided into problems that stem from the domain abstractions and problems that relate to the expressiveness of the language, the latter, in the context of DSELs, become questions about the integration of the DSL and the host language.

By Ehud Lamm at Fri, 2008-08-22 19:08 | login or register to post comments

Rules of thumb?

It does indeed seem that the topic can be deep in that there are many choices and nuances.

Might people have summary rules of thumbs about how they decide when to Embed vs. not to? And, more generally, what dangers there are in going down a DS{E}L route, and how to manage them?

(Among other personal DSL experiences, I recently find myself in a situation with some JVM scripting being used by non-devs, and the whole thing is less than safety / debugging / proof friendly, so I'd like to learn how good folks think when faced with the decision of going the DS{E}L route, to complement my own arguments.)

By raould at Mon, 2008-08-25 19:38 | login or register to post comments