Originally posted by manuel aldana:
often textual representations of a DSL can head you to a target quicker and easier.
Concepts of the domain in question are expressed and manipulated directly following the domains convention's rather than indirectly in some general purpose programming language or graphical notation. The resulting script should therefore be clearer
to someone who is knowledgeable in the domain, more concise and is often completed much more quickly.
Many domain experts don't want to learn UML to then awkwardly represent their domain or having to come up with a new UML profile. They rather deal with the problem in terms they understand. A textual DSL is often the quickest solution. A graphical DSL only makes sense if there is a pre-existing graphical notation that can be easily manipulated to convey the necessary actions.
Back in 1986 Jon Bentley called DSLs
Little Languages.
Programming Pearls 2e (
amazon US) p.28:
But special-purpose languages are still useful in certain applications. I despise having to use a mouse to poke at a faux calculator on the screen when I really want to type straightforward mathematics like
n=1000000
47 * n * log(n)/log2(2)
Ultimately Domain Driven Design (DDD) tries to approximate the utility of a full blown DSL in terms of OO - it is usually employed when a domain model does not exist or existing ones are inadequate for the task at hand.