Domain-Specific Languages Guide
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. Domain-specific languages have been talked about, and used for almost as long as computing has been done.
DSLs are very common in computing: examples include CSS, regular expressions, make, ant, SQL, many bits of Rails, expectations in JMock, graphviz's dot language, strut's configuration file....
An important and useful distinction I make is between internal and external DSLs. Internal DSLs are particular ways of using a host language to give the host language the feel of a particular language. This approach has long been part of the tradition in Lisp, and in the last decade got re-energized by the Ruby community. Although it's usually easier in low-ceremony languages like that, you can do effective internal DSLs in more mainstream languages like Java and C#. Internal DSLs are also referred to as embedded DSLs or fluent interfaces
External DSLs have their own custom syntax and you write a full parser to process them. There is a strong tradition of doing this in the Unix community. A variation of this is to encode the DSL in a data structure representation such as XML or YAML.
The most most common DSLs in the wild today are textual, but you can have graphical DSLs too. Graphical DSLs requires a tool along the lines of a Language Workbench. Language Workbenches are less common but some think they have the potential to profoundly improve the way we do programming.
DSLs can be implemented either by interpretation or code generation. Interpretation (reading in the DSL script and executing it at run time) is usually easiest, but code-generation is sometimes essential. Usually the generated code is itself a high level language, such as Java or C.
A guide to material on martinfowler.com about domain-specific languages.
During the last years of the 00's I got deeply interested in the resurgence of DSLs, fueled by efforts in the Ruby community, the desire to create fluent interfaces, and the enticing, if hazy, prospect of Language Workbenches. I saw a fair few projects using ideas from DSLs, but most people didn't have a good sense of their options in building and using them well. So I decided to tackle this by writing a book of patterns to use for simple internal and external textual DSLs. While much of that interest has abated during the intervening years, I still feel this book does a good job of capturing these techniques. In particular, it shines a light on using adaptive models to capture alternative computational models, such as rules engines, decision tables, and state machines.
I was asked to put together a discussion of DSLs for non-technical types. Maybe I've been reading too much Stephen O'Grady, but I felt an irresistible urge to do it in a Q and A manner. So here it comes.
When the topic of DomainSpecificLanguage comes up, one of the common puzzles is exactly what is or isn't a DSL. The trouble is that there is no precise definition for a DSL and there is a large gray area between DSLs and other things.
Most new ideas in software developments are really new variations on old ideas. This article describes one of these, the growing idea of a class of tools that I call Language Workbenches - examples of which include Intentional Software, JetBrains's Meta Programming System, and Microsoft's Software Factories. These tools take an old style of development - which I call language oriented programming and use IDE tooling in a bid to make language oriented programming a viable approach. Although I'm not enough of a prognosticator to say whether they will succeed in their ambition, I do think that these tools are some of the most interesting things on the horizon of software development. Interesting enough to write this essay to try to explain, at least in outline, how they work and the main issues around their future usefulness.
Will DSLs allow business people to write software rules without involving programmers?
When people talk about DSLs it's common to raise the question of business people writing code for themselves. I like to apply the COBOL inference to this line of thought. That is that one of the original aims of COBOL was to allow people to write software without programmers, and we know how that worked out. So when any scheme is hatched to write code without programmers, I have to ask what's special this time that would make it succeed where COBOL (and so many other things) have failed.
A common phrase that's bandied about when talking about DomainSpecificLanguages (or indeed any computer language) is that of noisy syntax. People may say that Ruby is less noisy than Java, or that external DSLs are less noisy than internal DSLs. By Syntactic Noise, what people mean is extraneous characters that aren't part of what we really need to say, but are there to satisfy the language definition. Noise characters are bad because they obscure the meaning of our program, forcing us to puzzle out what it's doing.
My book on Domain Specific Languages uses a pattern structure to organize the concepts that I use to describe DSLs. This catalog is a list of the patterns in that book. Each is linked to a page for each pattern. While the pages don’t contain very much detail, they do provide a reference URI for each pattern.