I was compelled to write this review a few minutes ago while attempting to use this book. I rarely bother to write a bad review-- but I'm fired up.
It's really a fairly horrible example of the genre. The problem is that there is no other game in town for this material.
It's clear the authors know what they are about. In fact, it's fairly obvious they are all brilliant professionals, but they desperately need good editors and co-authors who specialize in presenting this type of material.
This technology is relatively new and unfortunately it seems as though the example implementations available on-line are written by the authors of this book. Terrible or absent in-code documentation is the rule. ...So I am forced to read the book to sort out HOW to do the simplest of things.
When this happens, I seem to spend 15 minutes trying to find precisely what portion of the book is applicable. It's not that the book is poorly organized on a high level. It's that actual content isn't presented in an manner that lends itself to reference.
The examples presented are almost all part of large extended examples that run through most of the book. So I inevitably feel that I am missing most of the context when I start to read. Then the information is sometimes presented in language that sounds insular and academic to me -- a developer and software architect for over 15 years.
The authors seem to have expected the readers to set aside a day or two of their life to read the book from cover to cover and somehow remember it all. It's an absurd premise for a developer's book. No developer worth their salt has that kind of time ... unless they are an academic. It's also an impossible premise because the material is dry as a bone. After reading books from the "Head First" authors, this material will make you want to claw your eyes out.
I think the worst difficulty is that I find key information on how to integrate pieces of the functionality is often ignored or thrown in as an afterthought.
As an example, I discovered I need to add validation on some data entered into my DSL. It seems like an easy thing to do, right? Shouldn't take more than 5 minutes to figure that out, right? 15 pages into the section on "Constraints and Validation" I find I understand perfectly why the authors have decided to implement this functionality using C# instead of Object Constraint Language. I understand a great deal about their architectural decisions. I can recite the topology of their belly-buttons on the day they sat down to write the functionality, but I have no idea how to hook up a !@#$ing constraint.
I had the opportunity to listen to a web presentation by one of the authors, Gareth Jones. He presented some ingeniously written code for an example implementation of the DSL tools. To my complete and utter lack of surprise, I understood almost nothing nothing that he said. I found myself zipping back and forth in the presentation trying to deduct how pieces of the code examples he gave were meant to go together.
I was grateful to find the code itself was available on-line ... with no in-line documentation of course. I spent hours understanding how it all fit together when, with some basic presentation skills, he could have given me the information in 5 minutes.