One of those days I was reading a forum topic commenting Neal Ford’s post on Smalltalk. I’m no Smalltalk expert but I think Neal’s conclusions were not fair. Anyway, there was this guy defending Smalltalk and he was doing a nice job, except when he talked about Domain-Specific Languages.

The forum’s poster went on talking about how you wouldn’t need a DSL when you have an expressive language such as Smalltalk, and since Ruby, Java or whatever wasn’t that expressive they need that.

Well, I beg to disagree. Domain Specific Languages are programming languages that mimic concepts of the domain into its constructs. They make easy to express the intent of the software being built.

It does not matter how expressive your language (Ruby, Smalltalk, whatever) is, it’s not the most expressive for all scenarios. Maybe the guy were confused because he is used to DSLs like Ruby On Rails and those languages handles with a very exotic domain: web applications.

When we –the domain users- talk about web applications we generally don’t have a common language like Gantt Charts for scheduling or electric circuits diagram notation. We speak of concepts, maybe we draw some UML diagrams but generally we work with programming languages. Using programming languages to express a domain that was already defined only in terms of programming languages is something really confusing but it is a special case. When we have an internal DSL to handle those concepts we modify the language to deal easily with those concepts, the guy at the topic thought –I suppose- that since we had to modify our language (Ruby) to handle those concepts more clearly we were having trouble expressing the intent in our very host language. Since Smalltalk would provide the required expressiveness it won’t be necessary to have DSLs there.

Well this can be true (I’m not saying that it is true) but as I said before web applications, ORM and the like are not good case studies because they were always expressed in computer programming terms. To make a fair analysis we need to get an example of something that isn’t defined by computer nerds, say accounting.

If you write standard code in Smalltalk, Lisp, Ruby, Java, C++, C#, Perl, Pascal, VisualBasic, Scala or any other language and show it to an accountant you will have lots of problems trying to explaining him or her what is that about. Show the accountant a spreadsheet, mathematical formulas and speak in financial terms and you can make him understand you. That’s exactly what Eric Evans proposes with Domain Driven Design: to create software that maps the domain model as much as it can.

The problem DSLs try to address is subtly exposed in Eric’s book, page 8:

Expert 1: The “net” box looks just like a component instance.
Expert 1: He’s not using our notation. Everything is a box for them, I guess.
Developer: Sorry to say, yeas. I guess I’d better explain this notation a little more.

At that chapter Evans is describing a modeling session between two domain experts and a software developer. The experts are engineers and they’re working on an electrical circuit modeling application. This dialogue snippet tells us how difficult is for an user to comprehend software as it is written nowadays. In the example the developer uses simples boxes to model the concepts and the engineers get puzzled since that notation is not what they’re used to when modeling their problems. In the remainder of the books Evans brilliantly comes with solutions to the problem of how to make software look more like the domain so you and business people talk about the same concepts but what Domain Driven Design basically does is to bring some design and architectural patterns that would minimize the gap between software as we write and the domain. That’s what Simonyi calls the encryption we –developers- perform at domain concepts to get working software.

Using a DSL would remove the encryption. The translation between domain concepts and actual runnable software artifacts that is performed by the developer in the example above is made by the software platform, the thing that processes DSLs. It’s not using object-oriented (or procedural, or functional) code to describe concepts in domain language, is using the actual domain-language to produce running software.

Right now the more effective way to use DSLs in our day-by-day coding is to modify the way we develop software by implementing internal DSLs, little idioms in our programs that are tied to the host language syntax but are more concerned in make intent clear than to obey standard patterns and conventions for the given host language.

It doesn’t matter how perfectly you can understand a program written in your favorite language, it doesn’t matter if you can write macros that change the whole syntax or structure and make your program expressive: computer programming languages won’t be the right tool to describe a business domain. Computer languages will handle concepts like messages, threads, objects and classes that are not related to any domain (Ok, Object Orientationis a domain) and even if you can write perfectly clear object oriented (or functional, or whatever) code it is still not written used domain concepts, you still have to translate between the worlds (and I suggest Evan’s book on this task).

The actual point is that you have to use all those fancy resources your language and platform provides you to be able to write your program using the business concepts themselves. And that’s where languages like Smalltalk, Lisp or Ruby make life easier and more pleasant.