DSLs In Action is Out
Join the DZone community and get the full member experience.
Join For FreeIt all started with a mail from Christina of Manning expressing their
interest in publishing a book on building parsers in Scala. She
mentioned that they have come across a blog post of mine titled External DSLs made easy with Scala Parser Combinators
and Marjan Bace (Publisher) would like to talk to me on this possible
venture. I still remember that hour long discussion with Marjan that
ultimately led to the thoughts of coming out with a book on DSL design.
The ebook of DSLs In Action (buy here)* has been published,
the print version is due Dec 24, just in time for Christmas. The final
book is sized at 377 pages with 9 chapters and 7 appendices. Before
publication the book was reviewed at various levels by an illustrious
panel of reviewers. I received lots of feedbacks and suggestions at
Manning online Author's Forum.
The current incarnation of the book is the result of assimilating all
suggestions, feedbacks and critiques aided by the constructive editing
process of the Manning crew. Jonas Boner has been kind enough to write
the foreword of the book. The result is now a reality for all of you to
read, enjoy and review.
Some one asked to me pen down my thoughts on DSLs In Action in one page.
Not the literal summary of what it contains, but the impressions of
some of the thought snippets that it can potentially induce into the
minds of its readers. This post is an attempt towards that.
DSL and polyglotism
A DSL is targeted for a specific domain. Your implementation should be
expressive enough to model the ubiquitous language that your domain
users use everyday. Hence the practice od DSL driven development has an
aura of polyglotism in it. Assuming you have the relevant expertise in
your team, target the implementation language that's best suited for
developing the syntax of the domain. DSLs In Action considers case
studies in Ruby, Groovy, Clojure and Scala and focuses its readers to
the implementation patterns of DSLs in each of them.
A DSL as a collaboration medium
The one most standout dimension that DSL driven development adds to a
team is an increased emphasis on collaboration. The main value
proposition that a DSL brings to table is a better collaboration model
between the developers and the domain users. It's no secret that most of
today's failed projects attribute their debacle to the huge gap in the
developers' understanding of the domain. This mainly results from the
lack of communication between the developers and the domain users and
also between the different groups of developers. When you have code
snippets like the following as part of your domain model ..
import TaxFeeImplicits._
override def calculatedAs(trade: Trade): PartialFunction[TaxFee, BigDecimal] = {
case TradeTax => 5. percent_of trade.principal
case Commission => 20. percent_of trade.principal
case Surcharge => 7. percent_of trade.principal
case VAT => 7. percent_of trade.principal
}
you can collaborate very well with your domain experts to verify the
correctness of implementation of the business rule for tax calculation
on a security trade. DSLs In Action dispels the myth that a DSL will
make your domain analysts programmers - it will not. A DSL best serves
as the collaboration bridge to discuss business rules' implementation
with your analysts.
Importance of the semantic model
A DSL is a thin layer of linguistic abstraction atop a semantic model. I have blogged on this topic
some time ago. The semantic model is the set of abstractions on which
you grow your DSL syntax. The semantic model can potentially be reused
for purposes other than developing your DSL layer - hence it needs to be
as loosely coupled as possible with the syntax that your DSL publishes.
In DSLs In Action I discuss the concept of a DSL Facade that helps you
decouple basic abstractions of the domain model from the language
itself.
DSL design is also abstraction design
Throughout DSLs In Action I have highlighted many of the good qualities
that a well-designed abstraction needs to have. In fact Appendix A is
totally dedicated to discussing the qualities of good abstractions. In
almost every chapter I talk about how these qualities (minimalism,
distillation, composability and extensibility) apply in every step of
your DSL design. In real world when you implement DSLs, you will see
that entire DSLs also need to be composed as abstractions. Use a proper
language that supports good models of abstraction composition
External and Internal is only one dimension of classifying DSLs
Though broadly I talk about external and internal DSLs, actually there
are lots of different implementation patterns even within them. Internal
DSLs can be embedded where you emded the domain language within the
type system of the host language. Or they can generative where you allow
the language runtime to generate code for you, like you do in Ruby or
Groovy using dynamic meta-programming. With the Lisp family you can
create your own language using macros. Some time back I blogged about
all these varying implementation patterns with internal and external
DSLs.
Hope you all like DSLs In Action. If you have reached this far in the post, there are chapters 1 and 4 free on Manning site taht would help you get a sneak peak of some of the stuff that I talked about .. Happy Holidays!
From http://debasishg.blogspot.com/2010/12/dsls-in-action-is-out.html
Opinions expressed by DZone contributors are their own.
Comments