The secret problem with DSLs

I would argue that designing a good API is as hard, if not harder, than designing a DSL. A lot of the Java libraries have very bad APIs that are hard to use and remember. If the designers of those libraries have written a DSL for them they would have seen the difficulty in using their respective libraries and improved the DSL over time.

That’s an interesting idea; do you think their DSLs would be better if they used a real language builder, instead of these embedded or hosted DSLs? In other words, use something like Antlr, bison & flex, javacc, etc. to build a real DSL? Those tools would require more rigor in designing the language.

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.

A DSL doesn’t need to be a “real”, complete language–it can just be a simplified way to access the problem domain.

right on. couldn’t agree more. i’m so sick of hearing how dsls, tdd, ddd, and the rest of the lot are going to save all of us from bad programming. bah. there’s no panaceas.

Re: API vs. DSL design

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 think the “secret” problem with DSLs are the people that don’t understand that the “DSL”s that people create with Ruby, Scala, etc…are just really APIs.

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.

Well, no.

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.

Gotta agree with Rick on this one. I think a useful definition of DSL would be something like what he is hinting at here, but unfortunately people don’t apply any such rigorous definition. As it stands, DSL is just a overused buzzword for a library written in a language with more flexibility than Java. As such I think the real not-so-secret problem with DSLs is that people claiming to be writing them may very well be writing code that is unnecessarily clever and thus less maintainable, extendable or useful then it would be if written as a straightforward API.

“OK, Ruby has a little metamagic -but I still contend most of the Ruby DSLs are still just APIs.”

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.

Look at the JScience API which is considered a good API. The designers leveraged static imports and generics to design what is considered an elegant Java API.

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.

The flawed assumption is that programmers will be designing the DSL. A DSL should be designed by an expert in the domain (with assistance from a programmer who ideally has some 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.