Last Friday Rocky posted an entry on his weblog entitled “DSLs – fun, cool, but maybe a bad idea?” and my reaction was:
Maybe a bad idea? Maybe a bad idea? Of course they’re a bad idea!
This may seem strange coming from someone who’s working on the heart of Oslo/M’s DSL capabilities, but stick with me here.
To begin with, writing a new language, domain-specific or not, is a lot like opening a restaurant: everyone thinks they can do it because they’ve eaten at one and it looks like fun. But the truth is that something like 50% of restaurants fail in the first year, and probably 90% fail over the long haul. It’s incredibly difficult, time consuming, and hard to keep a restaurant as a going concern-but doing that while actually coming up with something people want to eat is nearly impossible. I’m amazed new restaurants open up at all, given the odds.
Languages are the same way. It’s mind-bendingly, stupendously difficult to build a new language, even one that’s largely based on an existing one. Yet many programmers think, “hey, I use languages, how hard can this be?” and go at it. Like restaurants, probably over 98% of them fail to ever gain any traction at all, but god bless the optimists because without them we’d never get the 2% of languages that succeed. I’m personally willing to sacrifice the millions of dollars and hours wasted on languages that never make it just so that we can get languages like C# and Java and Ruby and Python and so on. (One language omitted to preserve at least the appearance of humility.)
So the fact that coming up with a new language is a bad idea shouldn’t dissuade people from developing new DSLs, it should just give them pause and hopefully a little humility. The key, I think, is to start small and to stay small. A domain-specific language needs to stay, well, domain-specific and not try and branch out to become a general purpose programming language. The problem is that it’s really, really hard to resist the temptation to do that. You just have to keep in mind that all the really successful DSLs have remained little languages, and repeat that to yourself every day. If you do that, you’ll be fine. Or, put another way:
Remember kids, DSLs don’t kill people, people kill people.
Ahh, a provocative headline followed by an article containing tons of backpedaling. Good luck with your, thing, there.
people kill languages.
Your analogy with a restaurant is not correct, because most DSL’s are not designed to be used by everyone in the world. They are domain specific! Designed to be used by a specific company or department. As such, they are more like a canteen. And opening a new canteen in a crowded workplace where people have to pay a lot to eat outside is a lot less risky than opening a public restaurant, don’t you think?
If you end up with a DSL containing its own general purpose programming constructs then the point has definitely been missed. This is particularly going to be a problem with external DSL where you cannot reuse existing language constructs, though you do get the benefit of a purer syntax that will not corrode into scripting after a few cycles that miss updating the DSL.
Oslo is going to be a fun ride, but hopefully not in the same way as a 1960’s F1 race.
Digital Subscriber Line?
I am sorry, but it took me a while to realize that you mean Domain-specific language.
Hi, i don’t get it. I read the post twice but i don’t see an answer for the question: Why?. You pointed that implementing a new general purpose language is very difficult and because of that we should keep DSLs domain specific. I agree with that as well. That’s obvious but it doesn’t answer key question – Why?
"A domain-specific language needs to stay, well, domain-specific and not try and branch out to become a general purpose programming language."
I agree, but as long as you stick to that principle DSLs aren’t all that hard to build (as long as you know how to build a language and parsers) and incredibly useful in abstracting out the domain specific parts of your problem space.
DSLs are a good idea, of course!
Seems there is a general idea developing around this. I called it the YADSL rule. Check out: http://tigerops.org/?p=15
I may not have been very clear in my attempt to be cute — I think DSLs are a bad idea because it is so easy to abuse them. We can all seem to agree here that DSLs should stay domain specific, but in practice DSLs that manage to survive very long inevitably slide towards becoming full featured programming languages. It’s extremely difficult to fight against the tide and accept you’re just opening a company canteen when you think "how cool would it be to have a famous restaurant?"
I think that Paul may be correct in what he has said but I may disagree in his title of his article.
As an implementor of a full blown language implementation, I can agree that it is a much larger effort frought with many more details and dfficulties than first (or second) imagined.
Trying to invent the next major general purpose language is also like trying to set out to become the next major sports superstar. The probabilities that yours is going to be better than those that would otherwise succeed is very low indeed.
Also DSL tools may not be the best tools to accomplish the goal of general purpose language implementation because they are not really designed to support all of the functionality required for that task.
But the other side of the coin is that general purpose programming languages are notoriously bad at describing or capturing Domain Specific intent in an efficient way. That’s where Domain Specific Languages come in. Their purpose is to be a more efficient and direct mapping of the Domain Specific intent into some functional implementation. Properly designed DSL’s usually don’t need to be very large or complicated. It is even posible embed an escape mechanism to use a general purpose language inside a DSL, if needed, in order to take advantages of the best qualities of both.
DSL’s when properly designed can be a very beautiful thing when used in the Domain for which the were intended and in that case are far from BAD or a BAD idea.
I think that DSL’s and general purpose languages are related but are designed for very different purposes.
So you basically had a good title for a post but then figured out you really don’t have anything to say about the subject. Nice.
So how about allowing a mix-and-match between DSLs and existing languages to bridge some of those difficulties?
Make it easy to import existing language constructs (from C#, VB, etc) into a DSL for the general language constructs. Also allow for DSLs to be embedded into [C#/VB/xxx] code. The latter a bit like ESQL/C but now 20 years later; "embedded [DSL]".
I think that it would be a good idea and very useful if Oslo’s MGrammar would provide an escape mechanism or the ability to call other .Net languages or DLL methods from within a MGrammar module. Of course there would need to be parameter passing of data from the MGrammar Parser to the called routines and greater access to the information that the MGrammar module knows while it is parsing.
Good Ol’ Yacc is an example of the type of functionality needed to gather data during parsing and passing this data to routines coded in C.
I think that this is an importanat feature that Oslo’s MGrammar seems to currently lack.
Boo and LINQ both promote the idea that you dont have to build a language from scratch to get a DSL; you can and ought to extend and embrace the standard language as it is to enrich it for your own companies use. Thats really the heart of DSL, not going off and writing entirely new langauges. This parallels earlier movements with BPEL + BPM: people werent writing stand alone DSL’s, they were wiring components via standard interfaces written to present a coherent domain logic.
I the DSL hype finally starting to fade?
So, "bad idea unless you know what you’re in for"? I suggest that one reason for the high didn’t-pay-off rate is that the focus and skills necessary for the technical implementation (whether DSL or GPL) are not commonly combined with high levels of (1) empathy – to understand how others think about *their* problems/tasks, (2) teaching – to help others understand *my* language’s way of doing things, and (3) salesmanship – to promote *my* approach over the inevitable initial objections and learning hurdles. One human can only do so much!
Yeah. It is strange indeed to read this from someone who’s working on the heart of Oslo/M’s DSL capabilities. I mean if you are working at the heart of Oslo/M DSL, what stops anyone else from being at the heart of another potentially more powerful DSL? DSL implementation is only as hard to implement to the extent of the determination and mastery of the developer.
It’d be nice if someone would define DSL and give a good example of when you might need it and why.
Cause everything I’ve seen thus far, DSL is a big fancy name for "a bunch of methods"
"In software development, a domain-specific language (DSL) is a programming language or specification language dedicated to a particular problem domain, a particular problem representation technique, and/or a particular solution technique."
One designs a DSL when it is desired to create a new language that contains a syntax and vocabulary that more efficiently and directly reflects the Problem Domain.
For example, in the Gaming world, you may construct a DSL that more directly reflects the elements encountered in game design, animation and decision making. In the Financial world, you may construct a DSL using recognized financial terms and vocabulary. By designing the vocabulary and structure of the DSL to the problem domain you can gain greatly in efficientcy and expressiveness of the DSL to represent the details of the problem domain as well as enable to possibility of non-programmers to express their intent directly in an executable DSL environment.
Most general purpose programming languages do not allow their syntax and structure to be altered enough to create an efficient DSL. But it is possible for DSLs to transform their input language into a general purpose language output syntax for execution.
DSL can be textual, graphical, or a combination of both.
DSLs difinitely have their place in this world. I do not think that their need will dissapear anytime soon. But there certainly is some improvement that can be done with DSL creation tools to make the spcification and implementation of DSLs easier and more powerful.