I don’t know why or how I ended up in this Lamda The Ultimate website but I thought you may enjoy this 2012 discussion on Internal vs External DSLs with Erik Meijer and William Cook (among many other things, co-author of Ensō: Don’t Design Your Programs, Program Your Designs presented in this same blog) and many others.
As a starting point for the discussion let’s take this definition from Martin Fowler “An internal DSL is just a particular idiom of writing code in the host language. So a Ruby internal DSL is Ruby code, just written in particular style which gives a more language-like feel. As such they are often called Fluent Interfaces or Embedded DSLs. An external DSL is a completely separate language that is parsed into data that the host language can understand”.
Erik started the controversy with this highly provocative statement:
I fully ascribe to Hudak-style embedded DSL, which really just are well-designed APIs. External DSLs on the other hand are like puppies, they all start out cute and happy, but without exception turn into vicious beasts as they grow up (make, XSLT, regular expressions, …).
and from there, all hell broke loose, with supporters of external DSLs claiming that better tool support in the shape of language workbenches made the statement untrue or at least made the cost of creating those DSLs acceptable
external DSLs are ugly: I think they are, but so are death and taxes
while internal DSLs fans discredited the tool support argument by saying that this was only a small part of the problem.
External DSLs … have no mother language to depend upon, and so they must reinvent much general purpose behavior.
Anyway, read the whole discussion and see if you can make up your mind. Which side are you on? Internal DSLs, External DSLs or both?
FNR Pearl Chair. Head of the Software Engineering RDI Unit at LIST. Affiliate Professor at University of Luxembourg. More about me.
Passionate debates, I hope science will provide some answers and innovative techniques.
My answer so far: both! There are clearly pros and cons on both sides (from the discussions but also from our own experiences). So we hope to have “metamorphic” domain-specific languages for transitioning from external shapes to internal shapes (and vice-versa).
More details here:
https://hal.inria.fr/hal-01061576
http://fr.slideshare.net/acher/metamorphic-domainspecific-languages
It’s (surpise) a matter of abstraction context (level, domain…).
Internal DSLs most often use a concept which is not equally well supprted in the container language, but typically has long history of support in another domain.
E.g. queries; SQL like stuff is old, matured, and (on it’s level) well modeled.
Not so in #th Generation PLs. Here things are about emerging, yet a *good* abstraction on that level is still to be created (imho).
External ones often start out as “not technical, but XYZ focused” (XYZ e.g. “business”); nevertheless, what is done with these languages, is e.g. just “fancier programming”, since the respective abstraction is not comprehensive enough.
So one ends up with reinventing the (programming) wheel – but for *that* abstraction domain there’s already a good solution existing: programming languages.
Nevertheless, I believe in internal as well as external DSLs – if all pieces of the game are choosen wisely.
In my opinion the benefits of Internal DSLs are very small, as is the cost of creating them. They are cute but basically provide no real advantage.
On the other end External DSLs in the right contexts can
1) Increase productivity enormously
2) Reduce errors by orders of magnitude
3) Make possible to involve domain experts in software development
They bring huge benefits but yes, it costs to produce them. Mostly because of the tool support around them (editors, debuggers, simulators, etc.).
I do not think there is really any competion between the two: it is like comparing a skateboard to a space shuttle. They are both means of transportation but what they permit to achieve is very different.
And yes, it is true that internal DSLs could be built by any developer while external DSLs require competences in language design, otherwise there is a risk of the language evolving in a complex thing difficult to maintain.