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.

@lumpynose: No, I think their languages would be better if they are better language designers. Not sure how they could get better – reading more would help perhaps. And thinking really hard about the users of their language.

@Nadeem: Hmm. I have the feeling that designing a DSL is harder than designing an API. There are more combinations of building blocks in a DSL than an API. Perhaps you’re right though, designing an API is hard (I currently read the excellent “Practical API Design” and it is really really hard to desgin a good API.).

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

Nevertheless it’s a programming language.

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.

@Twylite: Yes your’re right, that’s the way it should be. Two comments

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.

Comment from Tim deleted.