Why Use a Domain Specific Language - IMPORTANT

If you want to get anything else about code generation, you’re going to want to re-read this article a couple of times until it makes sense. This is THE core concept from which everything else flows . . .

Firstly, if you’ve ever created a custom tag, utility library or a CFC, you’ve already written a DSL. A domain specific language is a limited language to allow you to solve a subset of problems more concisely than using a general purpose programming language.

So, if you write a UserDAO.cfc with methods for get(), insert(), update() and delete() then you have created a very simple DSL that supports four commands each of which has its own syntax. Now you can just write get(37) and it’ll take care of getting user where UserID=37. Compare that to the syntax to CFquery the db and you’ll see that get(37) is much more concise, expressive and readable. It is also much more limited – you can’t decide what fields to get, inner joins are not allowed, and if you want to get a user based on their email address you’re out of luck.

So, domain specific languages allow us to trade unnecessary flexibility for conciseness and readability. APIs and method calls could be considered as a rudimentary form of in language DSL for languages that don’t support more syntactically elegant self-extension mechanisms (Ruby IS cool in some ways).

But *That* Isn’t a DSL . . .
At their core DSLs are just an abstract grammar that allows you to describe a specific subset of problems more concisely that fully describing them in a general purpose language. Method signatures, config files, custom tag interfaces, UML class diagrams, simple “mini languages” parsed using yacc, meaningful directory structure conventions, database schemas – these are all domain specific languages.

Why Use?
Why do you create a custom tag or an object with methods? Elegant code reuse. Now instead of having to recode the algorithms every time you need them, you just write a phrase in your DSL (usually a custom tag or method call) and you end up with shorter, more easily maintainable programs.

A World of Distinctions
Of course, if you sit down with a proponent of Model Driven Architecture (or as I like to call it, programming in pictures :->) and tell them all they are doing is creating an API, they probably won’t like it. That doesn’t mean it isn’t true. The only difference is that instead of being tied to the concrete syntax of API calls in a given language, they are tied to the concrete syntax of boxes and arrows on a diagram.

There are in language DSLs, external DSLs, DSLs can be interpreted or compiled (through a generation step), but I’m with Eric Evans - the fundamental nature of programming is designing languages that elegantly capture requirements and make your code more concise, comprehensible and maintainable.

Conclusions
Start to look at programming as language design. I’ll be posting a number of pieces over the next few weeks on tips and tricks for dealing with different concrete syntaxes and how to generate code using DSLs. I’ll also be spending some time talking about one of the biggest issues that still needs to be fully solved in the world of application generation – creating generators using an agile approach.