Crafting Powerful DSLs

What Is a DSL?

A Domain Specific Language (DSL) is a language created to support a particular set of tasks, as they are performed in a specific domain.

Why Create a DSL?

Many companies have people who know what your software should do (the experts) and they have other people who know how to write software (the developers). Still, those two are very different groups of people and making them work together is not easy.

Working Without a DSL Is...

• You spend a lot of energy making your experts and your developers communicate. You try every trick in the book: you use analysts to try to bridge the gap, you write long documents of requirements that are a pain to write and impossible to keep updated…
• You need to go back and forth. Developers ask clarifications and experts get frustrated: “Why they cannot understand us?”. Developers get frustrated with receiving ideas that look half-baked to them. They miss the necessary details, prove incomplete and confused when trying to translate them into code.
• The process takes way longer than it should be. The ideas look simple according to your experts but it takes months at best to translate them into actual code.
• Errors, errors everywhere. Now, everyone makes mistakes but some errors could be prevented if the experts had a system to analyze their work. It is only when developers translate the ideas of experts into code that you can “debug” your ideas. But errors found late cost so much more than if you found them immediately.

It is nobody’s fault: the experts understand the subject but cannot code and developers can code but do not understand the subject. Everybody is forced to work outside their own area of expertise and this leads to problems and frustration.

Where Is the Catch?

A DSL can be awesome, but, of course, there is a catch: designing a DSL is complicated.

If we had the sum up the design problem in one phrase it would be this: you have to solve the communication problem once and for all.

The first step is to understand what experts can and want to do.

Then you need to abstract out the computer science aspects from these elements, so you can give experts a tool that they can use on their own.

For example, imagine you are helping companies manage accounting for international companies. Your Tax DSL needs to have a concept of tax brackets to calculate marginal taxes so that your expert accountants can define the appropriate ones for each country and keep them updated. To allow that, your developers need to implement the code for marginal taxations and tax brackets in a traditional programming language. Once these basic elements are implemented, they are available in the DSL for use by experts.

Designing a DSL Is a Process, Not a Recipe

There is not a recipe to design a DSL: there is no standard solution to apply each time the same. Based on our experience, we have elaborated a process to implement an effective way to create a tool. A series of steps to make your company come together and create the tool that will make you more productive.

Do You Know What Powerful Languages Mean?

You can read many possible definitions of a powerful language.

Powerful or effective are positive adjectives, so often, they are just something people want to associate with your language.

We think that a powerful language is something that allows one to create the best software with the least amount of effort.

A Domain Specific Language is powerful when it makes experts 10x more productive in their job.

The value of using such terms when discussing language design is exactly in that they force you to think about your goals.

What exactly is that you want to accomplish with your DSL?

What would make a DSL powerful for your users?

Finding the answer to this question is not trivial, you need a thoughtful and deliberate process to find what your users care about, what are the main tasks they want to accomplish, what are the things they do in their day-to-day work… It is the first step to designing an effective DSL that users will love.

Find the other ones within our course.