BT
x Your opinion matters! Please fill in the InfoQ Survey about your reading habits!

External DSLs: Success and Failure Factors

by Sadek Drobi on Dec 07, 2008 |

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.  

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

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.

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

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.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

3 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT