His experience is just like mine: programmers create the tools they need to solve a problem, and over time, certain useful point solutions get generalized and suddenly appear as full-blown or semi-full-blown languages. He traces the interesting case of the UNIX “adb” debugger “macro language” from its beginnings as list of very simple operations in the PDP “odt” debugger (octal address plus single-character operator) to something that was used to encode quite complex OS kernel inspection operations in Solaris. And how he found it necessary to provide an implementation of the adb macros for the mdb debugger created for the Solaris 64-bit port. Good tools just won’t die…

Another point that I had missed but that really shows the prevalence of domain-specific languages in highly complex systems and advanced development practice is that Solaris 10 shipped with a few new languages added. The “D” language used for dTrace is the best-known example, but there were a few other ones as well… It sounds like the point I made at a DATE 2008 panel debate (last year, missed this year due to conflicts with other duties in my life) where I took issue with the idea that “embedded software is written in C or C++” and said that “any real system contains at least 10 different languages” and that “there is a zoo in there”.

The last important point, I think, made in the article is the common design pattern of taking the expression syntax of an existing language and use that as the core of a domain-specific language. C is especially popular for this, since it also makes compiling simple: just generate a C-language program containing the snippets of C expressions in your language (the yacc model). It also avoid reinventing the wheel…

So overall, I found this article a very interesting read, not the least thanks to its long historical view of language design and tools.