Domain-Specific Languages by Martin Fowler

Domain-Specific Languages Reviews

• 
  David Lindelof

  Domain-specific languages (DSLs) are small languages that programmers use to express concepts in a very specific domain. They typically are far less powerful that generic programming languages but communicate their intent far better.
  
  This book is as far as I know the first comprehensive treatment of this important topic, and Martin Fowler does a very fine job of it, even though some areas (e.g. Language Workbenches) are too recent to get a full coverage.
  
  The book begins with a so-called narrative section that gives a broad explanation of DSLs, with abundant references to more detailed topics in the second half of the book (Martin carefully avoids the term "Patterns" here but I think this is what they really are.) This second half of the book can safely be skipped on a first reading, though I found Martin's writing to be so engaging that I had no difficulty reading the book cover to cover.
  
  If I should mention one area of improvement, it would be the so-called "Zoo of DSLs". This section gives several examples of DSLs, both internal and external, and I think this section could/should have been bigger with more examples and a better discussion of why this particular DSL is appropriate to that domain, etc.
  
  Highly recommended.
• 
  Joe

  A pretty light read for those interested in creating a domain-specific language, but aren't versed (nor want to be versed) in the design of general purpose programming languages and compiler theory. The book convinced me to switch from PLY to Antlr for my project, which was an unforeseen consequence. Martin Fowler's genius is in his ability to organize, condense and simplify a wide survey of information. If anyone else had written this book, I wouldn't have been able to read it in 3 days. The only deduction I give is for the unnecessary self-deprecating comments and apologies that were scattered throughout the book.
• 
  John

  Summary: this book is good, solid, trustworthy, accessible advice that allows one to create professional and perfectly serviceable, but ultimately uninspired and uninteresting, domain specific languages. If you write domain specific languages, you should read it, but if that's all you read I have a great pity for you.
  
  This book is successful in its project, which is to introduce the implementation of computer languages as a viable tool for the computing professional, or in other words to interpret the practices of language development as practices of software engineering. This is, by varying interpretations, both a good and a bad thing. Let us say what first is good about this result, and this volume, for there is much that is good about it.
  
  First of all, this is professional advice, administered with touches of that true sign of expert knowledge, self-skepticism. Fowler constantly warns of what he hasn't tried, and of what other software communities say differently. Where he does advise, he looks to specific examples of code to back up what he says. In ever way, one feels like one is getting judgment from where it is earned. This tone is leavened by whimsy, but even in the more fanciful examples one does not feel as though one has ever left the domain of the professional programmer. The organization of the book itself shows a good deal of professional care, with its division into general guidance and patterns, as well as the pattern listing and cheat sheet inside the front and back covers, respectively. It really does earn the red-ribbon bookmark which graces the hardcover edition, to indicate a book of substance and solid expert guidance.
  
  Having said this, in my opinion, its downfall is exactly that it brings the subject of language design to everyday professional software engineering. Although it talks about communication with domain experts, it brings nothing from outside domains inside the languages presented, and really does nothing to extend the notion of what one can do with computers. Domain-specific language design is truly one of great media for expressing formal ideas of any field nearly free of existing implementations. The reader will have some new tools to work on what they've worked on before, but they will not see new visas.
  
  Something about this, and perhaps much of software engineering, makes me sad, as though the experimental fun has been taken out of computing. To this, I should leave a quote from an early computing pioneer:
  
  “I think that it’s extraordinarily important that we in computer science keep fun in computing. When it started out it was an awful lot of fun. Of course the paying customers got shafted every now and then and after a while we began to take their complaints seriously. We began to feel as if we really were responsible for the successful error-free perfect use of these machines. I don’t think we are. I think we’re responsible for stretching them setting them off in new directions and keeping fun in the house. I hope the field of computer science never loses its sense of fun. Above all I hope we don’t become missionaries. Don’t feel as if you’re Bible sales-men. The world has too many of those already. What you know about computing other people will learn. Don’t feel as if the key to successful computing is only in your hands. What’s in your hands I think and hope is intelligence: the ability to see the machine as more than when you were first led up to it; that you can make it more.”
  ― Alan J. Perlis
  
  
• 
  Kiril Kirilov

  The DSL techniques I liked (because of their usage in Rails): literal extension, textual polishing, annotation, closure, dependency network, production rule system, state machine, template generation, embedment helper, generation gap. Rest of the book: mediocre.
• 
  Miloš

  I can see why this one became an instant classic - true to his form, Fowler applied his analytical pattern-sense to dissect Domain Specific Languages and produced a two-part delicacy - the first part dealing with general DSL guidelines and best practices and the second being a pattern reference book.
  
  Both the general advice and the patterns within are sound, practical and described Fowler's signature style - to the point, simple without being simplistic, whimsical and supported by copious amounts of code samples.
  
  The main fault of the book is its age - prophetically, Fowler predicted the coming age of language workbenches but, unfortunately, did not manage to cover them in enough detail that would be useful today.
• 
  Rod Hilton

  I loved Fowler's Refactoring and Patterns of Enterprise Application Architecture, so when I saw he was working on a book about DSLs, I was extremely excited. I've been really into fluent interfaces for a while, and I wanted to learn more about some best practices, patterns, and other stuff to think about.
  
  Fowler's Domain Specific Languages is good, but I wouldn't call it great. At least, not as great as Refactoring or PoEAA. One problem is that it's a little disjointed. DSLs are a large topic, and Fowler admits in numerous places that he wasn't sure how much detail to cover on a particular topic or where that topic should go, simply because of how resistant the material is to that kind of organization. He admits that he didn't want to be stuck writing the book forever, and wanted to release it earlier as opposed to never. I think he made the right call, and though he acknowledges that this decision has a downside, the downside is a bit noticable.
  
  The book can also be a tad hand-wavey at times. Fowler repeatedly stresses the importance of building a semantic model when developing a DSL, but I read the entire book from cover to cover and never felt like I got a truly good understanding of how best to do that for anything other than an extremely tiny DSL.
  
  A lot of the material on External DSLs I was able to understand because of my Computer Science degree, which focused on systems and stressed language design, lexing, parsing, compilation, and the like. If I didn't have that background, I think a lot of the External DSL content would have been over my head, as it felt like very high-level coverage of a very deep topic (a depth without which nothing practical can be done).
  
  Overall, I really enjoyed the book, as I do all of Fowler's books. His writing style can be a bit dry (he seems to have been made aware of this criticism, as this book contains a number of jokes peppered throughout its pages), but it is also dense and informative. I learned an awful lot, and I'd recommend the book to anyone who wanted to dive deeper into DSLs. That said, I think the book would have been better as two smaller books, one on internal DSLs and one on external DSLs (and all of the language workbench crap could just be completely dropped).
• 
  Yuriy Chulovskyy

  It should be not the first book you are reading about DSL.
  Since it was my first book, it is too abstract for me. It doesn't help me to create my first DSL.
  Maybe I'll read it again after I create a few DSLs.
• 
  Rejeev Divakaran

  I didn't like the book probably because I don't like the idea of DSLs
• 
  Miguel Alho

  great book with a lot of well organized knowledge about DSLs. really great to understand your options .
• 
  Slavik

  Good book. Everyone who want to start their journey with dsl should read this book.
• 
  Sam Keen

  First 1/2 is great. Second half is more for reference.