Collective Wisdom from the Experts 47
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 toolchain that includes lexer, parser, model transformer, gen-
erators, and any other type of post-processing. External DSLs are mostly read
into internal models that 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 toolchain (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
nontechnical 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 abil-
ity to adapt systems to their needs without requiring the help of developers. It
can also speed 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.