DSL Checklist

7 Cases in which
you should adopt a DSL

Learn more at https://tomassetti.me

 DSL Checklist

DSLs: when adopting

them?
Domain Specific Languages are extremely powerful tool for one
simple reason.

They are about supporting reasoning and communication. These are

probably the two most important activities which are carried out in any
organization.

In general I think that DSLs can be used in very different contexts,

however in some cases adopting a DSL is really a no-brainer, because
the advantages are particularly high.

We identified 7 cases to consider. If one or more applies to your

organization you should seriously give a thought at the possibility of
adopting one or more DSLs.

If you are not sure DSLs are a good fit for you, you can write to me at
[email protected].

If you want to have a more in-depth discussion you can also schedule a
roadmap call, so we can talk about the specificity of your situation and
assess what is the best way to go.

Remember, I would love to hear your feedback, advices on what could

2 of 18
 DSL Checklist

be improved and questions which remain unanswered. Feel free to

write at [email protected] .


3 of 18
 DSL Checklist

1
Do your experts already use
a formal notation?

Do your domain experts already work using: Excel spreadsheets,

complex mathematical formulas, or graphs? Do they use some form
of structured jargon?

These must be the basis on which your experts decide and debate the
best course of action. For example:

• they are financial advisors that use formulas to describe an

investment strategy

• they are statisticians that express how to calculate the likelihood of a

certain result

• they are physicians who describes the steps of a treatment

If the answer is yes, the good news is that they are already using a DSL.

The problem is that they are using one that is only partially formal and
they are giving up the possibility of using tools to support them.

4 of 18
 DSL Checklist

By adopting a proper DSL you could provide them:

1. Better editors, to speed up development

2. Better error-checking, to ensure better quality and reduce the cost

of correcting errors

3. Automated artefacts generation, like documentation or simulations

that can be obtained by leveraging the formal definition expressed
using the DSL

5 of 18
 DSL Checklist

2
Is the real business value in
the knowledge of the
domain experts?

In many cases you sell software but what your customers are really
interested into is the knowledge contained in those systems. Chances
are, you are in the business of selling knowledge in a well-packaged
form.

For example, you are selling accounting software that apply the correct
calculation for every business need.

If the answer is yes, you want to make sure to isolate your domain
expertise in a way that can be reused over time. For instance, with a
DSL you can use the same business logic to power a web service or a
desktop application.

One customer I worked with created its own DSL over 20 years ago.
They captured their knowledge about accounting rules using that DSL.
Over time new technologies came and go, and they migrated the
tooling around the DSL, but the knowledge remained expressed in
that DSL. They never had to throw it away and start a new

6 of 18
 DSL Checklist

implementation with a fancy new technology.

Their protected their most important asset: the domain specific

knowledge. They had just to update the means they used to extract
value from it: 20 times ago it was a console based application, now it is
a web application.

7 of 18
 DSL Checklist

3
Do you want to reduce the
time to train your experts?

How bad is when a domain expert leave your company? How much
effort and time you have to put in to bring a new hire up to speed?

The knowledge your domain experts pour into your products is an

asset you should protect. It should remain yours even if they leave.
Sure, you can ask them to write something down in a document.
Maybe you have a wiki or another place where chunks of information is
preserved. How well is that working in practice?

What you can do is to encapsulate the knowledge of your top

experts in a DSL.

By formalising the knowledge that your best people already have, you
can use a DSL both as a teaching tool and as a way to limit the
mistakes and the hand-holding of the new employees.

The newcomers can use it to speed up their learning, thanks to a good

documentation and supporting tools, such as simulators of the results
of their code. Furthermore your top experts can design semantic
checks that can be automatically applied to every program. For

8 of 18
 DSL Checklist

example if your company makes electronic toys, the DSL can have a
tutorial to explain the proper way to describe the toy. And if one of the
designer put a voice function with 10 different phrases, it can
automatically check that there is the proper amount of memory to
contain all the phrases.


9 of 18
 DSL Checklist

4
Are communication or
coordination a bottleneck?

How long does it take you to put something on the market?

Have you evaluated the influence that poor communication has on it?

How much energy you have to put to make the information circulate
across different roles?

In many businesses these are crucial aspects. One typical scenarios is

the following: someone collect requirements from domain experts at
the beginning of the project, then requirements are given to
developers that go away for months to build the product. During the
time they could speak with domain experts but they are not sure they
understand each other. In the end the domain experts are shown the
results. At that point the results of poor communication causes
refactoring and delays.

Yes, agile development could reduce this issue but not cancel it.
Developers have still to build a product and look for feedback only
after the fact. By adopting a DSL domain experts can participate in
using it or providing feedback as soon as it is written.

10 of 18
 DSL Checklist

In one project I have seen feedback cycles being reduced from 18

months to 1 day: using a DSL the team could share the code with
domain experts every evening. We had also built a simulator that
always run on the last version of the code.

How do you think this affected development time? How this affected
the relation between developers and domain experts?

They improved a lot: the project was completed in a fraction of the

time and the domain experts were able to provide valuable feedback
every day, ensuring the project was running smoothly. Domain experts
felt more involved, developers felt relieved: no big surprises ahead,
their work was being validated every single day.

11 of 18
 DSL Checklist

5
Are your domain experts
busy writing code?

You employ some domain experts that have some basic coding
knowledge and they write their own scripts. For example, they could
be scientists or mechanical engineers.

What is the problem with that? The problem is that is not the best
usage of their time, and given you probably spends a significant
amount of money for buying their time it makes that your problem.

The other things is that people who are not professional developers
but just code because they have to, do not produce the best code. Are
you pouring money to produce code that is unreliable? Code that has
poor quality?

If you are in this situation you could consider an alternative: you could
free some of the precious time of your workers by designing a DSL
that cater to their needs, and allow them to describe a problem in a
formal way. Typically productivity can be significantly increase (a 20x
increment in productivity due to the adoption of a DSL is not unheard
of).

12 of 18
 DSL Checklist

In this particular case other benefits are also very relevant: they would
not spend their time programming but using a DSL to formalise their
thought. This would be arguably more enjoyable for many experts,
leading to less turnover. A very important aspect is quality: a DSL
typically permit to avoid entire categories of quality issues you have
when doing classical programming. You can design a language that
makes impossible to have memory leak, infinite loops or null pointer
exceptions. Most importantly it makes the code more understandable,
and this permits to root out many conceptual mistakes.

Let’s be honest: scientists who write code because they have to, are
not professional at writing code. They tend to produce code that is
hard to maintain, poorly written and they take a lot of time to write it.

There is a better way.

13 of 18
 DSL Checklist

6
Are there many departments
that must collaborate on the
same project?

Communication is vital, but it does not come for free.

Typically a project involve different departments, and people with

different roles, very different backgrounds and skills. To make the
information flow to everyone, to orchestrate the traffic of feedback,
advices, and ideas could be a very demanding task.

Consider also that people with different backgrounds look at different

aspects of the same problem, and talk about it using different terms.

In my experience DSLs can become the central artefact capturing the

knowledge and they can help making communication more efficient
and less costly.

How you ask?

First of all they help building a common language. In addition to that

they can be typically understand by people in different roles. Another
aspect that is frequently overlooked is that they capture knowledge in

14 of 18
 DSL Checklist

a formal way, so that it can be processed and artefacts can be derived.

For example you could generate graphs and reports, automatically
from your code, ensuring their are always in sync with reality, which is
frequently not the case when they are written manually.

15 of 18
 DSL Checklist

7
Are there strong needs for
safety requirements?

You might be legally required to support certain security standard or it

may be too costly to make a mistake, be it because the loss of
reputation or the costs involved in recalling a product. This has an
impact on your development process, making it slower and clunky.
Under these conditions you can’t be quick to market.

You should ask some questions:

• How much are you spending to guarantee the quality of your

product?

• How much the quality process is slowing you down?

• Do your processes guarantee absolute confidence in the result?

You could create a DSL with supporting tools to guarantee the

correctness of your program. The tools can check all the boxes for you,
and warn the domain expert or the programmers of every mistake that
can’t be solved automatically.

16 of 18
 DSL Checklist

Consider for example the case in which you write code to control
machinery. You could use the state machine paradigm: pressing
buttons or activating levers correspond to send an event to your state
machine, which will react in different ways depending on its state.

If you are using a DSL to describe your systems you could use solvers
to verify certain properties of you state machine: is there a possibility
for infinite loops? Are all states reachable? Are all events handled? You
can use static analysis on your high level language to root our vast
categories of problem. This give you absolute certainty about the fact
that your system has certain properties. And it gives you that for free. It
sounds a good deal to me.

17 of 18
 DSL Checklist

What’s next?
If you have questions or doubts you can always look for more content
on my blog.

There is a category specific for Domain Specific Languages:

https://tomassetti.me/category/language-engineering/domain-
specific-languages

In general you can find articles related to Language Engineering:

https://tomassetti.me/category/language-engineering

If you cannot find an answers write to me and I will try my best to help
you. You will find me at [email protected] .

If you think that a DSL will help your organization you can schedule a
roadmap call and we can figure out together what is the best course of
action.

18 of 18