What do you think?
Rate this book
Martin Fowler Signature Book
Domain-Specific Languages (Addison-Wesley Signature Series
When carefully selected and used, Domain-Specific Languages (DSLs) may simplify complex code, promote effective communication with customers, improve productivity, and unclog development bottlenecks. In Domain-Specific Languages , noted software development expert Martin Fowler first provides the information software professionals need to decide if and when to utilize DSLs. Then, where DSLs prove suitable, Fowler presents effective techniques for building them, and guides software engineers in choosing the right approaches for their applications.
This book’s techniques may be utilized with most modern object-oriented languages; the author provides numerous examples in Java and C#, as well as selected examples in Ruby. Wherever possible, chapters are organized to be self-standing, and most reference topics are presented in a familiar patterns format. Armed with this wide-ranging book, developers will have the knowledge they need to make important decisions about DSLs―and, where appropriate, gain the significant technical and business benefits they offer. The topics covered • How DSLs compare to frameworks and libraries, and when those alternatives are sufficient • Using parsers and parser generators, and parsing external DSLs • Understanding, comparing, and choosing DSL language constructs • Determining whether to use code generation, and comparing code generation strategies • Previewing new language workbench tools for creating DSLs
This book’s techniques may be utilized with most modern object-oriented languages; the author provides numerous examples in Java and C#, as well as selected examples in Ruby. Wherever possible, chapters are organized to be self-standing, and most reference topics are presented in a familiar patterns format. Armed with this wide-ranging book, developers will have the knowledge they need to make important decisions about DSLs―and, where appropriate, gain the significant technical and business benefits they offer. The topics covered • How DSLs compare to frameworks and libraries, and when those alternatives are sufficient • Using parsers and parser generators, and parsing external DSLs • Understanding, comparing, and choosing DSL language constructs • Determining whether to use code generation, and comparing code generation strategies • Previewing new language workbench tools for creating DSLs
640 pages, Hardcover
First published September 23, 2010
83 people are currently reading
1123 people want to read
About the author
Martin Fowler
46 books1,099 followersMartin Fowler (b. 1963) is a software engineer, Chief Scientist at ThoughtWorks, and an outspoken advocate for best practices in enterprise software design, particularly in regard to agile software development methodologies, including extreme programming.
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 18 of 18 reviews
June 28, 2019
I'm very glad to finally finish this book. It's great.
I started reading it to "write a DSL for Autotests" (kind of integration tests for a very coupled architecture)".
During exploring the project I've understood that in this case it's better to use the runtime features of my programming language (still doing it).
After reading the first "theoretical" part of the book I was asked to write custom annotations for C++ code. C++11 standard declared [[ attributes ]], but compilers didn't impement it.
So it was obvious to me to use smth like macros, use a State Machine semantic model, process the code with python script at preprocessing step.
I couldnt imagine this without the book 😍, so the main power is that it gives ideas.
When reading about language workbenches, I started using Graphviz ( mostly for visualizing State Machines 😀). Now I almost developed a habit of doing my everyday "thinking" on a computer instead of a paper: the final product of analysis/exploration can be shared and understood with a much higher probability.
The sad moment lie in the fact that I'm almost a noob in Compilers theory(lexers, parsers) and theoretical side of regexps. So when I use a recursive regexps from Python 'regex' package, I don't know the computational complexity of this "nice powerful function".
As I've seen an ObjC wrapper for ANLTR, maybe in the nearest future I'll try it. Also, I plan to learn basic concepts of metaprogramming with C++ templates.
I started reading it to "write a DSL for Autotests" (kind of integration tests for a very coupled architecture)".
During exploring the project I've understood that in this case it's better to use the runtime features of my programming language (still doing it).
After reading the first "theoretical" part of the book I was asked to write custom annotations for C++ code. C++11 standard declared [[ attributes ]], but compilers didn't impement it.
So it was obvious to me to use smth like macros, use a State Machine semantic model, process the code with python script at preprocessing step.
I couldnt imagine this without the book 😍, so the main power is that it gives ideas.
When reading about language workbenches, I started using Graphviz ( mostly for visualizing State Machines 😀). Now I almost developed a habit of doing my everyday "thinking" on a computer instead of a paper: the final product of analysis/exploration can be shared and understood with a much higher probability.
The sad moment lie in the fact that I'm almost a noob in Compilers theory(lexers, parsers) and theoretical side of regexps. So when I use a recursive regexps from Python 'regex' package, I don't know the computational complexity of this "nice powerful function".
As I've seen an ObjC wrapper for ANLTR, maybe in the nearest future I'll try it. Also, I plan to learn basic concepts of metaprogramming with C++ templates.
June 20, 2012
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.
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.
May 1, 2011
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.
February 20, 2025
Я долистал до 201 страницы и решил, что это едет в DNF
1) Я все еще не знаю, как делаются DSL*
2) Я не узнал вообще ничего нового
* если не считать гораздо более полезной главы в книжке по Scala про packrat и туториала по ANTLR, для которых покупка этой книжки не нужна
1) Я все еще не знаю, как делаются DSL*
2) Я не узнал вообще ничего нового
* если не считать гораздо более полезной главы в книжке по Scala про packrat и туториала по ANTLR, для которых покупка этой книжки не нужна
April 5, 2012
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
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
October 20, 2013
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.
October 22, 2020
There was a requirement at my work to do something similar so I definitely found the book very insightful. I also learned how and where I can use some of these patterns/templates.
If you're new to DSL and want to delve into it, this book provides very strong basics - lexers, parsers, syntax tree and code generators. Simple language and detailed code examples helped me grasp the concepts with ease.
The author repeated the part of building the semantic model a little too often and I felt that Language Workbenches could have been a book by itself that includes details on how something like that could be implemented.
If you're new to DSL and want to delve into it, this book provides very strong basics - lexers, parsers, syntax tree and code generators. Simple language and detailed code examples helped me grasp the concepts with ease.
The author repeated the part of building the semantic model a little too often and I felt that Language Workbenches could have been a book by itself that includes details on how something like that could be implemented.
June 30, 2024
Very interesting book that sums up domain specific language purpose, types and implementations.
The common topics part is too exhaustive and could be cut short.
Still an incredible body of work in this rather overlooked domain.
The common topics part is too exhaustive and could be cut short.
Still an incredible body of work in this rather overlooked domain.
February 19, 2020
Not what I hoped. Might be useful if you want to do DSL by hand, though.
September 11, 2021
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.
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.
June 14, 2011
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).
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).
February 3, 2013
This book is a nice intro into the DSLs in general and as such, it's just the first step. Actually learning how to create DSLs isn't something the book is good for. The book focuses on introducing the wonderful world of DSLs and does it quite nicely (as expected).
I have come to expect a certain level of writing from Mr. Fowler and he stands up to my expectations very well. The text is easy to read and understand (no difficult words or long sentences).
I have come to expect a certain level of writing from Mr. Fowler and he stands up to my expectations very well. The text is easy to read and understand (no difficult words or long sentences).
November 14, 2015
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.
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.
August 23, 2015
I didn't like the book probably because I don't like the idea of DSLs
September 26, 2013
great book with a lot of well organized knowledge about DSLs. really great to understand your options .
November 15, 2015
Good book. Everyone who want to start their journey with dsl should read this book.
April 13, 2020
罗列各种模式，感觉比较全面。每种模式点到即止，别期望看完就从入门到精通。翻译值得吐槽，读起来很不顺畅。
June 27, 2011
First 1/2 is great. Second half is more for reference.
Displaying 1 - 18 of 18 reviews