So what is a DSL anyway?

The term Domain Specific Language (DSL) is a popular buzz-word at the moment. If you look at wikipedia you’ll see the following definition:

“In software development, a domain-specific language (DSL) is a programming language or specification language dedicated to a particular problem domain, a particular problem representation technique, and/or a particular solution technique. The concept isn't new—special-purpose programming languages and all kinds of modeling/specification languages have always existed, but the term has become more popular due to the rise of domain-specific modeling.

The opposite is:

The problem I have with this definition is that it’s hard to draw the boundary between what is general purpose and what is domain specific. Instead, I prefer to think of a language having different dimensions, and to categorize a language we need to place it on each of the dimensions relative to other languages. This leads to a much more fluid categorization system, but makes it easier to identify the similarities and differences between languages. Below is a diagram I produced recently for a talk showing three dimensions. I think there are more, but these three seem quite important. I put some examples on the diagram to illustrate.


And as a tool platform vendor, I’d like to provide facilities for creating and using languages in as many points in that 3-dimensional (though probably should be n-dimensional) space as possible. I also want to provide ways of moving between languages at different points in the space.

What might other dimensions be? Martin Fowler makes the further distinction between internal and external DSL, so perhaps that might be another, though in that case I might concede that the dimension is binary: external xor internal, and no points between. Another might be formal/informal dimension.

Comments (2)

  1. Rui Curado says:


    On the great "dimensions of design" slide shown on this post, I would argue that the "instance <-> type" axis should have been "low abstraction <-> high abstraction".

  2. Rui, I’m not sure. It depends what you mean by abstraction. Perhaps you have some examples? Perhaps low/high abstraction is another dimension. The difference I’m getting at, when applied to code, woulc be the difference between source code (definition of types) and traces through the executing program (instances).


Skip to main content