Domain Specific Languages (DSL)

image I’ve been spending a lot of time recently looking at DSLs. That’s not on purpose, it’s just happened that way as I’ve been to a number of different conferences, such as Central Ohio Day of .NET where Jay Wren was talking about Boo and DSLs. I’ve also been in on a lot of discussions with Joe O’Brien and others about them.

From Martin Fowler – “The basic idea of a domain specific language (DSL) is a computer language that’s targeted to a particular kind of problem, rather than a general purpose language that’s aimed at any kind of software problem.”

There are a number of DSLs that we use every day. One of them that Joe likes to reference is:

no whip
2 pump
white mocha

Obviously (hopefully), this is Starbucks’ DSL that they use. This is a very efficient way for the Starbucks employees to communicate. The cashier starts by taking the order and transmitting that order to the person working the espresso machine who fulfills the order and passes it on to the customer. I usually understand it when they hand it back to me even though it sounds little to nothing like what I said to the cashier in the first place.

Domain – Every Domain has a their own vocabulary and dialect. Think about the medical field, banking, real estate, investments, mathematics, zoology, chemistry, grocery stores and on and on. Everyone of these has a way of communicating that the outside world has to understand to understand them.

Specific – these vocabularies and dialects are specific to the domain that they are in. In fact, the various terms don’t transfer from domain to domain. As an example, if I’m say Prime to an investor vs. Prime to a butcher, they are going to have completely different ideas as to what I’m talking about.

Language – this specific vocabulary in each of these domains is about communication quickly and efficiently. It’s a language all unto itself. Now, the majority of these are created from within the languages that we speak on an every day basis – such as English or French. Some of them have a touch of Latin thrown in but for the most part, they are local centric.

In very much the same way, DSLs in the software world are created, typically, from a language that already exists. There are languages, such as BOO, where the point of the language is to make it easy to create DSLs. There are other languages, such as Ruby, that make it very easy to create DSLs (see Joe’s talk on referenced at the end of this post). This is one of many reasons that I’m geeked about IronRuby.

image It’s always a good thing when the programmers and the users are speaking the in the same languages. This makes sure that you’re in lock step on the requirements and what the application is supposed to do. I’ve seen time and time again where an application does exactly what the programmer intended for it to do but communications issues mean that they had no idea what the user actually wanted or needed.

The first time I was introduced to the topic was when I was writing banking software. We went through a lot of hoops to make sure that we were speaking in banking terms when talking to the business analysts (BA). This was a struggle for a lot of the compsci majors just out of college that were amazing programmers but couldn’t understand the business rules. Part of the problem was that the languages that we were writing in, while we had class and method names that mapped, was still the computer science language verses something that we could show the BA. I always wanted to make it a requirement that the programmers had to work as a teller for a week every couple of years so that they could understand the business. You think I’m joking, but Anheuser Busch makes all of it’s employees, from brewers to architects to executives go to brewing school. Dominoes Pizza makes everyone go through the line training to learn how the pizzas are made. There are a lot of these examples, but not nearly enough all at the same time.

We are getting the tools, however, at this point where the language that we write in can start to become the interface with the BAs and the users because we can write it in such a a way that they can understand it.

To get a fantastic primer on DSLs and see them created in Ruby, go watch Joe O’Brien‘s talk that he did at Mountain West Ruby Conf called Domain Specific Languages: Molding Ruby.

Other things to check out:

Martin Fowler on domain-specific languages
Creating Domain-Specific Languages