« Speaking in Russia | Main | Intelligent Design and Conway's Life »

November 28, 2008


Michael Finney

Yes! Like any breadwinner of the family, keeping the resume in mind is a must.

"In negotiations, they will factor in the cost of working with little known technologies."
True. I tried that once with the technology WebObjects (Apple.com). The manager didn't bite. The company closed the office anyway. It made my life a little harder trying to find a job. In interviews, I kept having to explain what WebObjects is.

Links to "embedded DSL" good practices would be great. Anyone?

"Dynamic languages like Ruby are ideal for embedded DSL construction..." That's good to know.
From what I have seen, Ruby is a little known/used language. Sure it made the list at TIOBE http://tinyurl.com/3xutoh
I give it the appropriate amount of time, but not as much as I would like.

IMHO, "embedded DSLs" need their own letters, eDSL or IDSL for Internal Domain Specific Language

Great post!

Steve Freeman

I remember going to a workshop on DSLs nearly 10 years ago. One point that many people raised is that successful DSLs should be small and focussed. They should do just one thing really well, which makes them easy to pick up and does not tempt anyone into treating them as full programming languages.

For internal DSLs, I guess we have to wait for the return of Lisp, or hope that a language like Fortress (which has extensibility as a goal) eventually makes it :)

Andrew Stone

"If you are creating an external DSL, consider open sourcing it"

Right on. The explosion in open source is not due to altruism, but becuase it makes good business sense. Just look at Erlang. Ericsson dropped Erlang for a number of reasons, and it would have died a brutal, horrible death if it wasn't open sourced.

Companies invest in DSLs because they need to solve specific problems in a domain. What most of them fail to realize is that opensourcing a language is much more of a benefit then the potential loss in proprietary technology to a competitor. Repeatedly we see the strongest growth in technologies coming from de-facto standards due to wide use, rather than industry consortium attempts. Opensource also provides customers with a behind the scenes look at the talent of employess at a particular company and may infact have a direct impact on company valuation. Furthermore, if the technology becomes widely used it drives more developers to want to work for the company rather than shirking away because they won't be able to use the DSL on their resume.

I guess my point is: Don't be afraid of opensource.

Marcelo Lopez

External DSL's also have one particular issue with them, and that is that the grammar is completely left to the designer, and often times, some of the "good housekeeping practices" we abide by in more formal languages are tossed for the sake of expediency.

When there is no formalism behind how the syntaxis of a language, and the semantics of that syntax are expressed and the flexibility they provide to your end user, you end up with an "exception is the rule" language to fit the circumstance, and that as you've deftly pointed out is where you end up with these "niche skills". What you can best walk away with from a circumstance where you've worked with an external DSL is to learn from it's limitations. Remember "what NOT to do" when designing/implementing such a construct as the basis of a product.

Chui Tey

The pain point with custom DSLs is in the debugging, and extending. Embedding interpreters is pragmatic, but might not suit a DSL which is more declarative than imperative.


"If you are creating an external DSL, ..."


Too many people who thinks they are competant programmers, make the mistake of thinking that just because they can program a new language, they should.
But its more like the difference in being able to write, and being a successful novelist.

- Paddy.

Sebastian Kübeck

Is there a book or scientific research papers out there with design patterns or other guidance on external DSL design?
I mean it's easy to bash bad external DSL designs but it is unfair to demand good ones if nobody ever observed them systematically.

Johan den Haan

"Is there a book or scientific research papers out there with design patterns or other guidance on external DSL design?"

There's a great scientific article on this topic:
Mernik, M.; Heering, J. & Sloane, A. M. When and how to develop domain-specific languages ACM Comput. Surv., ACM, 2005, 37, 316-344

Sebastian Kübeck

Thanks for the info! I withdraw my last comment.

Markus Kohler

Fully agreed.
"External" DSL's really almost always suck.
Language design is intrinsically hard stuff.

With expressive languages that have support for closures and other advanced features, internal DSL's are really powerful enough.
And their other main advantage is that you don't need to implement all the infrastructure around the language again.
You not only need a compiler, you also want an IDE, a debugger, a code coverage tool etc.


Hi Michael,

It seemed that you at least have two blog. I want to see your "10 must read papers", but it seemed that your other blog is not accessible here in China (Hangzhou, where you used to work together with us).
Can you also put it here, or what's the problem with the other one?

Trying to contact you via twitter, but you are not following me:-) I'm terryyin.

br, Terry

Amos Wenger

>> Trying to contact you via twitter, but you are not following me:-)

+1, I'm amoswenger on Twitter =)

Steven Kelly

@Sebastian Kübeck: "Is there a book or scientific research papers out there with design patterns or other guidance on external DSL design?"

You're right that there's too little out there that is based on actual experience. At MetaCase we've been building external DSLs for over 15 years, both for and with our customers, and wanted to do our bit to improve the situation. I've written a book with Juha-Pekka Tolvanen, explaining about Domain-Specific Modeling and how to create your DSLs, build tool support for them, deploy them, and maintain them:
- Domain-Specific Modeling: Enabling Full Code Generation, Wiley 2008

and recently with Risto Pohjonen an article that sounds similar in title to Michael's post, but goes somewhat further in providing actual advice on "how to fail":
- Worst Practices for Domain-Specific Modeling, IEEE Software, July/Aug 2009

The comments to this entry are closed.