Jay Fields and Zak Tamsen talked with InfoQ about Domain Specific Languages (DSLs), and how they have successfully used them in their projects at ThoughtWorks to empower businesses, reduce development time, and increase the agility of projects.
Watch the full interview with Jay Fields and Zak Tamsen (23 minutes)
In the interview, Jay & Zak describe DSLs as mini languages, written in the language and vocabulary of the domain they are being designed for. This essentially allows the DSL to be as expressive as necessary, yielding real benefits to business users:
“Having an expressive language allows the developer to do things more effectively and more concisely, and present a language to the business users that is a lot simpler for them to use, so they can focus on the actual domain”
Of course, there are also benefits to the DSL designer too. One particular benefit they discuss is that designing a DSL requires the programmer to really understand the domain that they are working within:
“The thing that I like about Domain Specific Languages is that you really learn the domain.”
The difference between internal and external DSLs are also discussed:
“Internal DSL implies that you are actually executing Ruby code, versus an external DSL where you use pre-processing to get it into the Ruby language to then be executed.”
Jay and Zak then describe why they feel that Ruby is such a suitable as a language for creating internal DSLs:
“Ruby [is] concise and [does not require] things such as parentheses or semicolons, giving you a more friendly language for domain experts.”
When asked to compare DSLs with rules engines, they said that rules weren’t always suitable for business users due to their complexity:
“Have you ever sat down with a business user in front of a rules engine?, they are generally very complicated”
To design a DSL is to design a bespoke language tailored specifically for the target domain. Rules engines typically attempt to provide the user with most of the features they require, and achieve the tailoring through extensions. However they describe that this isn’t always simple:
“Rules engines aren’t easily extendable, they can give you features 1 through 100 but you may need 101 and it’s not always an option.”
However, extending a DSL too much was something they didn’t encourage:
“The whole idea of the DSL is to solve a very small focus problem. You can have multiple DSLs within one application, that way it doesn’t become a general purpose language, which would increase the complexity. The more general your language becomes, not only the harder it is to build, the harder it is for the end user to use.”
For a while now, Jay has been blogging about the term Business Natural Language. He describes the problem:
“Everybody has been looking for a way for subject matter experts to specify the business logic”
Zak describes how using a GUI, the traditional approach for achieving this, is not necessarily as intuitive as a text box:
“When subject matter experts talk about their subject matter they don’t actually talk about it in GUI terms, or “I want to click here and move something over here”. They actually talk in English and say “I want to do XYZ if my profit score is a certain number”. They talk in English. I think that for them, once they see it working, the English, the text box, and just writing things that are close to English, is much more natural and more expressive.”
Both Jay and Zak recommend using DSLs written using Business Natural Languages (BNLs) to specify the business logic of applications. They describe how on one project they worked closely with a domain expert to achieve exactly this. They were pleased with how it worked out:
“By the end of the project [the domain expert] was defining the language. We were just working on what the keyword meant, after he came up with it.”
Watch the full interview with Jay Fields and Zak Tamsen (23 minutes)