Domain-Specific Languages

Freddy Mallet asks what is the difference between an Executable Specification Language and a Domain-Specific Language. They are clearly closely related, but I think there are some differences that are significant.

The main problem, from a purely technical viewpoint, is that being “domain specific” is, by itself, not sufficient to ensure that a language is defined at the level of specifications (what), rather than implementations (how). For example, we might say assembly language is domain-specific. Matlab is a domain-specific language, but it is essentially a programming language. One might even argue that all languages are domain-specific. This includes C, FORTRAN, COBOL, Lisp, PHP, Perl, Bash, and even Java. It is difficult to think of them without immediately thinking of their domain of application. I have often felt that many languages created by programming language researchers, including ML and Haskell, tend to be best at writing compilers, interpreters, and type systems… because these are the kinds of programs that programming language researchers are interested in writing. The danger is when you believe that your own narrow application domain is representative of the kind of programs that everyone wants to write.

There is also a lot of uncertainty about what a “domain” is. To some people domains are defined by a kind of product/service, e.g. insurance, real estate, banking, heavy manufacturing, retail, transportation, hospitals, and government. These are sometimes called verticals, or vertical markets. Horizontal domains are functional areas that cut across industries, including human resources, logistics, legal, etc. In programming we distinguish between problem domains and solution domains. Most, but not all, domain-specific languages are tied to a particular horizontal problem domain, often linked to a widely-used but specialized solution or specific kind of problem.

Finally, there can be domain-specific languages that are not directly executable. One might say that UML fits into that category. Or specialized logics. That last issue is annoying, because it is usually the limitation to a specific domain that enables a specification language to be executable. This means that being domain-specific is often necessary, but alone is not sufficient, to ensure that a language is an executable specification language.

Thus I find that the characterization “domain specific” is not a precise term for the kind of language that I am focusing on.

On the other hand, the phrase “Executable Specification Language” combines two terms that tend to be at odds with each other. When we say that language X has the property that X is executable (you can run it!), and that X is a specification language (more at the level of “what” than “how”… that is, a “what-oriented” language), then you end up with a very precise description of a set of interesting languages. If you compare the sets of languages defined in this way:

L1 = what-oriented  and  runnable

L2 = domain-specific

You will find that L1 is a subset of L2. But I believe that L1 contains exactly the languages I’m interested in, while L2 includes many languages that are not interesting to me. That is one reason why I used the unconventional phrase “Executable Specification Language”. The other reason is that I wanted to make an analogy with verification and lightweight verification, to cast domain-specific languages into a new light.

But in practice, current common usage for the phrase “Domain-Specific Language” seems to be fairly close to what I have in mind when I wrote “Executable Specification Language”. To add to the confusion, there is also a common usage of the term Executable Specification in the context of automated testing and agile development. In this context, the executable specification is really a test case that can be run to check if a system meets its specification. The key point is that these are specifications, not languages.

In conclusion, I apologize for introducing yet another term. However, it is sometimes useful to think about well-known ideas in new ways.

Comments (4)

  1. Freddy Mallet wrote::

    I understand your view point and agree that a domain specific language is not always an executable language. So why not introducing a new term but using “Executable DSL” would have been far less error prone :-).

    Moreover, Cobol, java, C, … are definitely general-purpose programming languages.

    Wednesday, November 9, 2011 at 5:44 pm #
  2. w7cook wrote::

    Adding “Executable” does help on one side, but it doesn’t ensure that the language is focused on “what” rather than “how”. Thus we could call them “Executable Specification-Oriented DSLs”. But at that point the DSL part is not providing much value. In any case, I’m not seriously proposing to change the terminology. What I’m trying to do is to introduce some nuances in meaning to how we think about DSLs.

    As for your second comment, it is import to distinguish the concept of “Turing-complete” from “general-purpose”. Any Turing complete language can in theory be used to do anything. However, I don’t think you would seriously propose that C should be used for scripting web pages. In other words, C is not as good as JavaScript for some purposes. That is what I mean by domain-specific: that a language has a domain where it is best, and other applications areas where it is not so good.

    Wednesday, November 9, 2011 at 6:07 pm #
  3. Andreas Semt wrote::

    Thanks for the two interesting articles! If you say:
    “In conclusion, I apologize for introducing yet another term” I’m pretty sure ther’s no need to apologize. The people from the Viewpoints Research Institute ( lead by Alan Kay also introduced yet another term in their STEPS project. It’s executable in the sense of “runnable” and they call it “problem oriented language” (POL). A more complete quote: “Our general approach is to pick an area whose parts seem to be related—for example: 2.5D anti‑aliased alphaed  computer  graphics—try  to  find  the  mathematical  relations  that  cover  the  desired  phenomena, 
    design  a  “problem  oriented  language”  (POL)  that  is  a  “runnable  math”  version  of  the  mathematics, implement that language, then use it to write the program code for the target area.” [1]

    All their POLs are based on OMeta, described as: “OMeta is a new object-oriented language for pattern matching”. Their concepts seem to go into the same directions as yours. Please have a look into their annual research report from [1] if you’re interested in their work. It’s pretty inspiring 🙂

    Best regards,
    Andreas Semt

    [1] Steps Toward Expressive Programming Systems, see:

    Friday, November 25, 2011 at 8:49 am #
  4. w7cook wrote::

    Hi Andreas,
    Turns out that I visited VPRI right around the time you were writing your note. I’ve also talked to Alex Warth, who created OMeta. I just wrote some notes on the trip.

    Wednesday, November 30, 2011 at 10:08 pm #

Trackbacks/Pingbacks (2)

  1. Domain-Specific Languages < Ensō Blog on Friday, November 11, 2011 at 4:17 pm

    […] Domain-Specific Languages < Ensō Blog Tags: specification language, type systems, mallet, e.g. insurance […]

  2. Domain-Specific Languages < Ensō Blog | DSL | on Tuesday, November 29, 2011 at 6:54 pm

    […] Domain-Specific Languages < Ensō Blog Freddy Mallet asks what is the difference between an Executable Specification Language and a Domain-Specific Language. They are clearly closely related, but I think there are some differences that are significant. Source: […]

Get plugin