Reading Fowler’s DSLs Book in the Land of the Rising Sun

Posted on February 2, 2012



What can I say? I love Japan. I’ve been waiting a year just to spend my vacation in the land of sushi, Yebisu beer, and puroresu. It is the time I get a chance to bring my books (in PDF or in my Kindle), and do some long-postponed reading. It was also a chance for my wife and I to finalize several things we started on our last trip. For instance, the pictures of my daughter’s 2nd birthday. Did you know that most (if not all) photo shops in Japan do not release digital copies of photographs for a year? Talk about capitalism 🙂

Fuyumi Rocio at 24 months old, 2011

One of the things I’ve been wanting to do, and which I’m finally getting to, is to ready Fowler’s book on DSLs.

If you work in software, and don’t know what DSLs (Domain Specific Languages) are, you owe it to yourself to get acquainted to them. I would suggest you listen to Software Engineering Radio podcast (episode 182) on the subject, with Martin Fowler himself and Rebecca Parsons as guests.

DSLs and LOP (Language Oriented Programming) aren’t a fad. I know first-hand of places (embedded and enterprise) that use them quite successfully.  It is a natural extension IMO of Model-Driven Development.

If you know what DSLs are, and you want to get a deeper insight into the subject (or get a better understanding if you work in DSL development), you should get Fowler’s book. It’s really, really, really good.

Fowler doesn’t just focus on DSLs, but on design principles that need to be taken into consideration before even considering a DSL. The first 1/3 of the book discusses DSLs in general, with the remaining 2/3 being an encyclopedia of technical items and patterns for implementing them.

His main argument (or so the way I’m understanding his message) is that a DSL is desirable if we have an underlying domain model or API for which a possibly alternative model of computation (alternative to imperative) is desirable or advantageous.

Ugly, unyielding APIs, complex build systems, enterprise integration glue code, test harnesses, requirement capturing using a human readable (and yet formal) grammar. The list goes on and on where a DSL is desirable.

Fowler goes on to discuss different “adaptive” programming models (state machine, decision tables, product rule systems, etc) with their pros and cons. He also separates the building of a semantic model from the parsing mechanisms.

I could think of so many places – past and present – where a DSL would have been simple to implement and benefits would have been tremendous. But perhaps, Fowler’s most important distinction between a DSL and simply calling an API is in a DSL’s focus on declarative sentences (following an explicit or implicit formal grammar. Calling an API involves calling the API’s individual functions or methods, each which, by their very nature, are stand-alone units of computation.

A DSL-level declarative sentence, on the other hand,  creates (what I call) a sentential context, a complex and yet cohesive composite unit of work that, under the hoods, operates and invokes the formerly described units of computation (methods, functions, etc.)

Furthermore, as described by Fowlers, these DSL-level sentences provide a cohesive couple of data and computation in a manner that facilitates the creation of adaptive systems (systems where data actually has a say in the type of behavior being implemented.)

The book is quite thick, and I’m about 1/3 of the way in it. It is one of the best books I’ve ever gotten, one that I strongly recommend for the software practitioner who cares about cultivating his career of choice.