A Domain Specific Language (DSL) is a programming language designed specifically to express solutions to problems in a specific domain. * One of the prerequisites of being a DSL is actually being a language. * ''how about regex, is that a language? sort of, kind of. Depends on your definition of language. Regex is definitely domain specific, but not really a full language. Is a wildcard a language? it's just asterisks. When does the wildcard become a language? only when it is complex as regex language?'' The former may or may not be TuringComplete (though even if they are, they are generally not useful outside of the problem domain). The latter could use method chaining... 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 * ''You don't have to call it from an ObjectOriented application. A domain specific language is a language, not just an API. The Windows API is not a domain specific language.'' * The OO example ''is'' an example, not a statement of requirement. And are you implying that the Windows API is a GeneralPurposeProgrammingLanguage? ^_^ RE: DSLs can implement as FreestandingDomainSpecificLanguage''''''s, or EmbeddedDomainSpecificLanguage''''''s; elaborations of a base language's calling syntax. * ''The base language may be the language you are thinking about - this sounds more like DomainSpecificTweaks to an existing language, if one is heavily making use of the base language grammar, syntax, notation.'' * No, I'm fairly certain we're thinking about EmbeddedDomainSpecificLanguage''''''s - e.g. a language designed for describing graphs declaratively embedded into a procedural language. These might be 'tweaks' by some definition of the word, but that doesn't seem very well defined - what is 'just' a tweak? What we can say for sure is that these can possess dedicated syntax and semantics to describe or program something in a rather specific domain, and thus are DomainSpecificLanguage''''''s. ---- DomainSpecificLanguage''''''s can be broken up into two types (doubtless there are many other possible and useful taxonomies, of course) * FreestandingDomainSpecificLanguage''''''s--Languages which are ''independent'' - not extensions to any particular host language (and can be implemented in any host language which is convenient). When one programs to such a language, ''only'' the functionality specified by that language is used. Some DSL's of this type may provide ways of calling "native" code implemented in a GeneralPurposeLanguage, but this is an optional feature. * EmbeddedDomainSpecificLanguage''''''s--languages which are ''dependent'' on a host language, and may be viewed as extensions to that host language. In many cases, the host-language primitives for flow-control and such are used; host language code can be invoked at will, and the DSL cannot live apart from its host language. Many DSLs implemented as LispMacro''''''s (or using macro systems in other languages) are of this category; the macro system translates the DSL to the host language. (Not all dependent DSLs are implemented this way; some are implemented as modifications to the compiler or interpreter of the host language, CeeGeeLanguage is an example of this.) Well-known examples of DomainSpecificLanguage (see more examples under LittleLanguage): Note that "domain specific" can depend on your point of view; one man's application is another man's middleware. * CRobots - An old DOS game where you could code robot behavior in a DSL. * PostScript. One of the most successful; domain is ''page rendering'' (both on screen and on printers). Independent, though has lots of ForthLanguage heritage. * CeeGeeLanguage. Extension to CeeLanguage developed by Nvidia and others for high-performance graphics programming (e.g. games). * StructuredQueryLanguage. Domain specific from the point of view of a database guy. Independent. ''OTOH, the specifiers of SQL were clearly hitting the CobolLanguage bong.'' * '''make''' macro language (at least the flavor supported by Gnu make and other sophisticated versions of Make). TuringComplete DomainSpecificLanguage which does simple text processing, coupled with a graph reduction system that analyzes file and build dependencies (coupled with an OS shell, also TuringComplete). The macro language which is part of most makes uses modified EssExpressions (a list is encoded as $(a b c) rather than (a b c) - that's the main difference). Technically independent; though most Makefiles are highly dependent on the BourneShell (the Make macro language, though TuringComplete, is crippled and uses shell commands to interact with the real world). * Some consider sed, awk, etc. to be DomainSpecificLanguage''''''s (although the domain there is an implementation domain rather than an application domain) * TexLanguage; a typesetting language developed by DonaldKnuth; one of the greatest hacks of computer science. TuringComplete, and quite powerful; with a complete macro facility. In fact, many DSLs have been implemented on top of Tex, including... ** LaTex, a macro package for Tex which provides higher-level abstractions (though still for general-purpose document formatting) ** BibTex, a macro package for Tex which specializes in handling citations/bibliographies for scholarly works * VAL (VoiceApplicationLanguage) used in the programming of systems connected to specific telephonic equipment (like Siemens switches). This language is not TuringComplete, nor does it permit access to external language constructs that would provide completeness. It is, however, ''almost'' completely adequate for call routing, holding, voice menus, and so on. ** I'm familiar with voice xml, but what is VAL? Googling seems to yield lots of hits, but all completely useless ones. Is there an overview/intro/tutorial/reference manual online? ** VAL is a language tied to a specific switching system (it's been years, but I believe it was Siemens). It allowed the programmer to vector to specific routines based on selected events. One thing it could do was write files in response to events, so we could use external stuff written in [language of choice] to watch for the appearance of new files, read them, and take appropriate action at operator consoles for call routing and such. I have no idea what documentation may have survived. I used it ten years ago, and it was old when I got there. * ExBase ---- Allow me to dither here, maybe something good will come of it... And if not, there are always WikiGnome''''''s 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 EnDeme''''''s grew until it used up every printable character in the ASCII character set. These days I limit EndemeSet''''''s 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 RealProgrammer''''''s 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 DomainSpecificLanguage''''''s, if done correctly, is a good thing, I run into too many ThreeStarProgrammer''''''s'''''''s who think their hacked-together collection of LispMacro''''''s, 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? :-)'' * Most of the times I've run across such designs, the result was of questionable quality. (Including the times ''I'' was the one engaging in the MetaProgramming and/or GreenSpunning). In some cases, MetaProgramming efforts arise out of a well-articulated need and are developed with a clear set of requirements in mind, by folks with the necessary DomainKnowledge. In many cases I've seen, it was someone's ego trip (again, including myself to some extent, I regret to report) - a case of "I'll provide this kewl framework/language/library that solves all the world's (or at least the company's) problems, so that the other programmers on the team won't trip and hurt themselves trying to implement in raw ." Live and learn. Probably the hardest trait for a good programmer to learn is humility. :) ---- 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. -- AlanCameronWills ---- An excellent discussion on DomainSpecificLanguage''''''s can be found in section 5.5 of the GenerativeProgrammingBook. ---- One issue to consider for DomainSpecificLanguage''''''s 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 EssExpression''''''s 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 FreestandingDomainSpecificLanguage''''''s? 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 EmbeddedDocument''''''s 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: * language that hides the execution order (or time aspect) of the program. * language that hides the execution of non-functional (out of business domain) code. ShaiBenYehuda. ---- '''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 QuoteFreeLanguage''''''s 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 ---- CategoryProgrammingLanguage