DomainSpecificLanguage

Work in Progress. Heavily Under Construction. While reading this page, you are likely to be eaten by a grue.

A DSL is a programming language designed for, and intended to be useful for, a specific kind of task. Through appropriate notations and abstractions, a DSL offers expressive power focused on, and usually restricted to, a particular problem domain.

DSL are much more expressive in their domain because they are built around domain idioms, that is operations that programmers define to handle common development task in a specific domain.

SQL and XSLT are two good examples of DSL. (Compare SQL to e.g. the Rails ORM vocabulary to get a feeling for what is the difference between a DSL and a programming library used as a DSL.)

A DSL is not just a library in your favourite programming language. A DSL is a language, so it should define its own grammar (or at least some kind of extension to the grammar of an existing language) alongside adopting the vocabulary of the particular domain it was designed against.

It is certainly possible that a DSL is programmed so as to be used as a library (in this case, it is defined as Embedded DSL); however, if the DSL is not defining its own grammar, the programmer is just using different nouns with an existing grammar: to qualify as a language, both nouns and verbs should be defined.

Application libraries used as DSL are important anyway:

design a new language, albeit small and domain-specific, can be difficult
programmers do not need to learn new grammar/syntax to use domain-specific functionalities

Such libraries are useful to bridge the gap between science (intended as the formalization of a grammar) and programming (intended as making the computer perform a task). Indeed, even with improved DSL development tools (which are currently not available), application libraries are probably going to remain the most cost effective solution in many cases.

However, application libraries do not really qualify as a language; at the very least, they are severely constrained by how much the host language allows its grammar and/or syntax to be redefined (e.g. the simplest form of flexibility seems to be adding new operators and allowing operator overloading). Nonetheless, depending on the language domain, the importance of syntax (also as opposed to the importance of vocabulary) may be debatable: only if a particular notation is commonly used in the language domain, the corresponding syntax need to be enforced at the DSL level; in other cases, creating a DSL from scratch instead of building a library may only benefit the avoidance of unnecessary host language syntax at a hardly bearable cost, when analysis, verification, optimization, parallelization, or transformation in terms of DSL constructs is not needed.

Reasoned Linkagerie (or whatever you would like to call it)

Domain-specific programming language - Wikipedia, the free encyclopedia: (because you just need to begin with the mandatory Wikipedia link) Blurries too much the line between DSL and programming libraries. The doubts expressed about XSLT as a DSL are arguable. Provides a good list of DSL advantages and disadvantages.
Domain Specific Language from the C2 wiki: (because C2 existed well before Wikipedia) Contains a richer DSL definition.
Little Languages, by Jon Bentley, Communications of the ACM, 29(8):711-21, August 1986: A bit outdated but a pleasure to read. (Reminds me of The Pragmatic Programmer.) Clearly follows the "real" language path, favoring preprocessing and composition over embedding.
When and How to Develop Domain-Specific Languages, by Marjan Mernik, Jan Heering, and Anthony M. Sloane, ACM Computer Surveys, 37(4):316-44, December 2005: A really interesting survey on each and every aspect of DSLs and DSL creation. Proposes patterns for the following DSL development phases: decision, analysis, design, and implementation. Most real-world examples are unknown (or at least known in their application domain or at the DSL academic level only). The cost-benefit analysis in the second half of 2.5.2 is a bit confusing. There are probably at least 24 valuable (plus 4 arguably valuable) entries in the bibliography, excluding analysis methodologies; where I will find the time not to read them?
Generative Programming: Methods, Tools, and Applications, by Krzysztof Czarnecki and Ulrich Eisenecker, Addison-Wesley, 2000: Contains just a six-page section on DSL, but it's more precise and insightful about some details than many other sources surveyed up to now.