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.