Domain Specific Language
Domain Specific LanguageA Domain Specific Language (DSL) is a programming language designed specifically to express solutions to problems in a specific domain.
root.up.twist.up.right.branch(root)...or argument chaining...
User.find(:all, :conditions 'debt > 42')...or the ExecuteAroundPattern:
sample = Sample.new do
string "override!"
action { |name| puts "Do something, #{name}!" }
end
As a DSL grows, it approaches the GangOfFour InterpreterPattern.
Wiki sites devoted to domain-specific languages include http://www.program-transformation.org/ and http://www.cwi.nl/projects/dsl (BrokenLink).
RE: It provides a declarative syntax, and you call it from an ObjectOriented application that uses a procedural syntax
DomainSpecificLanguages can be broken up into two types (doubtless there are many other possible and useful taxonomies, of course)
Allow me to dither here, maybe something good will come of it... And if not, there are always WikiGnomes lurking nearby, ready to snip out any cancerous growth.
First Observation:
Something perhaps ignored (deliberately?) in this discussion is the TowerOfBabel effect that results from having so many languages that a person needs to be familiar with (if not master) in order to get common jobs done.
Sometimes I want to do something in, say, Vim's macro language, which is syntactically Algol-like, and somewhat, but not entirely, dissimilar to C. Therein lies my hesitation. It's not C, but Algol is so close that I may get confused about what language feature I can and can't use in a solution. So I've limited my use to the rc file where I can pretty much copy and paste.
Second Observation:
I have implemented a few DSLs and agree that nothing is better than having your own LittleLanguage to do a specific job. It allows for concise expression of solutions to specific problems. But a problem arises when TheNextGuy comes along and has to learn the concepts behind the language, the motivations for particular elements of it, the syntax, etc.
When you use a scripting language there is a tremendous pressure to leverage the performance of built-in functions instead of writing stuff in script. This is why the library of built-ins for scripting languages used as general purpose languages grows until, or even after, it has reached unmanageable bounds. (LispLanguage is the oldest example. But PHP, Perl, etc. also rank high.)
So, when inventing your own DSL, make sure its domain is small and bounded, or it may grow into a monster!
My first attempt to develop EnDemes grew until it used up every printable character in the ASCII character set. These days I limit EndemeSets to 22 characters -- JonGrover
But when a cross-domain solution is needed, many different languages may have to be employed for a complete solution, and you have Babel in a breadbox. The developer(s) will have to be polyglot. But, then, all RealProgrammers are.
Third Observation:
Any sufficiently large software project becomes a DSL by virtue of the library of functions built up to implement the solution to the specific problem the project was concieved to address.
(That sounds a little bit like the Lisper's claim that eventually all large software projects include some kind of implementation of Lisp, but I haven't worked on a project that big yet, aparently.)
And the TowerOfBabel effect applies to anyone joining the project late in the game or during the maintenance phase.
Fourth Observation:
The not surprising and very obvious point is that every software project becomes a DSL.
-- BobBockholt
Some languages actually encourage this outcome. ForthLanguage is one such.
[Forth in fact is a DSLL - a domain specific language language. The fact that there are no reserved words or symbols at all (and almost no syntax) means that the programmer can craft a language for their problem in any way they see fit. The use of persistent scopes via vocabularies and swappable dictionary search orders means that a different DSL can be crafted for specific parts of the overall program and then re-used or modified for other parts. This tackles some of the issues raised in the next observation by allowing these mini-DSLs to be adapted to similar contexts rather than being either rebuilt from scratch or made so flexible that they no longer serve as "domain specific" in their original context.]
And a Fifth Observation
Writing a decent DSL is hard. Very limited, very simple DSL's can be adequately produced by a competent programmer with expertise in the problem domain - DSL's that can be described on a page or two, and are tailored to a specific application/environment. These language are seldom usable outside the very limited context - which is OK; if writing the DSL improves the productivity of the team, it was a good thing to do regardless of whether or not it gets reused elsewhere. (OTOH, if it doesn't improve the productivity of the team than it shouldn't have been written).
But writing a good DSL that is robust and reusable beyond a limited context, is a lot of work. It requires persons with both domain expertise and language design expertise (not necessarily the same person) to pull off. A truly reusable DSL will require reasonable documentation, otherwise it won't survive the departure of its designers. And, it will eventually require a good set of tools - debugging environments and the like - for it to become worthwhile.
Many of these issues are discussed in MetaProgramming as well.
Looking at the DSLs on the list above; a tremendous amount of effort went into making each and every one; moreso than is spent on most IT projects. Some of them came out of academia, industry research labs, and/or hobbyists and through the magic of OpenSource (long before the term was ever coined) were gradually improved on. Others were specific and dedicated projects undertaken by corporations for a specific purpose (often the language, while domain-specific, was intended to be an independent product; not an implementation detail of some larger system).
While writing DomainSpecificLanguages, if done correctly, is a good thing, I run into too many ThreeStarProgrammers's who think their hacked-together collection of LispMacros, C++ templates, or whatever else a) is the next coming of PostScript, and b) makes them better (or at least more "meta", see TripleMeta) than the programming grunts who stick to writing functions and creating objects in the language itself, rather than indulging in MetaProgramming.
Does this actually come up at all frequently? Or is it just that the few times that you've run across such people, they were intensely irritating to you? :-)
A frequent problem is inventing a language you think is going to be small, and then finding reasons to extend it piecemeal over the years. Such languages become pretty baroque. For example, there was a workflow language a while ago that started off with simple sequential paths that took a workitem from one user to another. Then after a few months they decided they wanted conditional branches; then after a year, they introduced loops. Then (after much effort and hassles with backward compatibility) in came subroutines (though parameters came a while later) ... and so on. And the odd thing was that neither the creators of the language nor the users thought of it as a programming language -- so they took quite a lot of intellectual effort to invent each concept, and mostly the solutions were a bit weird. Variables, when they came, were called 'repository accessors' and had tortuous scoping rules.
So my feeling is, recognize your language as such early, and put some resources into designing it a bit larger and more extensible than you need it to be. YouAreGonnaNeedIt.
An excellent discussion on DomainSpecificLanguages can be found in section 5.5 of the GenerativeProgrammingBook.
One issue to consider for DomainSpecificLanguages is the syntax. Many Lispers claim that Lisp programmers don't really program in Lisp; they do so in a DSL which is implemented in Lisp--and I'll buy that claim for this discussion. But the DSLs they generate sure look a lot like Lisp--it will almost assuredly use EssExpressions for syntax, and will undoubtedly be Lispish in other ways. Which isn't necessary a bad thing if its an EmbeddedDomainSpecificLanguage--those are intended to depend on the underlying domain-independent language.
But what of FreestandingDomainSpecificLanguages? How to imbed those in a host language? If you splice the DSL into the host language, and the DSL knows nothing of the host language's formatting rules, you run into the EmbeddedDocuments problem. One common solution is to keep different languages in separate files; but that isn't always desirable; sometimes closer coupling between the two is what you need.
Many good freestanding DSLs have a syntax that reflects the problem domain--and some aren't really text based at all! Unfortunately, SyntaxMatters.
What about declarative DSLs. I believe domain specific declarative languages tend to be simpler.
My suggestion for the definition of declarative DSL:
UnifiedModellingLanguage (or ?UnwantedModelingLanguage or UselessModellingLanguage?) and DomainSpecificLanguage
An MS person view on why UML is unsuited at http://blogs.msdn.com/alan_cameron_wills/archive/2004/11/11/255831.aspx
A MarkupLanguage can be seen as a narrowly focused domain specific language. Even more narrowly focused are various MicroFormats? (see the microformats wiki http://microformats.org/ ).
I'm leaning toward the belief that QuoteFreeLanguages may be better for DSL's because one uses more constants. At least it's an idea I'm playing with. -t
See LanguageOrientedProgramming
See LittleLanguage, DomainSpecificProgramming, SubLanguage, WorkBackwardFromPseudoCode, ExBaseRant
EditText of this page
(last edited December 14, 2014)
or FindPage with title or text search