UPDATE: My initial notes have been erased by the ether. It seems that my iOS blogger app ate my homework. So here is the summary.
Last week I was asked the question “why is flowstaller implemented as a DSL or DSL-like instead of implementing the tasks as first class functions” in the language of choice? At the time I was exhausted and not able to give put together a strong argument, however, after reading an article today I found the voice I was looking for.
The article I read made the argument that the author had built a DSL and refined it until it was no longer capable of completing the task for which it was designed. I also read Stack Overflow question/answer… the question was whether or not a physics researcher should implement the research questions in a DSL or in a first class language?
While the first problem is a challenge it’s not impossible. Usually it means one of two things. (a) the DSL was not thought out well enough in advance to account for the major constructs (b) the expectations are too high and some intermediate middle ground is missing. There is a third; the developer has simply lost interest because now there is some impedance mismatch like callstacks, looping, or conditionals that are just no fun to implement.
As for the second; this reminded me why I wanted a DSL for my project in the first place. In my case I was interested in merging DSLs from Chef, Puppet, Ansible, and SaltStack. So on the one hand I needed a DSL engine and on the other I needed the libraries to execute the tasks across all of the DSLs. However, I was reminded that the physics problem was the same and yet different. By starting the researchers with a DSL they are immediately productive. Then, over time, as they learn the DSL and possibly one or more of the underlying programming languages then converting their DSL-based applications to a first-class language should be a simple matter.
So contrary to my previous posts there is a place for a DSL in today’s modern development environments.