语言工作台：领域特定语言的杀手级应用？

面向语言编程的简单示例

我将首先通过一个非常简单的面向语言编程示例以及导致它的情况来开始。假设我们有一个读取文件的系统，需要根据这些文件创建对象。文件格式是每行一个对象。每行可以映射到一个不同的类，该类由行首的四个字符代码表示。该行的其余部分包含类的字段的数据，这些数据根据我们讨论的是哪个类而有所不同。字段由位置而不是分隔符指示。因此，客户 ID 号码可能从字符 4-8 开始。

以下是一些示例数据

#123456789012345678901234567890123456789012345678901234567890
SVCLFOWLER         10101MS0120050313.........................
SVCLHOHPE          10201DX0320050315........................
SVCLTWO           x10301MRP220050329..............................
USGE10301TWO          x50214..7050329...............................

点表示一些难以理解的、不感兴趣的数据。顶部的注释行是为了帮助你查看字符位置。前四个字符表示数据的类型 - SVCL 表示服务调用，USGE 表示使用记录。后面的字符表示对象的数据。因此，服务调用中从位置 5 到 18 的字符表示客户的姓名。

为了将它们转换为对象，你可能会试图为每种情况编写特定的代码，我希望在编写了一些代码之后，你会希望通过编写一个可以使用每个类的字段详细信息进行参数化的单个读取器类来简化任务。

这里我有一个简单的类来做到这一点。读取器类读取文件。读取器可以使用读取器策略类的集合进行参数化 - 每个目标类一个。因此，对于我们的示例，我们将有一个用于服务调用的策略，另一个用于使用情况。我将策略保存在一个以代码为键的映射中。

以下是处理文件的代码

class Reader...

  public IList Process(StreamReader input) {
    IList result = new ArrayList();
    string line;
    while ((line = input.ReadLine()) != null)
      ProcessLine(line, result);
    return result;
  }

  private void ProcessLine(string line, IList result) {
    if (isBlank(line)) return;
    if (isComment(line)) return;
    string typeCode = GetTypeCode(line);
    IReaderStrategy strategy = (IReaderStrategy)_strategies[typeCode];
    if (null == strategy) 
      throw new Exception("Unable to find strategy");
    result.Add(strategy.Process(line));
  }
  private static bool isComment(string line) {
    return line[0] == '#';
  }
  private static bool isBlank(string line) {
    return line == "";
  }
  private string GetTypeCode(string line) {
    return line.Substring(0,4);
  }
  IDictionary _strategies = new Hashtable();
  public void AddStrategy(IReaderStrategy arg) {
    _strategies[arg.Code] = arg;
  }

它只是循环遍历每一行，读取足够的信息以确定要调用哪个策略，然后将其交给策略来完成工作。要让读取器完成这项工作，你需要创建一个新的读取器，为其加载策略，然后让它处理你想要处理的文件。

策略也可以是可参数化的。我们只需要一个策略类，当我们实例化它时，我们可以使用代码、目标类以及输入上的哪些字符位置映射到目标类上的哪些字段的详细信息对其进行参数化。我将后者保存在一个字段提取器类列表中。

class ReaderStrategy...

  private string _code;
  private Type _target;
  private IList extractors = new ArrayList();
  public ReaderStrategy(string code, Type target) {
    _code = code;
    this._target = target;
  }
  public string Code {
    get { return _code; }
  }

实例化策略后，我可以向其中添加字段提取器。

class ReaderStrategy...

  public void AddFieldExtractor(int begin, int end, string target) {
    if (!targetPropertyNames().Contains(target)) 
      throw new NoFieldInTargetException(target, _target.FullName);
    extractors.Add(new FieldExtractor(begin, end, target));
  }
  private IList targetPropertyNames() {
    IList result = new ArrayList();
    foreach (PropertyInfo p in _target.GetProperties())
      result.Add(p.Name);
    return result;
  }

为了处理该行，策略创建目标类并使用提取器获取字段数据

class ReaderStrategy...

  public object Process(string line) {
    object result = Activator.CreateInstance(_target);
    foreach (FieldExtractor ex in extractors)
      ex.extractField(line, result);
    return result;
  }

提取器只是从该行的正确位置提取数据，并使用反射将值放入目标对象中。

class FieldExtractor...

  private int _begin, _end;
  private string _targetPropertyName;
  public FieldExtractor(int begin, int end, string target) {
    _begin = begin;
    _end = end;
    _targetPropertyName = target;
  }
  public void extractField(string line, object targetObject) {
    string value = line.Substring(_begin, _end - _begin + 1);
    setValue(targetObject, value);
  }
  private void setValue(object targetObject, string value) {
    PropertyInfo prop = targetObject.GetType().GetProperty(_targetPropertyName);
    prop.SetValue(targetObject, value, null);
  }

到目前为止，我所描述的是一个非常简单的库，用于完成这类事情。本质上，我已经构建了一个抽象，然后我可以使用它来指定具体的工作。为了使用抽象，我需要配置策略并将它们加载到读取器中。以下是两个示例用例的示例。

public void Configure(Reader target) {
  target.AddStrategy(ConfigureServiceCall());
  target.AddStrategy(ConfigureUsage());
}
private ReaderStrategy ConfigureServiceCall() {
  ReaderStrategy result = new ReaderStrategy("SVCL", typeof (ServiceCall));
  result.AddFieldExtractor(4, 18, "CustomerName");
  result.AddFieldExtractor(19, 23, "CustomerID");
  result.AddFieldExtractor(24, 27, "CallTypeCode");
  result.AddFieldExtractor(28, 35, "DateOfCallString");
  return result;
}
private ReaderStrategy ConfigureUsage() {
  ReaderStrategy result = new ReaderStrategy("USGE", typeof (Usage));
  result.AddFieldExtractor(4, 8, "CustomerID");
  result.AddFieldExtractor(9, 22, "CustomerName");
  result.AddFieldExtractor(30, 30, "Cycle");
  result.AddFieldExtractor(31, 36, "ReadDate");
  return result;
}

我认为这是两种不同的代码风格。Reader 和 Strategy 类是一个抽象，最后这段代码是配置。当你构建这类库类时，考虑这两个部分通常会有所帮助：抽象和配置。抽象可以是一个类库、一个框架，或者只是一组函数调用。抽象可以在许多项目中重用，但它不一定是可重用的。配置代码往往是特定于项目的；相当简单、直接的代码。

由于配置非常简单，并且比抽象更容易更改，因此一种常见的方法是进一步分离它，并将配置完全从 C# 中移除。目前的做法是将其放在 XML 文件中。

<ReaderConfiguration>
  <Mapping Code = "SVCL" TargetClass = "dsl.ServiceCall">
    <Field name = "CustomerName" start = "4" end = "18"/>
    <Field name = "CustomerID" start = "19" end = "23"/>
    <Field name = "CallTypeCode" start = "24" end = "27"/>
    <Field name = "DateOfCallString" start = "28" end = "35"/>
  </Mapping>
  <Mapping Code = "USGE" TargetClass = "dsl.Usage">
    <Field name = "CustomerID" start = "4" end = "8"/>
    <Field name = "CustomerName" start = "9" end = "22"/>
    <Field name = "Cycle" start = "30" end = "30"/>
    <Field name = "ReadDate" start = "31" end = "36"/>
  </Mapping>
</ReaderConfiguration>

XML 有其用途，但并不容易阅读。我们可以通过使用自定义语法使其更容易理解。也许像这样

mapping SVCL dsl.ServiceCall
  4-18: CustomerName
  19-23: CustomerID
  24-27 : CallTypeCode
  28-35 : DateOfCallString

mapping  USGE dsl.Usage
  4-8 : CustomerID
  9-22: CustomerName
  30-30: Cycle
  31-36: ReadDate
  

由于你现在已经熟悉了这个问题，所以你应该能够在没有我帮助的情况下阅读语法。

当你查看最后一个示例时，你可以看到我们这里有一个非常小的编程语言 - 它（只）适用于将固定长度字段映射到类。它是 Unix 传统中“小型语言”的典型例子。它是用于该任务的领域特定语言。

这种语言是一种领域特定语言，并且具有 DSL 的许多特征。首先，它只适用于非常狭窄的用途 - 它除了将这些特定的固定长度记录映射到类之外，什么也做不了。因此，DSL 非常简单 - 没有控制结构或其他任何东西的工具。它甚至不是图灵完备的。你不能用这种语言编写整个应用程序 - 你所能做的只是描述应用程序的一小部分。因此，DSL 必须与其他语言结合使用才能完成任何事情。但 DSL 的简单性意味着它易于编辑和翻译。（我将在稍后详细介绍 DSL 的优缺点。）

现在再看看 XML 表示。这是一种 DSL 吗？我认为它是。它采用 XML 语法 - 但它仍然是一种 DSL - 事实上，在许多方面它与前面的示例是相同的 DSL。

现在是介绍编程语言领域中常见区别的好时机 - 抽象语法和具体语法的区别。语言的**具体语法**是我们在其表示中看到的语法。XML 和自定义语言文件具有不同的具体语法。然而，两者都具有相同的基本结构：你有多个映射，每个映射都有一个代码、一个目标类名和一组字段。这种基本结构是**抽象语法**。当大多数开发人员考虑编程语言语法时，他们不会做出这种区分，但当你使用 DSL 时，这是一个重要的区分。你可以从两个方面来理解这一点。你可以说我们有一种语言有两种具体语法，或者说两种语言共享相同的抽象语法。

因此，这个例子提出了一个设计问题 - 为 DSL 使用自定义具体语法还是 XML 具体语法更好。XML 语法可能更容易解析，因为有这么多可用的 XML 工具；尽管在这种情况下，自定义语法实际上更容易。我认为自定义语法更容易阅读，至少在这种情况下是这样。但无论你如何看待这种选择，围绕 DSL 的核心权衡都是一样的。事实上，你可以说任何 XML 配置文件本质上都是 DSL。

让我们再往前走一步，回到 C# 中的配置代码 - 这是一种 DSL 吗？

当你想到这一点时，请看这段代码。这看起来像解决这个问题的 DSL 吗？

mapping('SVCL', ServiceCall) do
	extract 4..18, 'customer_name'
	extract 19..23, 'customer_ID'
	extract 24..27, 'call_type_code'
	extract 28..35, 'date_of_call_string'
end
mapping('USGE', Usage) do
	extract 9..22, 'customer_name'
	extract 4..8, 'customer_ID'
	extract 30..30, 'cycle'
	extract 31..36, 'read_date'
end

第二段代码与 C# 代码相关。熟悉我语言偏好的人可能已经猜到，最后一个例子实际上是 Ruby 代码。事实上，它与 C# 示例在功能上完全等效。由于 Ruby 的各种特性：最小侵入式语法、范围字面量和灵活的运行时求值，它看起来更像是一种自定义 DSL。这是一个完整的配置文件，可以在运行时读取并在对象实例的范围内进行求值。但它仍然是纯粹的 Ruby 代码，并通过方法调用 mapping 和 extract 与框架代码交互，这两个方法分别对应于 C# 示例中的 AddStrategy 和 AddFieldExtractor。

我认为 C# 和 Ruby 示例都是 DSL。在这两种情况下，我们都使用了宿主语言的一部分功能，并使用我们的 XML 和自定义语法来表达相同的思想。本质上，我们是将 DSL 嵌入到我们的宿主语言中，使用宿主语言的一个子集作为我们抽象语言的自定义语法。在某种程度上，这更多的是一种态度问题，而不是其他任何问题。我选择从面向语言编程的角度来看待 C# 和 Ruby 代码。但这种观点由来已久——Lisp 程序员经常考虑在 Lisp 中创建 DSL。这些内部 DSL 的权衡显然不同于外部 DSL，但仍有许多相似之处。（稍后我也会详细说明这些权衡）。

现在我已经展示了一个 DSL 的例子，我可以更好地定义面向语言编程。面向语言编程是关于通过多个 DSL 来描述一个系统。它是一个渐进的过程，你可以在一个系统中使用少量的面向语言编程，其中只有一部分功能是用 DSL 表示的；或者你也可以用 DSL 表示大部分功能，并大量使用面向语言编程。你使用了多少面向语言编程是很难衡量的，特别是当你使用语言内部的 DSL 时。通常，就像任何可重用代码一样，你自己编写一些 DSL，并使用来自其他地方的其他 DSL。

面向语言编程的传统

正如我的例子所示，面向语言编程并不是什么新鲜事——人们已经进行面向语言编程相当长一段时间了。因此，在我们关注语言工作台为我们带来了什么之前，有必要先了解一下面向语言编程的现状。

目前，面向语言编程的风格有很多种。现在是总结其中几种风格的好时机。

面向语言编程的优缺点

回顾这些风格，我们可以看到各种形式的面向语言编程都非常流行。概括地说，我发现将它们分为两种更广泛的风格是很有用的。**外部 DSL** 使用与应用程序主要（宿主）语言不同的语言编写，并使用某种形式的编译器或解释器转换为宿主语言。Unix 小型语言、活动数据模型和 XML 配置文件都属于这一类。**内部 DSL** 将宿主语言本身转换为 DSL——Lisp 传统就是这方面的最佳例子。

我在本文中创造了“外部/内部”这两个术语，因为对于我认为有用的区别，目前还没有一对明确的术语。内部 DSL 通常被称为“嵌入式 DSL”，但我避免使用“嵌入式”一词，因为它与应用程序中的嵌入式语言（例如嵌入到 Word 中的 VBA，如果说它是什么的话，它就是一个外部 DSL）相混淆。然而，如果你查阅更多关于 DSL 的文章，你可能会遇到“嵌入式”一词。

外部 DSL 和内部 DSL 的权衡相当不同，因此最好分别进行 بررسی。

今天的语言工作台

我将首先简要介绍一些我遇到过的属于语言工作台类别的工具。请记住，所有这些工具都处于开发的早期阶段。我们还需要几年的时间才能看到可用于大规模软件开发的语言工作台。

语言工作台的要素

尽管这些工具各不相同，但它们确实有一些共同的特征和相似的部分。

语言工作台最强大的优势之一是，它们改变了编辑和编译程序之间的关系。从本质上讲，它们从编辑文本文件转变为编辑程序的抽象表示。让我用几段话来解释最后一句话。

在传统编程中，我们使用文本编辑器编辑文本文件中的程序文本。然后，我们通过运行将这些文本文件转换为计算机可以理解和执行的内容的转换器，使该文件可执行。这种转换可以在执行时进行，例如 Python 或 Ruby 等脚本语言，也可以作为编译语言（例如 Java、C# 和 C）的单独步骤进行。

图 1：传统编译的概要。

让我把这个过程分解一下。图 1显示了编译过程的简化视图。为了将 foo.cs 转换为可执行文件，我们在其上运行编译器。为了便于讨论，我们可以将编译过程分为两个步骤。第一步从文件 foo.cs 中获取文本并将其解析为抽象语法树 (AST)。第二步遍历此树，生成 CLR 字节码并将其放入程序集（exe 文件）中。

我们可以将程序视为具有多种表示形式，编译器在这些表示形式之间进行转换。源文件是可编辑表示形式，也就是说，这是我们想要更改程序时操作的表示形式。它也是存储表示形式，即保存在源代码管理中的表示形式，如果我们想再次访问程序，可以使用它。当我们运行编译器时，第一阶段将可编辑表示形式映射到抽象表示形式（抽象语法树），然后代码生成器将其转换为可执行表示形式（CLR 字节码）。

（在可执行代码真正成为最终可执行文件之前，还有更多的转换。但是，一旦我们有了字节码，编译器的工作就完成了，剩下的所有内容都留给其范围之外的后续阶段。）

抽象表示形式非常短暂——它只在编译器运行时存在，并且仅用于将编译分为两个逻辑步骤。当然，这种短暂性也是外部 DSL 之间难以实现符号集成的很大一部分原因。每种语言都经过单独的编译，因此抽象表示形式之间没有链接。只有在生成代码时，事物才会结合在一起，此时关键的抽象就会丢失。

更复杂的 IntelliJ 后 IDE 为此模型带来了重大变化。当 IDE 加载文件时，它会在内存中创建一个抽象表示形式，用于帮助您编辑文件。（Smalltalk 也做了一个有限的版本。）这种抽象表示形式有助于完成简单的事情，例如方法名称完成，以及复杂的事情，例如重构（自动重构是对抽象表示形式的转换）。

我的同事 Matt Foemmel 描述了有一次他在 IntelliJ 中工作时，这种情况是如何让他印象深刻的。他做了一个由这些功能大力协助的更改，突然意识到他不是在键入文本，而是在对抽象表示形式运行命令。尽管 IDE 将抽象表示形式中的这些更改转换回了文本，但他真正操作的是抽象表示形式。如果您在使用现代 IDE 时也有类似的感觉，那么您就会明白语言工作台的作用。

图 2：使用语言工作台操作表示形式。

图 2显示了此过程如何与语言工作台一起工作。这里的关键区别在于“源”不再是可编辑的文本文件。您操作的关键源是抽象表示形式本身。为了对其进行编辑，语言工作台将抽象表示形式投影到某种形式的可编辑表示形式中。但是，这种可编辑的表示形式纯粹是短暂的——它只是为了帮助人类。真正的来源是持久的抽象表示形式。

可编辑表示形式仅仅是抽象表示形式的投影这一事实引出了几点。也许最重要的是，可编辑表示形式不需要完整——如果抽象表示形式的某些方面对当前任务不重要，则可以省略它们。此外，您可以拥有多个投影，每个投影都显示抽象表示形式的不同方面。由于投影位于语言工作台中，因此可编辑表示形式比文本文件更加活跃。这种**投影编辑器**与语言本身紧密相连。因此，在考虑可编辑表示形式时，您会积极地考虑编辑器如何处理它们。这会导致与您从纯被动可编辑表示形式（例如文本）获得的想法不同。

语言工作台将存储表示形式与可编辑表示形式分开。存储表示形式现在是抽象表示形式的序列化。一种常见的方法是使用 XML，但这种 XML 不是为人工编辑而设计的。将 XML 作为存储表示形式有助于工具互操作性，尽管这种互操作性可能非常困难。

代码生成几乎相同，尽管此类工具可能会将传统源代码视为可执行表示形式。如果它们确实生成了常规语言源文件，则这些文件实际上并不是源文件，并且像其他生成的代码一样，不应直接编辑。随着语言工作台的成熟，我们应该会看到更多地依赖于生成不可编辑的结构，例如字节码。

语言工作台的一个不明显但很重要的特性是，抽象表示形式必须能够容忍错误和歧义。传统上，人们认为，如果您要使用抽象表示形式，则需要保持其正确性——您不应该能够在其中放入不正确的信息。然而，这种假设导致了糟糕的可用性。IntelliJ 后的 IDE 意识到了这一点，并对错误状态做出了优雅的反应。例如，您可以对具有编译错误的程序执行重构（这对良好的可用性非常必要）。

如果您想从多个来源捕获复杂信息，这一点就变得更加重要。您不可能始终保持所有内容的一致性和正确性。因此，您必须处理模糊和错误的状态——突出显示错误而不是拒绝输入。您还应该允许人们轻松地将不可计算的信息（例如文档）输入到模型中。这样，扫描的餐巾纸就可以直接链接到生成的 DSL 代码。

定义语言工作台

目前还没有普遍接受的定义来界定什么是语言工作台。这并不奇怪，因为这个词是我在这篇文章中刚刚创造出来的！但我认为，为了避免软件行业中许多主题（例如组件、面向服务的体系结构）普遍存在的歧义，我应该尝试对语言工作台的基本特征进行初步的定义，我现在可以简要地做到这一点，因为我已经提供了必要的背景。

• 用户可以自由定义彼此完全集成的新语言。
• 主要信息来源是持久的抽象表示形式。
• 语言设计者通过三个主要部分定义 DSL：模式、编辑器和生成器。
• 语言用户通过投影编辑器来操作 DSL。
• 语言工作台可以在其抽象表示形式中保留不完整或矛盾的信息。

语言工作台如何改变面向语言编程的权衡。

不久前，我讨论了面向语言编程的权衡。语言工作台显然会影响这种权衡，并带来许多需要考虑的新事物。

语言工作台对等式做出的最明显改变是创建外部 DSL 的容易程度。您不再需要编写解析器。您确实需要定义抽象语法，但这实际上是一个非常简单的数据库建模步骤。此外，您的 DSL 还获得了一个强大的 IDE，尽管您确实需要花一些时间来定义该编辑器。生成器仍然是您必须做的事情，我的感觉是它并不比以往更容易。但是，为一个优秀而简单的 DSL 构建生成器是这项工作中最简单的部分之一。

语言工作台的第二个优点是您可以获得符号集成。能够使用类似 Excel 的公式语言，并将其插入到您自己的专用语言中，这是非常棒的。同样，能够在一个语言中更改符号，并让这些更改在整个系统中传播，这也是使用语言工作台时可以考虑的一个合理的事情（我不确定它们中是否已经有哪个可以做到这一点）。

重构这个问题是语言工作台中的一大问题。当我解释如何使用语言工作台时，很容易落入将其描述为“首先定义 DSL，然后使用它构建东西”的陷阱。如果您阅读过我过去写过的很多东西，那么这个概念应该会敲响许多警钟。我非常提倡演进式设计——在这个语境下，这意味着您需要能够同时演进 DSL 和用 DSL 构建的任何代码。这是一个难题，但在 Intentional 的早期开发中就已得到承认。现在就断言在成熟的语言工作台中，与 DSL 的使用同时演进 DSL 会有多成功还为时过早——但缺乏这种能力将是它们的一大缺陷。

我认为语言工作台中期面临的最大问题是供应商锁定的风险。目前还没有定义模式、编辑器和生成器三者的标准。一旦您在语言工作台中定义了一种语言，您就被绑定到该语言工作台。不同的语言工作台之间没有交换的标准——如果您想更换语言工作台，这将导致您不得不重新实现这三者。随着时间的推移，我们可能会看到某种专门用于交换 DSL 的特殊存储表示——一种交换表示。但是，除非在这方面出现一个可靠的解决方案，否则供应商锁定仍然是一个很大的风险。（MDA 声称可以解决这个问题，但它充其量只是部分解决方案。）

对此的一种缓解措施是，将语言工作台视为帮助您生成源代码的工具。例如，可以使用语言工作台来控制所有 Java XML 配置文件。如果最坏的情况发生，您不得不放弃语言工作台，那么您仍然拥有生成的配置文件。只要您注意生成的代码是否清晰易懂，您甚至可能不会比自己编写更糟糕。即使对于更深层次的功能，您仍然可以生成结构良好的 Java 代码。这在一定程度上降低了风险，至少您不会完全陷入困境。但是，供应商锁定仍然是需要考虑的问题。

关于工具的这个问题是放弃文本文件作为源代码的后果之一。其他问题也随之而来——我们已经设法用文本解决了这些问题，但现在必须重新思考抽象表示的中心作用。在我的清单上，最重要的是版本控制。我们知道如何对文本源代码进行有效的版本控制，并具有良好的差异和合并功能。为了提高效率，语言工作台需要能够提供抽象表示本身的差异和合并功能。从理论上讲，这应该是可以解决的，并且可以实现真正的语义差异（其中重命名符号被理解为该行为，而不仅仅是像使用文本那样从其结果中推断出的东西）。Intentional 似乎在这方面有一个很好的解决方案，但我们还没有在实践中尝试过。

回到积极的一面，自定义语言和编辑器的结合可能最终为非程序员编辑 DSL 铺平了道路。此外，符号集成消除了用户代码和核心程序不同步的问题。编辑器的使用可能是帮助打破 COBOL 推论的最大工具——提供为用户交互定制工具的环境。

这种让领域专家更直接地参与开发工作的承诺，也许是语言工作台承诺中最诱人的部分。我们一次又一次地看到，无论我们程序员使用什么工具来提高生产力，都有一种感觉，我们正在优化空闲循环。在我访问的大多数项目中，最大的问题是开发人员和业务人员之间的沟通。如果这方面进展顺利，那么即使使用二流的技术，您也可以取得进展。如果这种关系破裂，那么即使是 Smalltalk 也救不了你。

大多数面向语言编程的支持者都在谈论更多地让领域专家参与进来。事实上，我甚至听说过秘书们愉快地用 Lisp 的内部 DSL 编程的例子。然而，大多数情况下，这些努力都没有真正取得成功。通过将专注的外部 DSL 与复杂的编辑器和开发环境相结合，也许我们最终可以开始解决这个问题。如果真是这样，那么好处将是巨大的。事实上，令人惊讶的是，这种用户参与似乎是 Charles Simonyi 工作背后的主要驱动力，支撑着 Intentional Software 中的大多数决策。

这些工具短期内最大的限制是成熟度。这些工具要达到甚至领先的开发人员水平还需要一段时间。但正如我们所知，这种情况可能会迅速改变——想想十年前与现在的工具和语言选择相比就知道了。

改变我们对 DSL 的理解

我在本文中使用的例子实际上是 DSL 中相当无趣的例子。我使用它们是因为它们易于讨论和构建。但即使是更复杂的协议 DSL 也相当传统——很容易看出它如何可以作为传统的文本 DSL 来完成。许多人希望生成图形化的 DSL，但即使是这些 DSL 也不能完全发挥其潜力。使用“语言”一词的最大危险在于，它可能会导致人们忽略语言工作台真正能做的事情。

当我与我的同事们谈论 OOPSLA 2004 时，最热门的话题是 Jonathon Edwards 关于以示例为中心的编程的一些演示。其关键思想是一个编辑器，它不仅显示程序代码，还显示该代码中示例执行的结果。这个想法是，虽然我们操纵的是抽象，但我们经常发现用具体案例来思考更容易。这种对示例的倾向是以测试驱动开发的吸引力很大一部分——我认为它是以示例说明。

Edwards 将他的想法进一步发展成一个名为Subtext的工具。Subtext 与语言工作台有一些共同的原则——特别是放弃文本源代码的想法。虽然 subtext 在支持轻松定义新语言方面不那么有趣，但它提供了一个有趣的视角，让我们了解随着语言工作台让我们深入思考语言和工具的紧密联系，可能会发展出什么样的想法。

事实上，这可能是语言工作台能够避免 COBOL 推论的不利影响的最强有力的理由。正如我之前所说，我们不断地提出技术来赋予用户作为非专业程序员的能力，但却经常失败。让我们考虑一项真正成功地使非专业程序员变得高效的技术——电子表格。

大多数程序员并不认为电子表格是一种编程环境。然而，许多非专业程序员使用它们创建了复杂的系统。电子表格是一个迷人的编程环境，它暗示了非专业编程工具可能需要的特性

• 即时反馈——包括立即显示示例计算的结果。
• 工具和语言的深度集成
• 没有文本源代码
• 不需要始终显示所有信息——公式仅在您编辑包含它们的单元格时可见，否则将显示值。

电子表格也非常令人沮丧。它们缺乏结构鼓励实验，但我经常觉得稍微多一点结构可以让某些问题更容易处理。

因此，当我们考虑语言工作台中的 DSL 时，我们不应该再局限于我在这里展示的那些语言——或者建模者所钟爱的图形语言。相反，我们应该考虑下一代电子表格之类的东西。

结论

我写这篇文章的主要目的是向您介绍语言工作台。至少我希望您现在已经了解了足够多的知识，以便在您的经理要求您用它们替换整个编程环境时，能够应对自如。

在我看来，语言工作台提供了两个主要优势。一是通过为程序员提供更好的工具来提高他们的生产力。另一个是通过让领域专家有更多机会直接贡献于开发基础，从而加强与领域专家的关系，从而提高开发效率。只有时间才能证明这些优势是否能够真正实现。看看这两点，我会说提高生产力更有可能实现，但影响较小。如果语言工作台对开发和领域专家之间的关系产生了重大影响，那么它可能会产生巨大的影响——但它必须克服 COBOL 推论才能取得成功。

也许我意识到最有趣的事情是，一旦我们有了使用语言工作台的经验，我们可能就不知道 DSL 会是什么样子了。到目前为止，我的想法仍然很大程度上局限于对文本和图形语言的思考。然而，编辑器和模式的相互作用开辟了与大多数人对外部 DSL 的想法截然不同的可能性。如果语言工作台不负众望，那么十年后，我们会回顾过去，嘲笑我们现在对 DSL 应该是什么样子的想法。

正如我所指出的，语言工作台仍处于非常早期的开发阶段。要认真评估它们还需要几年的时间。我不打算预测它们是否会像它们的倡导者所希望的那样改变软件开发的面貌。我不是一个技术未来学家。但我相信，语言工作台是我们视野边缘最有趣的想法之一。如果它们真的发挥了潜力，它们肯定会对我们的行业产生巨大的影响。即使没有，我怀疑它们也会带来很多有趣的想法。

所以我建议你密切关注这个领域。这是一个有趣的领域，而且有足够的生命力在未来许多年里保持有趣。我很幸运，在最近几个月里对它有了一个很好的了解，我打算在未来一段时间内继续保持对它的兴趣。