Internal DSLs are good, external DSLs are bad (discussion)

Tweet about this on TwitterShare on FacebookBuffer this pageShare on RedditShare on LinkedInShare on Google+Email this to someone

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?

Tweet about this on TwitterShare on FacebookBuffer this pageShare on RedditShare on LinkedInShare on Google+Email this to someone
Comments
  1. Acher
  2. Andreas Leue

Reply

Your email address will not be published. Required fields are marked *