Domain-Specific Languages
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 — writable 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 that do not (e.g., Java). 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 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.
By Michael Hunger
领域特定语言
每当你听任何领域的专家的讨论，无论是棋手、幼儿园老师还是保险代理人，你都会注意到他们的词汇与日常语言截然不同。这就是领域特定语言（DSL）的一部分：一个特定的领域有一个专门的词汇表来描述该领域特有的东西。在软件世界中，DSL是指特定于词汇和语法有限的领域的语言中的可执行表达式，该语言可由领域专家阅读、理解，并有望写入。针对软件开发人员或科学家的DSL已经存在很长时间了。例如，配置文件中的Unix“小语言”和使用LISP宏创建的语言是一些较老的例子。DSL通常分为内部或外部：内部DSL是用一种通用编程语言编写的，其语法已经被弯曲，看起来更像自然语言。这对于提供更多语法糖和格式化可能性的语言（例如Ruby和Scala）来说比其他不提供语法糖和格式可能性的语言更容易（例如Java）。大多数内部DSL封装现有的API、库或业务代码，并提供一个封装器来减少对功能的访问。只要运行它们，它们就可以直接执行。根据实现和域的不同，它们用于构建数据结构、定义依赖关系、运行流程或任务、与其他系统通信或验证用户输入。内部DSL的语法受到主机语言的限制。有许多模式——例如，表达式构建器、方法链接和注释——可以帮助您使宿主语言适应DSL。如果宿主语言不需要重新编译，那么可以很快地与领域专家一起开发内部DSL。外部DSL是语言的文本或图形表达——尽管文本DSL往往比图形DSL更常见。文本表达式可以由一个工具链处理，该工具链包括lexer、解析器、模型转换器、生成器和任何其他类型的后处理。外部DSL大多被读入内部模型，这些模型构成了进一步处理的基础。定义语法是有帮助的（例如，在EBNF中）。语法为生成工具链的各个部分（例如编辑器、可视化工具、解析器生成器）提供了起点。对于简单的DSL，手工解析器可能就足够了——例如，使用正则表达式。如果对自定义解析器的要求太高，它们可能会变得很难使用，因此查看专门为处理语言语法和DSL而设计的工具是有意义的，例如openArchitectureWare、ANTlr、SableCC、AndroMDA。将外部DSL定义为XML方言也是很常见的，尽管可读性通常是一个问题，尤其是对于非技术读者来说。您必须始终考虑DSL的目标受众。他们是开发人员、经理、业务客户还是最终用户？您必须调整语言的技术水平、可用的工具、语法帮助（例如intellisense）、早期验证、可视化和表示以适应预期受众。通过隐藏技术细节，DSL可以让用户在不需要开发人员帮助的情况下根据自己的需求调整系统，从而增强用户的能力。它还可以加快开发，因为在初始语言框架到位后，工作可能会分布。这种语言可以逐渐演变。现有的表达式和语法也有不同的迁移路径。作者：Michael Hunger
