External DSLs: Success and Failure Factors

Posted by Sadek Drobi on Dec 07, 2008

Sections

Architecture & Design,

Development,

Operations & Infrastructure

Topics

Open Source ,

Domain Specific Languages ,

Architecture

Tags

DSLs

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.  

1. Back to top

   Erlang is not a DSL

   by Humphrey Bogart

   Erlang is not a DSL. It isn't specific to any particular domain.
   
   There are far more DSLs for data than for programming. Look at all those industry XML standards. Each one could be more succinctly and naturally expressed in a DSL.

   Reply

2. Back to top

   Re: Erlang is not a DSL

   by Angelo Schneider

   I second that. Furthermore I like to point out, the opposite of the authors statements is true. Ericsson continuously dropped in market share, share values, product quality and time to market (product cycles) when they switched from Erlang to C++. Erlang and the products built with it where not only state of the art but also bleeding edge technology. Now Ericsson is just one among others and has to compete with them on their level.
   
   Regarding DSLs and hiring domain experts, first I have to emphasize that a true DSL is a very limited language, with a very focused scope. If the scope is to broad then it is likely approaching a full fledged language in features. That basically means a good DSL should be learnable in a day or two. And that is what I expect from a domain expert. If someone calls himself an expert he should be able to express matters of his work in simple sentences, in his own "spoken DSL" ... the step to crafting, teaching or just acquiring a foreign DSL crafted by someone else should not be difficult.
   
   Nevertheless the hint to open source the DSL or to form some kind of consortium makes really sense.
   
   But bottom line: a DSL is not really targeting developers!! A DSL is for Domain Experts!! Yes, this can be developers, e.g. consider a DSL to configure dependency injection in Spring. However DSLs are mainly aimed to give the end user or other stakes holders the option to configure or parameterize or even adapt, in other words "program" an application or a system of applications.
   
   Regards,
   Angelo

   Reply

3. Back to top

   Wrong comparison

   by Tjerk Wolterink

   Normal general purpose languages are compared with DSL's in this articles. But the whole point of a DSL is to be domain specific.
   And like Angelo says: DSL tend to be very simple, and they are not hard too learn. Even for non-programmers.
   
   So if DSL are used in the way they are intended to use they should make things simpler.

   Reply

• Older >