Dsl Intro

Now that we have some understanding of monads, I want to turn our attention to DSL’s. We’ll come back to monads in a bit.

Seeds of thought

I’m always keeping my eyes open for “what’s next”. In programming languages, I think Clojure is what’s next. A couple of years ago, the seed for my thinking was planted when I read “On Lisp”. But this actually built on something I read 15 years ago in “Thinking Forth” by Leo Brodie. (You should at least skim Brodie’s book, since it’s free) He talks about grouping words into lexicons to make writing the solution to a problem easier. Very similar to Paul Graham’s idea of extending Lisp to create a language that you then write your final solution in.

Then to add to the mix, I watched Bob Martin’s keynote at RubyMidWest software architecture. The one thing I took from that is the idea that by reading the code, you should be able to see what that code is supposed to be doing. This idea of architecture and Alexanderian patterns came up again in Jim Coplien’s talk about the DCI architecture pattern. And also reading Richard Gabriel’s abstract for his Clojure/West talk (which you should really go to if you’re reading this, click link above) along with some other essay’s of his focused my attention on beauty in code and what might be coming next. Not to mention Alan Kay’s work at VPRI as stated in their 2011 annual report.

So I’ve come to think that DSLs will be the next abstraction technique to allow us to write beautiful, correct code.



The history of computer programming can be viewed as constructing a tower of abstractions. First there was machine language, where we punched holes into paper tape or punch cards that stood for numbers which were decoded by the CPU’s as instructions.

Then we decided to attached alphabetic mnemonics to the machine language instructions so they would be easier to remember. This abstraction hid the complexity of machine language.

Then we noticed that certain sequences of instructions were repeated over and over in our programs. So we invented the idea of the subroutine and added hardware support for it. This hid the complexity of repeated code.

Then we got crazy and invented ‘higher level languages’ like FORTRAN, Algol and Lisp. These hid the complexity of assembly language and let us use something resembling algebra.

Seeing the mess that using GOTO’s caused, we invented block structured programming in languages like Pascal. This hid the complexity of ad hoc flow control and let us reason more easily about what our programs were doing.

And to top off the imperative branch of things, we invented object oriented programming to hide the complexity of global state by encapsulating state inside objects.

On the functional side of things, we had Lisp, to which we added an object system, CLOS.

I know these ideas weren’t necessarily developed in this order (eg. Smalltalk), but it seems to me this is the order they came into general use. And in any case, it lets me make my point.

Enter DSLs

I think DSLs are going to come next in our little abstraction tower. The idea is becoming more mainstream given the advent of Rails in the Ruby community. And books like Martin Fowler’s Domain Specific Languages are laying some good foundations. For me, I would have to recommend Debasish Ghosh’s DSL’s in Action over Fowler’s because he addresses functional programming and languages like Clojure while Fowler limits his discussion to object oriented languages.

There seems to be some confusion on exactly what a DSL is vs an API vs something else. I’m not going to be so concerned with hard and fast definitions as I am with how to best produce good code. And the most important thing to me in that regard is how do I hide complexity while saying what I really need to say.

And since this is already too long, we’ll start on that next time.

Jim Duey 15 February 2012
blog comments powered by Disqus