Evolving Domain-Specific Languages

When designing domain-specific languages (DSL), the most critical choice is the selection of concepts that form the basis of the language. Sometimes concepts for the language come from the customer directly or from domain traditions. Sometimes the DSL developers force customers to use what they are already familiar with. Implementing these concepts in the DSL as close to the domain as possible is usually a good choice so the language will be readily understood by domain experts. However, instead of sticking to the existing domain concepts, it is also possible to evolve domain concepts by designing higher-level concepts based on existing concepts. In this article, I’ll demonstrate how such an evolution could be done using a classic state machine language as an example.

State Machine Language

Martin Fowler wrote a classic book called “Domain-Specific Languages.” This is a really good book, and I recommended reading it if you have plans to go into DSL design. The state machine sample from that book is copied from an article, and a lot of DSL framework developers and language workbench developers demonstrate the capabilities of their tools based on this state machine language. This language has become a kind of a DSL tool benchmark language. The sample is in the following code block (one of many variants. I've tried to compare to the one that is implemented for Xtext version of the language at the blog post by Sven Efftinge, “Martin Fowler's State Machine DSL with Xtext 2.3”):

On Evolution of Database Languages, Part 3

The article “Abstraction Tiers of Notations, Part 1” introduced abstraction tier concept, and in the article “Birth of New Generation of Programming Languages? Part 2,” I have tried to apply it to the evolution of the general-purpose programming languages. However, this framework is applicable to domain-specific languages as well. Let’s consider one of the most popular domains, where DSLs are widely used: data manipulation languages.

Current State

Firstly, let’s briefly examine current technologies available on the market. We will consider only employed abstraction tiers of data manipulation language for the database technologies while ignoring other aspects like distribution models, transaction support, or performance. While these aspects are very important for technology selection, they are orthogonal to the supported abstraction tiers.