Domain-Specific Languages - Revision history

Kevlin at 05:02, 19 July 2009

Kevlin — Sun, 19 Jul 2009 05:02:52 GMT

←Older revision		Revision as of 05:02, 19 July 2009
Line 5:		Line 5:
	DSLs are commonly classified as either ''internal'' or ''external'':		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.	+	:'''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.	+	:'''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.		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.

Kevlin at 04:49, 19 July 2009

Kevlin — Sun, 19 Jul 2009 04:49:06 GMT

←Older revision		Revision as of 04:49, 19 July 2009
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

Kevlin: Domain Specific Languages moved to Domain-Specific Languages

Kevlin — Sun, 19 Jul 2009 04:08:53 GMT

Domain Specific Languages moved to Domain-Specific Languages

←Older revision

Revision as of 04:08, 19 July 2009

Michael Hunger at 21:10, 29 January 2009

Michael Hunger — Thu, 29 Jan 2009 21:10:25 GMT

←Older revision		Revision as of 21:10, 29 January 2009
Line 19:		Line 19:
	* 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]		* 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]		* MDD, DSL podcasts of Software Engineering radio [http://se-radio.net/tags/dsls]
		+
		+	--[[User:Michael Hunger\|Michael Hunger]] 13:10, 29 January 2009 (PST)

Michael Hunger at 21:08, 29 January 2009

Michael Hunger — Thu, 29 Jan 2009 21:08:44 GMT

←Older revision		Revision as of 21:08, 29 January 2009
Line 14:		Line 14:

	Further reading:		Further reading:
-	* Martin Fowler, DSL book (work in progress) [martinfowler.com/dslwip]	+	* 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]		* 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]		* 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]		* 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]		* MDD, DSL podcasts of Software Engineering radio [http://se-radio.net/tags/dsls]

Michael Hunger: New page: 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...

Michael Hunger — Thu, 29 Jan 2009 21:08:24 GMT

New page: 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...

New page

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.

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.

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.

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 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 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 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.

Further reading:
* Martin Fowler, DSL book (work in progress) [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]