The DSL Misunderstanding
I never thought I’d ever write a blog entry with a title that would sound appropriate for an episode of The BigBang Theory. Life is full of surprises.
When working in IT, Domain-Specific Languages (AKA DSL’s) are everywhere, but there is precious little consensus as for a working definition to qualify them.
Academic conference about DSL’s turn to presentation of ever more abstract tools aimed at simplifying the task of implementing DSL’s, or enumerations of more and more exotic application domains, together with the languages that have been designed to address them. The papers from this second class are utterly enjoyable – a true benefit if I ever saw one – but essentially pointless as they merely document niche problems and niche solutions. They don’t provide applicable wisdom. They don’t give keys to recognize my next problem as best solved by a DSL. And by the way, what is a DSL solution? What is a DSL?
And by the way, my objection on the first class of academic papers on DSL’s is even more fundamental, but way beyond the scope of this paper.
To spare feelings (“my DSL is more of a DSL than yours”) some use ever more encompassing definitions, to the point of irrelevance: anything that aims at solving a particular problem for a particular domain qualifies. According to such a vague gospel, make, ant, Excel are all DSLs, as they don’t solve universal problems. Look closely enough, and HTML and emojis become DSLs too. When lines are blurred, no wonder one starts playing with them.
Pushing this inclusive logic to the extreme, some even go as far as claiming that DSL don’t even have to be languages: class or function libraries qualify.
And when everything is a DSL, nothing is. It becomes a definition void of discriminating value (Quoting a forgettable even if enjoyable piece of cinematic culture, “When everyone’s super, no one will be.”)
Blurring the lines in this way does not help anyone, except for DSL taxonomists (like those looking for evidence of the golden ratio in architecture, nature, or even music ), who now have even more DSLs to gloat about.
Many will disagree with my definition given in this post, but at least, it is usefully discriminating: it is based on two objective criteria that characterize recognizable situations, where equally recognizable solutions can be applied fruitfully.
First, a DSL is a language. It is not a mere library. The whole point is to consider that for a given problem, the benefits of a bespoke language offset the corresponding development and maintenance costs.
Language processing infrastructures – interpreters, compilers, emulators – are out of most people’s comfort zone. I am a compiler writer by trade, programming language are my daily bread and butter, so I am understandably much less impressed by the effort required to implement them.
Full-fledged languages are very different from function or class libraries. They constraint the developers into formalisms, enforce paradigms, limit the number of concepts and features one can use, even inadvertently. They can (sometimes) be used by people with extensive domain expertise, even if not technically savvy enough to start programming in a conventional third generation language, where issues such as types, persistence, exceptions, scopes, and other similarly important concepts must be mastered.
Changeability is the second and even more important characteristic of any DSL effort: whoever uses it can decide to change it, alter it, improve it. As a software engineer, going for a DSL means that one can tackle complexity at two levels, by designing the language to provide useful abstractions, and by using the language to use these abstractions, an extreme form of divide and conquer.
A situation where the language is a given, when its design will not bulge, where its users have no say on how it evolves, is, in my opinion, not a DSL (or should I rather write: not a useful DSL)
Oddly enough, this definition does not even consider “domain-specificity” by itself as that much a useful criterion, because domains come in all sizes and shapes (is business administration a domain? Is scientific computing a domain? Is system programming a domain? Depending on your answers, COBOL, Fortran and C could be arguably domain-specific). On the other hand, changeability requires closeness between the users and the development, making the DSL a local development, shared by a relatively small set of people with a common concern, not all that unlike the common understanding of the term “domain”. More often than not, DSLs (in my understanding of the term) tend to be application-specific rather than truly domain specific.
And this definition can be articulated as a possible strategy for complex software projects: can one define a fruitful set of abstractions encapsulated in a DSL to make the software significantly easier, faster, more flexible to develop and maintain?
So shoot. Feel free to disagree. Or agree. What are your thoughts?
