Domain-Specific Languages

From WikiContent

(Difference between revisions)
Jump to: navigation, search
Current revision (05:02, 19 July 2009) (edit) (undo)
 
(One intermediate revision not shown.)
Line 1: Line 1:
-
Whenever you listen to a discussion by experts in any domain , be it chess players, young mothers or insurance agents, you'll notice that their vocabulary is quite different from everyday language. That's partly what domain specific languages are about.
+
Whenever you listen to a discussion by experts in any domain, be it chess players, kindergarten teachers, or insurance agents, you'll notice that their vocabulary is quite different from everyday language. That's part of what domain-specific languages (DSLs) are about: a specific domain has a specialized vocabulary to describe the things that are particular to that domain.
-
They're about executable expressions in a language specific to a domain with limited vocabulary and grammar that is readable, understandable and hopefully writable by domain experts.
+
In the world of software, DSLs are about executable expressions in a language specific to a domain with limited vocabulary and grammar that is readable, understandable, and — hopefully — writeable by domain experts. DSLs targeted at software developers or scientists have been around for a long time. For example, the Unix little languages found in configuration files and the languages created with the power of LISP macros are some of the older examples.
-
DSLs that were targeted at software developers or scientists have been around for quite a time. The unix little languages found in configuration files or the languages created with the power of LISP macros are some of the older examples.
+
DSLs are commonly classified as either ''internal'' or ''external'':
-
When talking about domain specific languages Martin Fowler makes the well accepted distinction between internal and external DSLs and language workbenches.
+
:'''Internal DSLs''' are written in a general purpose programming language whose syntax has been bent to look much more like natural language. This is easier for languages that offer more syntactic sugar and formatting possibilities (e.g., Ruby and Scala) than it is for others (e.g., Java) that do not. Most internal DSLs wrap existing APIs, libraries, or business code and provide a wrapper for less-mind bending access to the functionality. They are directly executable by just running them. Depending on the implementation and the domain, they are used to build data structures, define dependencies, run processes or tasks, communicate with other systems, or validate user input. The syntax of an internal DSL is constrained by the host language. There are many patterns — e.g., expression builder, method chaining, and annotation — that can help you to bend the host language to your DSL. If the host language doesn't require recompilation, an internal DSL can be developed quite quickly working side by side with a domain expert.
-
'''Internal DSLs''' are written in a general purpose programming language whose syntax has been bent to look much more like natural language. This is easier for some languages who have more syntactic sugar (like Ruby or Scala) and much more difficult for others (like Java). Some people even see library APIs as a form of a DSL (but not a very fluent one). Most internal DSLs wrap existing APIs, libraries or business code and provide a wrapper for a less mind bending access to the functionality. They are directly executable by just running them. Depending on the implementation they are used to build data structures, define dependencies, run processes or tasks, communicate with other systems or validate user input. There is a plethora patterns and idioms that helps you to bend your host language. Examples are: expression builder, method chaining, function sequence, object scoping, literal collection. The language can be developed in the constraints of the host language. If the host language doesn't require recompilation, an internal DSL can be developed quite quickly together with a domain expert.
+
:'''External DSLs''' are textual or graphical expressions of the language — although textual DSLs tend to be more common than graphical ones. Textual expressions can be processed by a tool chain that includes lexer, parser, model transformer, generators, and any other type of post-processing. External DSLs are mostly read into internal models which form the basis for further processing. It is helpful to define a grammar (e.g., in EBNF). A grammar provides the starting point for generating parts of the tool chain (e.g., editor, visualizer, parser generator). For simple DSLs, a handmade parser may be sufficient — using, for instance, regular expressions. Custom parsers can become unwieldy if too much is asked of them, so it makes sense to look at tools designed specifically for working with language grammars and DSLs — e.g., openArchitectureWare, ANTlr, SableCC, AndroMDA. Defining external DSLs as XML dialects is also quite common, although readability is often an issue — especially for non-technical readers.
-
'''External DSLs''' are mostly textual expressions of the language, graphical ones are much more difficult to handle (especially in terms of versioning, storing in SCM and editing). The textual expressions are processed by a tool chain that includes lexer, parser, model transformer, generators and any other type of post-processing. External DSLs are mostly read into internal models which form the basis for further processing. For working with external DSLs it has been helpful to define a grammar (e.g. using EBNF) which provides the starting point for generating parts of the tool chain (e.g. editor, visualizer, parser generator). For simple DSLs a hand made parser for instance using regular expressions may be sufficient but most often becomes quickly unwieldy. There are some tools for working with external DSLs - openArchitectureWare, ANTlr, SableCC, AndroMDA. Systems working with XML dialects as external DSLs are also quite common, although they are not easily processable by (nontechnical) people. ANT build scripts are a good example for that.
+
You must always take the target audience of your DSL into account. Are they developers, managers, business customers, or end users? You have to adapt the technical level of the language, the available tools, syntax help (e.g., intellisense), early validation, visualization, and representation to the intended audience. By hiding technical details, DSLs can empower users by giving them the ability to adapt systems to their needs without requiring the help of developers. It also speeds up development because of the potential distribution of work after the initial language framework is in place. The language can be evolved gradually. There are also different migration paths for existing expressions and grammars available.
-
You must always take the target audience of your DSL into account. Are they developers, managers, business customers or end customers? You have to adapt the technicality of the language, the available tools, syntax help (intellisense), early validation, visualization and representation to the intended consumers. Using DSLs can help raising the level of abstraction and thereby hiding technical details behind well known syntax and semantics. It empowers users as it gives them the ability to adapt systems to their needs without requiring the help of developers. It also speeds up development because of the potential distribution of work after the initial language framework is in place. The language can be evolved gradually. There are also different migration paths for existing expressions and grammars available.
+
By [[Michael Hunger]]
-
Further reading:
+
This work is licensed under a [http://creativecommons.org/licenses/by/3.0/us/ Creative Commons Attribution 3]
-
* Martin Fowler, DSL book (work in progress) [http://martinfowler.com/dslwip]
+
-
* Venkat (DSLs in Groovy) [http://www.javaworld.com/javaworld/jw-06-2008/jw-06-dsls-in-java-1.html]
+
-
* Markus Völter (MDD, oAW) [http://www.voelter.de/services/mdsd.html]
+
-
* Thoughtworks DSL podcast [http://feeds.feedburner.com/~r/thoughtworks/IT_Matters/~3/284778933/thoughtworks_001_DSL_01.m4a] [http://feeds.feedburner.com/~r/thoughtworks/IT_Matters/~3/284778936/thoughtworks_003_DSL_02.m4a]
+
-
* MDD, DSL podcasts of Software Engineering radio [http://se-radio.net/tags/dsls]
+
-
--[[User:Michael Hunger|Michael Hunger]] 13:10, 29 January 2009 (PST)
+
Back to [[97 Things Every Programmer Should Know]] home page

Current revision

Whenever you listen to a discussion by experts in any domain, be it chess players, kindergarten teachers, or insurance agents, you'll notice that their vocabulary is quite different from everyday language. That's part of what domain-specific languages (DSLs) are about: a specific domain has a specialized vocabulary to describe the things that are particular to that domain.

In the world of software, DSLs are about executable expressions in a language specific to a domain with limited vocabulary and grammar that is readable, understandable, and — hopefully — writeable by domain experts. DSLs targeted at software developers or scientists have been around for a long time. For example, the Unix little languages found in configuration files and the languages created with the power of LISP macros are some of the older examples.

DSLs are commonly classified as either internal or external:

Internal DSLs are written in a general purpose programming language whose syntax has been bent to look much more like natural language. This is easier for languages that offer more syntactic sugar and formatting possibilities (e.g., Ruby and Scala) than it is for others (e.g., Java) that do not. Most internal DSLs wrap existing APIs, libraries, or business code and provide a wrapper for less-mind bending access to the functionality. They are directly executable by just running them. Depending on the implementation and the domain, they are used to build data structures, define dependencies, run processes or tasks, communicate with other systems, or validate user input. The syntax of an internal DSL is constrained by the host language. There are many patterns — e.g., expression builder, method chaining, and annotation — that can help you to bend the host language to your DSL. If the host language doesn't require recompilation, an internal DSL can be developed quite quickly working side by side with a domain expert.
External DSLs are textual or graphical expressions of the language — although textual DSLs tend to be more common than graphical ones. Textual expressions can be processed by a tool chain that includes lexer, parser, model transformer, generators, and any other type of post-processing. External DSLs are mostly read into internal models which form the basis for further processing. It is helpful to define a grammar (e.g., in EBNF). A grammar provides the starting point for generating parts of the tool chain (e.g., editor, visualizer, parser generator). For simple DSLs, a handmade parser may be sufficient — using, for instance, regular expressions. Custom parsers can become unwieldy if too much is asked of them, so it makes sense to look at tools designed specifically for working with language grammars and DSLs — e.g., openArchitectureWare, ANTlr, SableCC, AndroMDA. Defining external DSLs as XML dialects is also quite common, although readability is often an issue — especially for non-technical readers.

You must always take the target audience of your DSL into account. Are they developers, managers, business customers, or end users? You have to adapt the technical level of the language, the available tools, syntax help (e.g., intellisense), early validation, visualization, and representation to the intended audience. By hiding technical details, DSLs can empower users by giving them the ability to adapt systems to their needs without requiring the help of developers. It also speeds up development because of the potential distribution of work after the initial language framework is in place. The language can be evolved gradually. There are also different migration paths for existing expressions and grammars available.

By Michael Hunger

This work is licensed under a Creative Commons Attribution 3

Back to 97 Things Every Programmer Should Know home page

Personal tools