External DSLs: Success and Failure Factors

Given the growing interest in Domain Specific Languages (DSLs), Michael Feathers provides some reflections on external DSLs, their advantages and pitfalls as well as possible success and failure factors. He stresses that while external DSLs “give you a freer hand" and allow you creating "a complete syntax and tune it directly to a particular domain”, they represent an important commitment for companies using them. And this “commitment doesn’t end when the initial implementation is done”. 

Because of the specificity of external DSLs, they may induce significant maintenance costs since there should be in-house expertise for adapting DSL to occurring changes. For the same reason, the use of external DSLs complicates hiring and, more specifically, hiring of domain experts:

Let’s face it, if you are looking for a job what do you want to have on your resume?  A language used by precisely one company or one that is known or used throughout the industry? […]

One very public example is Erlang.  People are paying a lot of attention to Erlang today, but we shouldn’t forget that it was dropped by Ericsson in part because they were concerned with their ability to hire and train developers.  Many people know the story of Erlang, but what they don’t realize is just how common this scenario has been in the industry.  I get to see a lot of legacy code in my work, and a good amount of it is in homegrown languages that companies have trouble supporting.

So, Michael Feathers argues that, with regard to external DSLs, “success is a function of far more than the technology”. Their potential can only be successfully exploited if company objectively assesses the needed commitment and can assume it “even under adverse business conditions”. In addition to that, Feathers outlines a couple of ideas about how to reduce potential costs of external DSLs:

1. If you are creating an external DSL, consider open sourcing it or, at least, consider forming some sort of an industry group around it.  This partially externalizes the cost of maintenance and avoids hiring trouble. 
2. If you can’t or won’t open your DSL(s) to the outside world, make sure that your developers are not expected to use them exclusively.  If you don’t, you can expect to pay higher wages for developers of equivalent skill than you would otherwise.  In negotiations, they will factor in the cost of working with little known technologies.

Considering embedded DSLs could be another alternative since, according to the author, they are easy to construct and can yield many of the same advantages as external DSLs.