Domain Specific Languages

I came across this article on Lambda by Simon Johnston on DSL's. He takes two examples from the world of art, and asks that we consider possible parallels in software.

1. My son and I recently read a book on Leonardo da Vinci (great link), in particular looking at the way Leonardo’s work contained a great body of work from very rough sketches to beautiful and complete works of art. Explaining how artists start with rough pencil sketches, refining the lines, the perspective and then move onto oil to complete was a particularly interesting discussion. 2. I know there are many analogies that we in computer science draw between our world and that of construction – here’s another. Look at how buildings are really constructed, the architect does not build blue prints, they draw or make a model of the envisioned building (some of these drawings have become as well known as the actual buildings themselves). For example, Frank Lloyd Wright’s Fallingwater started with a truly beautiful drawing that sold the client. Then followed floor plans and blueprints. Only then did wiring diagrams, plumbing details and specific engineering drawings for features such as the cantilevered balconies complete the story.

Simon then goes on to state his position:

My position is that the creation of domain specific languages that do not seamlessly support the ability to transform information along the refinement scale are not helpful to us. So, for example, a component designer that is a stand alone tool unconnected to the class designer that provides the next logical level of refinement (classes being used to construct components) is a pot hole in the road from concept to actual implementation. Now, this is not as I have said to indicate that domain specific languages are bad, just that many of us in this industry love to create new languages be they graphical, textual or conceptual. We have to beware of the tendency to build these disjoint languages that force the user to keep stopping and jumping across another gap.

I couldn't read this and not immediately be struck by Paul Graham's reflections on creating what became Yahoo Store, specifically his comments regarding lisp. Writing this it also occurred to me that RMS's comment in Why you should not use Tcl is also appropriate:

The principal lesson of Emacs is that a language for extensions should not be a mere "extension language". It should be a real programming language, designed for writing and maintaining substantial programs. Because people will want to do that! Extensions are often large, complex programs in their own right, and the people who write them deserve the same facilities that other programmers rely on.

...which can only apply doubly for applications written in a DSL.

It also brings to mind the miriad of embedded dsl's spawned by the Haskell community though their wholesale adoption and exploitation of monads (and more recently arrows).

It only reinforces my increasing belief that the biggest gap in many popular modern languages is the lack of syntactic closure; the ability to introduce new syntatic support for a feature that becomes a first-class citizen of your programming environment.