领域特定语言指南

在00年代的最后几年里，我对dsl的复兴产生了浓厚的兴趣，这是由Ruby社区的努力、创建流畅接口的愿望以及语言工作台的诱人(虽然模糊)前景所推动的。我看到一些项目使用了来自领域特定语言的想法，但大多数人对构建和使用它们的选择没有很好的感觉。因此，我决定通过编写一本用于简单的内部和外部文本dsl的模式书来解决这个问题。虽然这种兴趣在其间的几年里已经减弱了，但我仍然觉得这本书很好地掌握了这些技巧。特别是，它介绍了如何使用自适应模型来捕获可选计算模型，如规则引擎、决策表和状态机。

我被要求对非技术类型的dsl进行讨论。也许我读得太多了Stephen O’grady但我有一种不可抗拒的冲动，想用问答的方式来回答。它来了。

当话题DomainSpecificLanguage最常见的问题之一就是到底什么是DSL，什么不是DSL。问题是DSL没有精确的定义，而且DSL和其他东西之间有很大的灰色地带。

软件开发中的大多数新思想实际上是旧思华体会登录网址想的新变体。本文描述了其中之一，我称之为语言工作台的一类工具的不断发展的想法——其中的例子包括意图软件、JetBrains的元编程系统和微软的软件工厂。这些工具采用了一种旧的开发风格——我称之为面向语言的编程，并使用IDE工具使面向语言的编程成为一种可行的方法。尽管我不能预测他们是否会成功，但我确实认为这些工具是软件开发领域中最有趣的东西。华体会登录网址有趣的是，我写这篇文章来尝试解释(至少是概述)它们是如何工作的，以及围绕它们未来用途的主要问题。

我们的大多数软件逻辑都是用编程语言编写的，这为我们提供了编写和发展这种逻辑的最佳环境。但是在某些情况下，将逻辑转移到命令式代码可以解释的数据结构中是有用的——我将其称为自适应模型。在这里，我将展示一些用JavaScript编写的产品选择逻辑，并展示如何将其重构为用JSON编码的简单生产规则系统。这个JSON数据允许我们在使用不同编程语言的设备之间共享这个选择逻辑，并在不更新这些设备上的代码的情况下更新这个逻辑。

dsl允许业务人员在不涉及程序员的情况下编写软件规则吗?

当人们谈论dsl时，通常会提出业务人员为自己编写代码的问题。我喜欢将COBOL推理应用到这一思路中。那就是COBOL最初的目标之一是允许人们在没有程序员的情况下编写软件，我们知道这是如何实现的。因此，当任何计划在没有程序员的情况下编写代码时，我必须问一下，在COBOL(和许多其他东西)失败的情况下，这次有什么特别之处可以使它成功。

这是一个经常被提及的短语DomainSpecificLanguages(或实际上任何计算机语言)是嘈杂的语法。人们可能会说Ruby比Java更安静，或者外部领域特定语言比内部领域特定语言更安静。所谓“句法噪声”，人们指的是无关紧要的字符，这些字符不是我们真正需要表达的内容的一部分，而是为了满足语言定义而存在的。噪声字符很糟糕，因为它们模糊了程序的含义，迫使我们弄清楚它在做什么。

我关于领域特定语言的书使用了一种模式结构来组织我用来描述领域特定语言的概念。这个目录是那本书中模式的列表。每个链接都链接到每个模式的页面。虽然这些页面不包含太多细节，但它们确实为每个模式提供了一个参考URI。