What are Domain Specific Languages?
At some point in the past you may have heard of the term 'Domain Specific Language' or DSL. More so since Microsoft released a DSL toolkit that plugs into Visual Studio. But I'm sure many of you are left wondering just what a Domain Specific Language actually is.
There's a short answer and a long answer. The short answer, especially in the case of Microsoft's DSL toolkit, is that a DSL is a way to let users (business experts) design a domain model that can then be automatically fed into a code generator to extend an application. Think config file with a nice GUI.
Before taking the long answer it's worth talking about the term 'Domain' - what exactly is a domain? Dictionary.com tells us that a domain is "A sphere of activity, concern, or function; a field: eg. the domain of history.". It sounds rather vague, but I like to think of a domain as a topic in which someone can specialize.
General Purpose Languages
There are probably hundreds of computer languages out there. Some of the more popular languages are C++, Visual Basic and C#. These are considered General Purpose Languages (GPLs) because they can be used for just about any purpose, from creating a shoot-em-up game to programming rules for a general ledger in an accounting system.
But GPLs have their drawbacks. Take drawing a picture as a metaphor. You can use Microsoft Paintbrush to draw any picture you like, but the more complex the picture you are trying to draw, the more complex and time consuming the task becomes with such a general and basic tool. GPLs are a little like Paintbrush, in that you can achieve anything with them but it won't necessarily be the most efficient way to get the result you need. When you're drawing a three dimensional picture of a house, perhaps what you need is a CAD program and not Paintbrush.
Most modern GPLs have features such as classes and types that let you create abstractions. Abstractions are important because they let the programmer do more than simply instruct the computer - they let the programmer create what I call a "domain oriented environment" - that is, a set of tools that transform the language into something far more aligned with a specific domain.
Consider a language like C#. Leaving aside the .Net framework you're left with some functions such as simple arithmetic, string manipulation, conditions and looping. These are great if your domain is a calculation engine for example. But if you had to implement an inventory management system you'd soon realize that piling together a sequence of calculations might eventually get you your desired product, but under the hood it will be an unmanageable heap of meaningless codes. With abstractions we can create concepts - an invoice, an asset, an inventory list - that can be extended and developed and can evolve with the programmer's understanding of the domain. At this point the general purpose language has been used to create a domain oriented platform.
When Field Meets Language
But is that enough? While GPLs allow us to create domain oriented platforms, there are still many constraints. Classes and methods in those classes can only be used within the confines of the language's syntax, a syntax which is deliberately general. This general syntax can often complicate the code and make it unnecessarily verbose and difficult to read.
To take this one step further would allow us not only to create new types that are domain specific, but also new semantics and a syntax that is specific, and more importantly optimized, for a certain domain. And this is where Domain Specific Languages come in to the picture.
A DSL Example
There's nothing new about DSLs. There are plenty of examples of DSLs out there today that have been around for 30 or more years, and you've likely used several. Some examples are SQL, XQuery/XPath, HTML, Batch files, BNF and DTD.
Let's take SQL as an example. Here the domain is relational data management. While we could easily use a GPL such as C# to describe a select-join statement, perhaps something (made up) like this:
SelectOutput output = new SelectOutput();
foreach (TableRow row in Tables["Invoices"].FindRecords(new WhereStatement(new EqualityPredicate("Status", "Open")))
output.Add(Tables["Customers"].FindRecord(new WhereStatement(new EqualityPredicate("CustomerID", row["CustomerID"]))));
reutrn output;
…you can see that it's not exactly the most succinct representation of a join. This is a classic case of the constraints of a GPL's syntax getting in the way of what you're trying to describe: Most of the important and useful information is shrouded by stuff that looks redundant.
The equivalent in SQL could be:
SELECT Customers.CustomerID FROM Invoices INNER JOIN Customers ON Invoices.CustomerID = Customers.CustomerID WHERE Invoices.Status = "Open"
…which is much clearer. You could imagine, for example, someone who understands relational databases quite easily writing the SQL statement, but it would be much harder and would require much more knowledge outside of RDBMS experience to write the C# code.
Here you can see how SQL opened up a whole new world to those who specialize in understanding databases. DSLs effectively create an interface, a bridge, between domain experts and computer systems.
Different Types of DSLs
While SQL may be one of the more familiar DSLs, they have been used probably thousands of times in a far more specific manner: To add programmability to an application. Think application config files or options dialogs, for one. These are a form of domain specific language. They allow the domain expert to change the behavior of the application using a language in which they are familiar. These are known as Declarative DSLs.
These configuration interfaces focus on changing existing behavior, but what is also interesting are DSLs that let domain experts create new behavior. Effectively the DSL then becomes a new programming language - with a syntax optimized for a specific domain. This is quite a powerful concept. These are known as Imperative DSLs.
An example of this type of DSL is a workflow system. Workflow designers allow business experts to graphically define program flow using domain terminology: One box in the flow chart may specify an event such an invoice being created, the next box may be a condition that forks based on the due date of the invoice. These steps combine to form new behaviors that can extend, or build an application.
There are also imperative DSLs that are textual and more like traditional programming languages. Take, for example, a statement such as:
"when invoice is near due date send invoice to accounts"
This is effectively a business rule. The language used to articulate this business rule has an inherent understanding of what an invoice is, where to find it, and what it means for the invoice to be near the due date. While the language would have a concise syntax, the chosen syntax can use the type of words that the business expert would use in everyday language. It's a syntax they can quickly learn and should already be familiar with.
In both cases, throughout the process the domain expert is working in an environment in which they can easily understand, and that empowers them to combine their knowledge and experience with creativity to produce a system that more concisely reflects their requirements.
As a final comment I'd like to mention one particular technology that doesn't fit into either GPL or DSLs: Intentional Programming. Originally developed by Microsoft Research, IP can best be described as a domain engineering environment that promotes the development of abstractions, like a GPL, but these abstractions are central to the environment, providing the ability to transform the syntax of the language dynamically. Even syntax in IP takes on a new meaning, allowing representations of abstractions in both graphical as well as textual form. And that's really just the beginning. I've added some references to papers on IP at the end of this article for those who are interested in learning more.
References
You can learn more about DSLs from these sources:
http://en.wikipedia.org/wiki/Domain-specific_language
http://homepages.cwi.nl/~arie/papers/dslbib/
http://martinfowler.com/articles/languageWorkbench.html
http://msdn.microsoft.com/vstudio/DSLTools/
http://www.intentsoft.com/technology/overview.html