This post originated from an RSS feed registered with Agile Buzz
by Martin Fowler.
Original Post: DslQandA
Feed Title: Martin Fowler's Bliki
Feed URL: http://martinfowler.com/feed.atom
Feed Description: A cross between a blog and wiki of my partly-formed ideas on software development
I was asked to put together a discussion of DSLs for
non-technical types. Maybe I've been reading too much Stephen O'Grady, but I felt an
irresistible urge to do it in a Q and A manner. So here it
comes.
What is a Domain Specific Language?
A Domain Specific Language (DSL) is a computer
programming language of limited expressiveness focused on a
particular domain. Most languages you hear of are General
Purpose Languages, which can handle most things you run into
during a software project. Each DSL can only handle one specific
aspect of a system.
So you wouldn't write a whole project in a
DSL?
No. Most projects will use one general purpose language
and several DSLs
Are they a new idea?
Not at all. DSLs have been used extensively in Unix
circles since the early days of that system. The lisp community
often talks of creating DSLs in lisp and then using the DSLs to
implement the logic. Most IT projects use several DSLs - you
might of heard of things like CSS, SQL, regular expressions and
the like.
So why are they getting a lot of noise
now?
Probably because of Ruby and Rails. Ruby as a language has
many features that make it easy to develop DSLs and the people
who got involved in the Ruby community have been familiar with
this approach from elsewhere, so they took advantage of these
features. In particular Rails uses several DSLs which have
played a big role in making it so easy to use. This in turn
encouraged more people to take up these ideas.
Another reason is that many Java and C# systems need to have
some of their behavior defined in a more dynamic way. This led
to complex XML files that are difficult to comprehend, which in
turn led to people exploring DSLs again.
So DSLs can be used with languages other than
Ruby?
Yes, as I indicated DSLs have been around for much
longer than Ruby has. Ruby has an unobtrusive syntax and
meta-programming features that make it easier to create more
elegant internal DSLs than languages like C# and Java. But there
are useful internal DSLs in Java and C#.
What's the distinction between internal and external
DSLs?
An internal DSL is just a particular idiom of
writing code in the host language. So a Ruby internal DSL is
Ruby code, just written in particular style which gives a more
language-like feel. As such they are often called Fluent
Interfaces or Embedded DSLs. An external DSL
is a completely separate language that is parsed into data that
the host language can understand.
Why are people interested in DSLs?
I see DSLs as having two main benefits. The most common
benefit is that they make certain kinds of code easier to
comprehend, which makes it much easier to modify, thus
improving programmer productivity. This is worthwhile all on
its own and is relatively easy to achieve.
The most interesting benefit, however, is that a well designed
DSL can be understandable by business people, allowing them to
directly comprehend the code that implements their business
rules.
So is this the hook - business people write the rules
themselves?
In general I don't think so. It's a lot of work to make
an environment that allows business people to write their own
rules. You have to make a comfortable editing tool, debugging
tools, testing tools, and so on. You get most of the benefit of
business facing DSLs by doing enough to allow business people to
be able to read the rules. They can then review them for
accuracy, talk about them with the developers and draft changes
for developers to implement properly. Getting DSLs to be
business readable is far less effort than business writable, but
yields most of the benefits. There are times where it's worth
making the effort to make the DSLs business-writable, but it's a
more advanced goal.
Do you need special (ie expensive) tools?
In general, no. Internal DSLs just use the regular
facilities of the programming language that you are using
anyway. External DSLs do require you to use some special tools
- but these are open source and are very mature. The biggest
problem with these tools is that most developers aren't
familiar with them and believe they are harder to use than
they really are (a problem exacerbated by poor
documentation).
There are exceptions on the horizon, however. These are a
class of tools that I call a
LanguageWorkbench. These tools allow you to define
DSLs more easily, and also provide sophisticated editors for
them. Tools like this make it more feasible to make
business-writable DSLs.
So is this a repeat of the dream of developing
software without programming (or programmers)?
That was the intent of COBOL, and I don't think there's
any reason to think that DSLs will succeed where COBOL (and so
many others failed). What I think is important is that DSLs
allow business people and developers to collaborate more
effectively because they can talk about a common set of precise
rules that are the executable code.
When should I consider making a DSL?
When you are looking at an aspect of system with rich
business rules or work-flow. A well-written DSL should allow
customers to understand the rules by which the system works.
Isn't this going to lead to a cacophony of languages
that people will find hard to learn?
We already have a cacophony of frameworks that
programmers have to learn. That's the inevitable consequence of
reusable software, which is the only way we can get a handle on
all the things software has to do these days. In essence a DSL
is nothing more than a fancy facade over a framework. As a
result they contribute little complexity over what is already
there. Indeed a good DSL should make things better by making
these frameworks easier to use.
But won't people create lots of bad DSLs?
Of course, just like people create bad frameworks. But
again I'd argue that bad DSLs don't do much additional harm
compared to the cost of bad frameworks.
Previous Topic
