Seven signs YOU may have created a Gratuitous Domain Specific Language
Posted by Tom Moertel Sat, 18 Aug 2007 17:01:00 GMT
Like chromatic, I have watched the recent irrational exuberance for domain-specific languages (DSLs) with bewilderment. In certain quarters of the programming universe, it seems that creating DSLs is nearly a rite of passage. The problem is, more and more of these DSLs appear to have been created mainly because, well, DSLs are cool these days, even if less “novel” solutions probably would have been more sensible.
Whereas chromatic unhesitatingly confronted the madness head-on, I have so far managed to avoid the fray. Sure, I’ve asked the occasional probing question of the DSL enthusiast, but mostly my reaction has been limited to standing back and staring in mute amazement at the runaway Domain-Specific Fun-Time Language Train, screaming down the tracks, destined for its inevitable high-speed derailment into what I can only expect will be a bridge abutment. But I’m starting to get the feeling that some of the train’s passengers are aboard because they think it’s the Right Thing To Do Train, so maybe it’s time to say something.
To set the record straight, I don’t have anything against DSLs, embedded or otherwise. (I have created my fair share, some of which are actually useful.) No, my concern is limited strictly to the rise of the Gratuitous DSL. So let’s talk about it.
The reason – the right reason – for creating a DSL is because it ultimately lowers the cost of solving problems. If, then, you create a DSL and the cost of solving your problems does not go down, why did you create it? Think about it. Creating a DSL is an expensive proposition. Making people learn your DSL’s syntax, semantics, and underlying domain is a lot to ask – it’s costly. If you do ask, if you do make the imposition, you had better be sure your DSL pays its bills.
But what if your DSL turns out to be a deadbeat? What if using your DSL doesn’t lower the cost of solving problems? Well, guess what? You have created a Gratuitous Domain Specific Language.
Still unsure of whether you’re on the DSL Train for the wrong reason? No problem. Just take this simple, seven-step test:
Seven signs you may have created a Gratuitous Domain Specific Language (GDSL)
- You can’t actually explain what a DSL is.
- For your DSL, you can’t explain what the domain is.
- You have a hard time explaining the DSL’s syntax and semantics.
- You have a hard time explaining how the DSL interacts with the language it is embedded in. (For embedded DSLs only.)
- A vanilla library API would have captured the domain’s semantics without awkwardness.
- It’s easier to express complex domain concepts in general-purpose code than in your DSL.
- Your colleagues have a hard time writing things in your DSL.
Did more than a few of the statements ring true? If so, take a bow. You are the proud creator of a Gratuitous DSL!1
Even so, it’s not too late. You can always hop off the DSL Train at the next stop.
1. Rationale for the Seven Signs. Signs 1–4 suggest that your DSL may not even be a DSL. Signs 4–7 suggest that, though your DSL may be real, it may not be paying the bills.
Update 2008-03-22: edits for clarity.
I was just at a Ruby conference in N.C. last week where several talks were devoted to using Ruby to create DSLs. Ruby’s syntax seems particularly suited to it. The Ruby crowed seems particularly taken with them.
While they can be incredibly useful, I get your (tongue-in-cheek) point that you should know how, where, and why to create one and when not to.
I can’t speak for the Ruby crowd, since I don’t follow their fad.
In short, I would say,
“DSL is to bottom-up design as API is to top-down design.”
But, then again, TLAs do get annoying.
“Making somebody else learn about the domain and your DSL’s syntax and semantics is a lot to ask – it’s costly.”
Its not costly. If its costly, then the DSL is wrong.
A DSL should express something in an easy, logical manner. Straightforward. People should look at it, people should understand it.
But I tend to agree with you, since the last some months I have noticed that different people refer to something as “DSL” when it in fact is just plain and simple markup or annotation language, be it XML like, YAML like, CSV files, or similar.
A DSL should also be not too simple, because if its tooooo simple, then you probably didnt have a real problem to solve by using a DSL! (And could have solved already by using ie. a yaml file that stores it all ready-made…)
“I can’t speak for the Ruby crowd, since I don’t follow their fad.”
Let me put it to you mildly – there is no hive mind in any “crowd”. There are DIFFERENT people with DIFFERENT opinions. And you know what? This is not unique to “the ruby crowd”. Lets all concentrate on what is important – a DSL can have advantages. Lets point out at that. If it doesnt, then why have a DSL? In cases it just feels like API invocations, which I believe shouldnt qualify as a DSL.
“DSL is to bottom-up design as API is to top-down design.”
You describe it by introducing “bottom-up design” and “top-down design”? Sounds too complicated man;)
8. Your domain specific language is Turing complete
My understanding of DSL comes from Common Lisp, not Ruby. Ruby coders makes a lot of noise about meta-programming, but the language itself has relatively terrible support for it. However, every Ruby programmer I talk to raves about it. This misplaced enthusiasm is probably the origin of some of the skepticism towards “DSLs.”
I may be misinterpreting your sarcasm. “Bottom-up” and “top-down” design are old terms and pretty simple ideas. I’m also referencing Paul Graham here. I don’t care much for the guy, but he’s written a lot about this stuff. His essay from ‘93 named “Programming Bottom Up” practically defines what would later be called “Domain Specific Languages.”
When I hear, or talk about, DSLs it is that essay (and subsequent works) which comes to mind.
Surely if you’re going to have to explain the domain to somebody else at some point – programming, whether a DSL or an API without having at least some grasp of the domain is just asking for trouble.
Generally, I’m with chromatic though; it’s almost never a DSL. But I also believe that any large programming project ends up being language design. How we choose to break the problem up, what we call the bits and how we compose them is, within certain constraints, a matter of taste. Breaking the problem down into components that are easy to reason about in the language of the problem domain (NOT the same as a DSL) is a good goal to aim for.
Piers Cawley wrote:
Indeed. When one thinks of DSLs, one thinks of an associated domain that exists (or can exist) outside of the DSL. The essential form of the domain – the sum of its natural characteristics that will be manifest in any representation – strongly influences the domain’s programming-world representation, DSL or otherwise, and no programmer who uses this representation can avoid learning something about that essential form. Just as you said.
What I’m trying to get at is that when programmers invent a “DSL” to supplement an imagined deficiency in vanilla APIs, there is no real domain whose essential form guides the language’s creation. It’s the other way around. By creating the DSL, they implicitly create an associated domain, shallow though it may be, and foist it on the DSL’s users. This domain, however, has no essential form; it is an artifact of the DSL’s creation: a nebulous amalgam of the creator’s language-design prejudices. As a result, it contributes an artificial learning cost to all who must use the DSL.
Agreed, completely.
Cheers,
Tom
Ah yes, of course. The DSL that creates its own domain (and does it badly). I hadn’t thought of that possibility.
Of course, if you’re a genius, your DSL could ‘create’ a domain that nobody else had spotted, but geniuses are depressingly rare in this industry.
Thanks for the clarification.