1.) People don’t do that (see most of the DSL stories and examples in the blogosphere)
2.) Developers write most DSLs for themselves (admin, deployment, storage, …) and consider themself an expert in the domain

It’s more like: Your assumption about bug fixing is wrong, developers should think and be careful and not write bugs => q.e.d. no bugfixing needed.

Looks good but is not what happens in the real world.

And it’s the same with DSLs from my point of view.

I forgot :-)

3.) “DSLs to describe privacy policies for healthcare should be designed by privacy & healthcare professionals.”

There have been several articles that DSL don’t work with professionals. I was project lead of a research project which went into (visual) domain and flow models for professionals where we talked to business analysts about their experiences. In the end developers or businesss analysts design the flow models and domains because professionals just don’t care. Either they want you to solve the problem or cannot think abstract enough. Just my 0.02c.

And

4.) The professionals can give input about the domain, they can’t design the language. As a DSL is a programming language, you need programming language design skills.

DSLs to describe actuarial, financial or economic computations should be designed by actuaries, accountants or economists; not by programmers. DSLs to describe privacy policies for healthcare should be designed by privacy & healthcare professionals. A DSL for configuring a firewall should be designed by a network administrator.

A DSL is quite simple a grammatic interface instead of a GUI, providing functionality relevant to users in a specific domain.

What is easier to design, use and maintain?


Amount m1 = Amount.valueOf(3, KILO(GRAM));
Amount m2 = Amount.valueOf(2, KILO(GRAM));
Amount sum = m1.plus(m2);


or


3.kg 2.kg


The first example uses the JScience API directly and the second uses a DSL built on top of that api using groovy.

Do you imply that “metamagic” is needed to do a DSL?

For me a DSL is practical and close to the problem. It is “logical”. An API often is not logical, the intent can be confusing.

The best DSLs I saw were done for games. Games seem to be great for evolving a DSL.

And as long as a DSL stays elegant, it is the right way to do it.

If a problem is sufficiently hairy that a DSL seems necessary or a good idea to solve it, then it will be difficult to find someone talented enough to solve it at all, whether you use a DSL or not. The question is, do we expect that DSLs will tend to improve the ability of someone with a given amount of talent to solve the problem or not? If we expect that their ability to solve the problem increases, then this is not a secret problem with DSLs, it is a secret problem with problems hard enough to merit a DSL.

I don’t consider it a DSL unless you’ve got macros or some other mechanism to hook into the compiler pipeline. OK, Ruby has a little metamagic -but I still contend most of the Ruby DSLs are still just APIs.

Doing either of them well is hard. The key of the problem is that programmers have a lot of experience using and writing APIs but very little in writing and evolving languages. Of course, most APIs suck, too.

Another facet of the problem is that APIs have much more wiggle room than most languages do. I.e., the purpose of most DSLs is precisely to make things simpler by constraining/reducing the thought model of the programmer down so that it’s more clear/faster to write/etc.

Also, I think that there’s a lot more examples of bad languages than good so it’s harder to pick up the “how to do this well” than for APIs.

Finally, IMHO and IME, designing good APIs and languages are fundamentally the same game, just manifested in different ways.

I’ve always been irritated with the term DSL since it implies, nay states, that it’s a DOMAIN SPECIFIC language. If it was really domain specific you wouldn’t be able to revert to the host language, and the error messages would be specific (there’s that word again) to the DSL, not the host language.