Given all the di erent bene ts that domain speci c languages are reported to produce, why are they not a widely adopted practice? The essence of the question has roots in industrial experience of the two authors of this report, but it was put out as a discussion starter at OOPSLE 2020. During the discussion session itself, there were some possible reasons voiced and possibly related concerns expressed. In this report, we try to condense those in a short coherent text. Not claiming any generality and fully acknowledging the anecdotal nature of our evidence, we still think that such a conversation is useful to have within the SLE community.
While this paper re ects the opinions of the authors, it has been strongly in
uenced by the helpful discussions at OOPSLE over the business and organisational
problems causing domain speci c languages (DSLs) not to be adopted. By the
lack (or perhaps just dearth) of adoption here we mean that whenever software
developers have a problem to solve, among the possible solutions to it,
modelling the problem domain by means of creating a new domain-speci c language
or adopting an existing one, is rarely, if ever, the rst option. Quite often it is
being left out of this list altogether.
{ domain-speci c abstractions [
Given the obvious enthusiasm about the potential of domain-speci c languages within the (OOP)SLE community, it is discomforting to notice how low the adoption rate of DSLs appears to be, even in contexts which, according to the experience industries have with DSLs, would be a good t for their adoption. In the remainder of the paper we try to summarise possible reasons without overselling DSLs as the silver bullet. 3
During the discussion two main problems emerged, which seem to negatively a ect DSL adoption: 1. Many software engineering professionals are unaware or oblivious of DSLs. 2. Many SE professionals who are aware of DSLs, perceive them as risky.
In the remainder of this section we discuss these speci c evident symptoms of the problem. We will not be discussing the cause for these symptoms, nor trying to nd other problems to make the list exhaustive. 3.1
As practitioners, we seem to agree that only a tiny minority of software development professionals are aware of DSLs. An anecdote we can report, is based on our experience working with a client on the development of a DSL. Before contacting us, an organisation had invested some e ort internally to raise the level of abstraction in their software development process. They had the intuition it was possible to do so, in their context. However, the strategy to reach that goal, remained unclear until they were faced with the de nition of the term \Domain Speci c Language" and the implications around it. That term was encountered by them for the rst time only after investing two years on this internal project.
While many practitioners have a total lack of awareness about DSLs, others
have severe misconceptions about them. Often practitioners associate things
unrelated to DSLs, to the misunderstood term. In other cases they are aware of
only a certain kind of DSL, for example internal or embedded DSLs [
It appears obvious that DSLs cannot be more widely adopted, until more software development professionals get a better understanding of them, or until the DSL community adopts a di erent terminology which is less alienating for developers. 3.2
When there is a proper understanding of DSLs within an organisation, and they are aware of the bene ts DSLs could bring to their speci c situation, there is a set of perceived risks which could dissuade them from adopting DSLs.
In this section we are not making any statement about the validity of these
risks, but only trying to identify risks as they appear to be perceived by potential
adopters:
1. Lack of competence. Adopting DSLs is seen as risky because most
companies simply do not have internal resources with the skills needed to design,
implement, and maintain advanced DSL-based solutions. Such competence
seems di cult to acquire on the market or to develop internally.
2. Lack of established vendors. It is perceived to be di cult to identify
vendors providing language engineering services. In particular large
organisations see the risk in the absence of large vendors capable of providing
su cient support for software language engineering projects. The majority
of providers of language engineering services are single freelancers or
microconsultancies. Raincode Labs is known to be the largest in the world with
only around 50 compiler experts [
Most of these risks are far from being unfounded. It is indeed hard to become
an accomplished expert in compiler services and software language engineering|
even though only a very small team of such people is needed for any project or an
organisation. It is indeed a big liability that DSLs can be abandoned simply
because the one person making maintenance promises, decides to retract them and
move on. It is indeed true that DSLs are not a universal solution to all the
problems, and thus remain somewhat niche. We see the latter two as the most weakly
supported by facts: while there is a lock-in chance, a well-designed DSL raises
the level of abstraction enough to be separated from the technical
implementation details, which means redeveloping an alternative toolset is just a matter of
resources. (An example was given of TIALAA, short for \There Is A Life After
AppBuilder" [
Since the term \Domain-Speci c Languages" is problematic and overly general,
there can be two paths to solve this problem: either re ning it or abandoning
it. Re nement will imply further classi cation around several dimensions, in
order to clearly position each particular proposed solution within the overly
large solution space, and to facilitate separate discussions around each of the
dimensions, instead of wallowing in misconceptions. Examples of dimensions
can be:
{ Internal/Embedded/External. Internal DSLs are de ned within the host
language (e.g., Haskell's combinator libraries, jQuery and similar libraries for
JavaScript, XML I/O in most languages). Embedded DSLs are de ned
naturally within an environment that was meant for signi cant extension (e.g.,
language workbenches, languages with powerful quoting like MetaOCaml,
extensible compilers). External DSLs have foreign syntax and require
specifically developed tooling (e.g., embedded SQL in COBOL and 4GLs, LINQ in
C#, XPath and PCRE in all languages that support them). This particular
de nition of this dimension is heavily inspired by Renggli's work [
Examples of statements made aware of such dimensions:
{ HTML is an external DSL, targeting developers, for a horizontal domain
of hypertext markup. Building such a DSL and the corresponding tooling
is an e ort which requires signi cantly resources and it is intended to be
fore-taken by the industry as a whole.
{ Simple internal DSLs can be developed within a few hours, with the intent
of making code more readable. They require minimal investment. They are
intended mostly for developers, and in the majority of cases the management
will not even be aware of their existence inside the organisation.
{ Vertical external DSLs directed to non-developers, can be transformative for
an organisation. They require the deployment of a signi cant e ort and need
the support of the whole organisation or a large unit, such as a department.
They are typically multi-year projects with far reaching consequences in
term of productivity. They require adequate planning as they need to be
supported on the long term. This particular kind of DSLs are probably the
least well-known by a broader audience. A relevant example of this particular
kind of DSL is described by Volter et al [
If we consider these examples, we can see that they solve very di erent problems, they are intended to be used in di erent contexts, they require di erent resources to be implemented, they bring di erent risks with them, and they provide di erent bene ts. In other words, it is hard to see them as an homogeneous category, from the point of view of the potential adopters. Some are expensive, some are not, some can be built in an afternoon, others take years, some need to be maintained for decades, others don't, for some it is easy to nd competencies, for other is extremely di cult. As consequence hardly anything which can be stated for one sub-category of DSLs, can be extended to the whole category of DSLs. This could have contributed to the emerging of a very confused understanding of DSLs among many practitioners, and this could have in turn limited the di usion as the idea, as it is blurred and confused.
In other words, the category \Domain-Speci c Languages" seem too abstract for practitioners, while being perfectly useful for researchers. We could draw a similarity with other broad categories such as \means of transportation". While this term could be useful when discussing logistics or studying transportation, this would not be a term that many users would consider when looking for a solution to their problems, as it encompasses very di erent things such as bicycles, trains, tanks and aeroplanes, which are used in very di erent contexts to solve very di erent problems.
Hence, instead of re ning it, we can try to completely abandon the term
\DSL", and leave it behind. Alternatives to consider, are:
{ Fluent Interfaces =) Internal DSLs, APIs, library packages: they are
characterised by requiring a very limited e ort, introducing limited risks,
and provide a limited value when compared to external DSLs, because of the
lack of all advantages provided by tooling. While the developers of such DSLs
themselves enjoy some comfortable IDEs, not all that confort and support is
propagated well to the DSLs they create. Take diagrams [
These DSLs can have a very signi cant impact on the industry and typically their creation and development is fore-taken by several large partners.
Examples of Technical Languages are SQL, HTML, and CSS.
{ Knowledge Systems =) External executable DSLs for non-developers,
often vertical. This type of DSLs are typically developed by a single
organisation or a consortium of organisations operating in the same vertical space.
They require signi cant investments, and given they are intended for a
speci c vertical space, only a reduced number of users can bene t from them.
Therefore the investment requested to each adopting organisation is signi
cant. A key factor of this kind of DSLs is the creation of customised tooling:
besides editors, interpreters, simulators, diagram generators, and other
components are frequently developed and integrated in a comprehensive solution.
This is the kind of DSLs least widely known: unlike other kinds, such DSLs
are not typically shared outside the organisation which nanced them. An
example of such kind of DSL is the DSL created by the Dutch Tax and
Customs Administration for the de nition of tax calculations [
In Table 1 we present the relation between the DSL dimensions we discussed in section 4 and the DSL types we introduced here.
As an example of how DSL types can also be useful, consider the discussion on how risks a ect the adoption of a DSL. Di erent types of DSLs that we have identi ed, are impacted very di erently by the risks perceived: { In the case of Fluent Interfaces the risks involved are limited, as the investments necessary, and the bene ts provided. { In the case of Technical Languages, these languages are typically tackled as large, industry-wide e orts. While the resources necessary to tackle such projects are very large, the e ort is typically spread across multiple actors. The actors typically involved in these initiatives have the resources needed to counteract the risks involved. { In the case of Knowledge Systems, the risks faced are more signi cant because the level of investment needed is high, and the number of adopters to Internal (I)/ Horizontal (H)/ Developers (D)/ External (E) Vertical (V) Anyone (A) DSL Type share such risks is low. In addition to this, there is a problem speci c to this kind of DSLs, and this the lack of examples which are publicly accessible. We believe that the community should concentrate its e ort in mitigating the risks for this type of DSLs. More speci cally:
Lack of competence could be reduced by an e ort in education.
Under the umbrella of SLEBoK [
Speaking pessimistically, we can say that as a community of language designers, we are failing to communicate all the possibilities and bene ts that DSLs and the discipline of their engineering, can o er to practitioners. DSLs remain niche solutions to problems experienced by people who are both already aware of them and unafraid to venture towards them. In particular, metaprogrammers seem to be a good target audience for selling DSLs to.
In this paper, we tried to summarise the essence of the discussion that was taking place during OOPSLE 2020, the workshop on Open and Original Problems in Software Language Engineering. To substantiate some of the statements and to facilitate consumption of this text by external readers, we added some technical content, especially relating to the advantages of DSLs, that we collected in section 2 from available literature; the two adoption problems of DSLs, including a list of perceived risks of using them, in section 3; possible ways of improving the terminology by either re ning or replacing the very term \DSLs", in section 4. Our hope is that claims made here, can later be validated experimentally, and proper corrections could be put in place by the community to improve the level of adoption of language engineering techniques in the broader eld of software engineering.
We would like to thank all the participants of the discussion which was held as part of OOPSLE 2020. In particular, active participation in the discussion was noticed and appreciated from: Jurriaan Hage, Markus Volter, Ralf Lammel, Friedrich Steimann, and Mathieu Acher. We are also grateful to the organisers and other attendees of the OOPSLE workshop.