Domain Specific Languages can be mysterious beasts. Federico Tomassetti is giving at talk at Voxxed Days Ticino about how to build DSLs in a simple and pragmatic way. We asked him who could benefit from them.

Why do we need DSLs, and why are they important?

Domain Specific Languages are languages that do one thing, and do it well.

We use this kind of languages every day: HTML and CSS are examples of very successful DSLs. Some companies hire me to build DSLs specific to their businesses. The reason they want to use DSLs is that they can offer a terrific increase in productivity.

There are several reasons for this:

  • Code expressed using DSLs can be understood or even written by domain experts: doctors, accountants, mechanical engineers. Because of this there are less misunderstanding between them and the developers.
  • The knowledge is captured at a very high level and you can perform all sorts of analysis on that. That leads to less errors.
  • They are resistant to technological changes because they capture ideas, not the implementation.

For example a DSL could define a medical procedure, but not how the recommendations defined by the algorithm are presented to the patient. This means that later you can change the technology around the DSL, to generate an Android application instead of a web application, for example. Think about the HTML you wrote 20 years ago: you can still open it on your phone. The browser changed, the HTML code stayed the same.

What kind of project needs a DSL?

They can be used in different cases but some are more obvious:

  • Do you have people spending their time writing poorly maintained, messy excel spreadsheets? Chances are they would be better off using a DSL with specific tool support. It would easily make them faster and prevent tons of errors.
  • Do you need domain experts and developers to collaborate? For example, if you are writing a medical application, this is the case. If you use a DSL you make easier for them to understand each other.
  • Do you have strict regulatory requirements? A DSL would permit you to analyze your code with domain specific formal checking. The code that you write with a normal programming language like Python or Java is practically impossible to verify. Is there a risk of getting a null pointer exception? An infinite loop? You can just test your application and hope for the best. With the right DSL you can prove properties of your code. If lives depends on your code, this will make you sleep better.

If you want more details I wrote a checklist of the 7 reasons to use a DSL.

What is ANTLR?

ANTLR is a parser generator. Parsers are the first component you need to build all textual languages, including DSLs. I personally like working with ANTLR because it can generate parsers in many languages like Java, Python, C#, JavaScript and more. It permits you to define parsers concisely and clearly. For some projects, instead of ANTLR I use a language workbench named Jetbrains MetaProgramming System (MPS). This is an interesting piece of software that allows you to create and mix different notations: you can then use text, tables, diagrams and more all in the same program. If you never heard of it you should take a look.

How difficult is to build a DSL?

It can vary a lot, depending on the tool support you need. In my presentation I am going to discuss a lightweight approach to create a useful DSL, with an editor and a simulator in less than 1.000 lines of code. This is possible because we are going to reuse some open-source components like ANTLR and Kanvas, and we are going to use Kotlin. On the other end of the spectrum you could need a small team to work for 6-18 months to build rich families of DSLs with first class tool support. Part of the work is also figuring what DSL you need.

If you are interested in hearing more about DSLs I wrote the complete guide to (external) Domain Specific Languages. I am also working on a book on building languages using the lightweight approach discussed in the talk.

 

For more, see Federico’s talk at Voxxed Days Ticino:

Ticino