Dave Thomas has a really nice post on what I think is the main issue when someone tries to create a Domain-Specific Language. I’ve seem this a dozen of times, someone says “This is a DSL because it reads like English”.

Let’s say that another way. Whenever domain experts communicate, they may seem to be speaking in English (or French, or whatever). But they are not. They are speaking jargon, a specialized language that they’ve invented as a shorthand for communicating effectively with their peers. Jargon may use English words, but these words have been warped into having very different meanings—meanings that you only learn through experience in the field.

He gives some examples. Make is good one, ActiveRecord is something that I’m still trying to fit between DSLs and “the good old Ruby metaprogramming style”.

I disagree with some points though. When Dave says:

What’s the point? When you’re writing logic like this, with exception handling, command sequencing, and (in more advanced examples) conditionals and loops, then what you’re doing is programming. The domain is the world of code. If you’re not up to programming, then you shouldn’t be writing AppleScript. And if you are up to programming, then AppleScript just gets in your way.

This is not an issue. A Domain-Specific Language as we promote today is a Domain-Specific Programming Language. Right now the technology we have wouldn’t allow us to create programs that do not follow a given structure and using loops or conditionals is a valid way of programming inside a domain. Not all DSLs are declarative, imperative DSLs will generally rely on the constructs already used by imperative General Purpose Languages.

Also PragDave criticizes the way test frameworks like RSpec ( which I always use as an example of Internal DSL) use DSL-ish syntax because they try to create a language that sounds like English. This is not a problem at all. Specifications in BDD frameworks should look like functional specifications and in most cases software is specified in English (or Portuguese, or German, or whatever).

Actually RSpec’s syntax is very easy even for people that don’t know how to program in Ruby. I’ve seem people that use RSpec as a Selenium driver to test Java systems, the only bit of Ruby in the whole codebase are the specs. The non-Ruby programmers do a pretty job developing and maintaining these specs, all due to the natural-language style RSpec has.

Think of something as a DSL only because it tries to approach natural speaking is an error. Imagine that a DSL can’t look like natural speaking is another.

Anyway, Dave got a really good conclusion:

However, I am concerned that the popularity of these frameworks, and other similar uses of English-as-a-DSL, may lead developers astray. Martin Fowler writes about fluent interfaces. I think his work might have been misunderstood—the fluency here is programmer fluency, not English fluency. It’s writing succinct, expressive code (and, in particular, using method chaining where appropriate).

I’ve stated before that Fluent Interfaces are not about English-like sentences but about changing a programming language to become more clear and or effective in a task. Fowler disagrees with me and make Fluent Interface almost synonym to Internal DSL. Since I’m not arguing with the author of the term I’m looking for a better name for the concept I use.

I would add to Dave’s conclusion the fact that a Domain-Specific Language is a language specialized in a given domain. If the domain expert uses that language and can read your code written in it this is awesome, but is not a real requirement for it.

It’s just like HTML in the 90s. Basically only programmers understood HTML in the beginning of the web-as-a-mainstream-thing era but it was still a DSL. The fact that the web designers that actually create the design in Adobe Photoshop couldn’t understand a sentence of it (and the sad fact that even today lots of designers don’t have a clue about HTML) does not make HTML less Domain-Specific.

Update: Anders Norås has similar thoughts.