摘要：随着软件功能不断增加，代码数量也日益膨胀，我们要如何停止不断堆砌，甚至缩小软件体积？本文作者提出了一种可能性：“小语言”。

链接：https://chreke.com/little-languages.html

声明：本文为 CSDN 翻译，未经允许禁止转载。

作者 | Christoffer Ekeroth

译者 | 弯月责编 | 郑丽媛

出品 | CSDN（ID：CSDNnews）

我认为，“小语言”——旨在解决非常具体问题的小语言——是编程的未来，尤其是在阅读了 Gabriella Gonzalez 的文章《编程历史的终结》（The end of history for programming），并观看了 Alan Kay 的演讲《编程与扩展》之后，我更加确定了这个看法。

什么是“小语言”？

“小语言”这个词源自 Jon Bentley 的一篇文章《Little Languages》（小语言），他给出的定义如下：

……小语言指的是专门针对某个特定问题领域的编程语言，不包含传统语言的许多功能。

举个例子，SQL 就是一种描述数据库操作的小语言，正则表达式是一种用于文本匹配的小语言，Dhall 是一种用于配置管理的小语言，等等。

这些语言还有一些其他名称，比如领域特定语言（Domain-specific languages，简称 DSL）、面向问题的语言等等。但是，我最喜欢“小语言”这种叫法，有一部分原因是“DSL”一词包含的含义太多了，包括从具有流式接口的库到成熟的查询语言（如 SQL）。此外，“小语言”这种叫法还强调了这类语言的一个本质：小。

为什么我们需要小语言？

从工程的发展史来看，如今的软件也属于某种工程，但从事这种工程的人并不懂得“拱门”为何物。现在大多数软件与埃及金字塔非常相像，由数百万块砖相互堆叠而成，没有结构完整性，只是靠蛮力和成千上万的奴隶建造的。

—— 艾伦·凯，摘自《与艾伦·凯的对话》

软件工程社区真正遇到的问题是，随着应用程序的复杂性增加，其源代码的规模也会随之增加。然而，我们知道大型代码库的能力在很大程度上仍然是固定的。根据 Sourcegraph 于 2020 年发起的一项调查 The Emergence of Big Code 表明，大多人都表示他们的代码库出现了以下一个或多个问题：

很难添加新员工；
缺乏对依赖关系的理解，导致代码出问题；
代码变更的管理难度越来越大。

更糟糕的是，应用程序正以惊人的速度增长，据 Sourcegraph 调查，大多人认为他们的代码库在过去十年中增长了 100～500 倍。举一个具体的例子，1992 年 Linux 内核刚问世时只有大约 1 万行代码，但在 20 年后的今天已经达到了 3000 万行。

这些代码从何而来？我认为“更多功能”不足以解释这些代码量的增加，相反，我认为这与我们构建软件的方式有关。在程序中添加新功能的常见方法是：在现有功能之上不断堆叠——这不恰恰就是金字塔的搭建方式吗？不同的是，每一层所需要的砖会越来越多。

逆势而上

问题是，我们真的需要数百万行代码来构建现代操作系统吗？2006 年，Alan Kay 与 STEPS 项目的合作者开始挑战这个假设：

科学的进步需要结合实证研究与理论模型，所以作为科学家，我们的首要问题是，如果我们以个人计算现象为基础建立一个模型，是否可以将其提炼为极度简化的东西，就像适用于所有电磁波谱的麦克斯韦方程组，或者是可以浓缩至衬衫口袋大小的美国宪法？还是说这个模型非常混乱（或者极端复杂），就像美国的法律体系（或当前的软件实践）一样“堆积起来有 3 立方英里”那么高的判例法？答案几乎是肯定的：介于两者之间。果真如此的话，能证明这个模型更接近于简化，而不是极端复杂，那一定非常有趣。

所以，我们的问题是：个人计算体验（将操作系统、应用以及其他支持软件的经验都算在内）本质上指的是多少行代码？20 亿行、2 亿行、2 千万行、2 百万行、20 万行、2 万行还是 2 千行？

—— 《STEPS 2007 年进度报告》，第 4～5 页

这里，Kay 提到的麦克斯韦方程组是一组描述电磁学、光学和电路基础的方程式。这些方程式的使用范围非常广，但方程式本身很紧凑，甚至可以印到 T 恤衫上：

这些方程式如此简洁的原因之一是，使用了 Del 符号（∇）来描述向量微积分运算。需要注意的一点是，Del 并不是真正的运算符，它更像是一种简写形式，可以方便我们使用向量微积分中的某些方程。

那么，我们可以创建编程界的 Del 符号吗？就像 Del 可以让向量演算更易于管理一样，我们是否可以找到某种符号，以相同的方式帮助我们理解程序？这个问题正是 STEPS 项目背后的核心思路之一：

此外，我们认为创建面向问题的语言可以降低解决问题的难度，可以使解决方案更易于理解且更小，并且也符合我们“主动数学”方法的精神。这些“面向问题的语言”将被创建并用于大大小小的问题，以及不同层次的抽象和细节。

—— 《STEPS 2007 年进度报告》，第 6 页

这里的基本思路是，在寻找应用程序中的模式时，你可以用一种小语言将它们编码，这种语言将允许你以比其他抽象方法更紧凑的方式来表达这些模式。这样不仅可以逆转应用程序不断增长的趋势，而且还可以让代码库在开发的过程中缩小！

我发现，Nile（https://github.com/damelang/nile）是 STEPS 计划的一大成果，这是一种用于描述图形渲染和合成的小语言，目标是使用 Nile 实现与 Cairo 相同水平的功能。Cairo 是各种免费软件项目都在使用的一种开源渲染器，总代码量约为 44,000 行——而 Nile 只有大约 300 行。

为什么不是高级语言？

尽管如此，事实证明 Ada 并不是干掉软件生产力怪物的灵丹妙药。毕竟，它也只是一种高级语言，这类语言带来的最大收益来自第一次转变，从机器意外的复杂性上升到更抽象的逐步解决方案。在剔除这些意外后，剩下的意外就会变少，而剔除它们的回报自然也会减少。

—— Frederick P. Brooks，《No Silver Bullet》

说到这里，你可能想问：“为什么我们不能发明一种更高级的通用语言呢？”我认为，通用语言的表达能力带给我们的收益已在递减。那么，更高级的语言将是什么样子呢？以 Python 为例，这门语言如此高级，看起来已经很像伪代码了。

通用语言的问题在于，你仍然需要将问题转化为算法，然后再用语言表达算法。如今的高级语言非常擅长描述算法，但除非你的目标是实现算法，否则它也会意外的复杂。

在写这篇文章的时候，我想起了一个关于 Donald Knuth 的故事：有人让 Knuth 在 Jon Bentley 的 Programming Pearls 专栏中展示他的编程风格，而 Doug McIlroy 应邀对 Knuth 的程序发表评论。

Knuth 的任务是计算某一段文本中的词频，其解决方案是用 WEB 语言精心编写的，这门语言是 Pascal 的变体，也是他自己编写的。Knuth 添加了一个专门用于跟踪字数的数据结构，所有代码不到 10 页。虽然 McIlroy 很快就称赞了 Knuth 的解决方案，但他对程序本身并不是很满意。作为评论的一部分，他用 shell 脚本、Unix 命令和小语言编写了自己的解决方案：

tr -cs A-Za-z '\n' |
tr A-Z a-z |
sort |
uniq -c |
sort -rn |
sed ${1}q

对于不熟悉 Unix 的人来说，这段代码不太容易理解——McIlroy 本人也承认这一点，他甚至添加了一个带注释的版本。但很显然，相比十页的程序，这段代码更容易理解。

Unix 命令是为操作文本而设计的，这就是为什么 McIlroy 可以编写出一个如此紧凑的字数统计程序。或许，我们可以将 shell 脚本视为文本操作的“Del 符号”？

少即是多

上述 Unix 命令示例说明了小语言的另一个特征：语言本身不是特别强大，但运行时非常强大。Gonzalez 在文章《编程历史的终结》中提到了如下趋势：

在研究上述趋势时，我们发现了一个共同的模式：将用户关心的某个问题转变成运行时的问题，可以……让使程序更像纯数学表达式，并且……运行时的复杂性明显增加。

正则表达式和 SQL 只能用于表达文本搜索和数据库操作。与之相对的是，C 等没有运行时的语言，你可以表达任何在冯-诺伊曼架构上可能出现的东西。而 Python 和 Haskell 等高级语言介于两者之间：你无需在意内存管理，但仍然可以使用图灵完备语言的全部功能，这意味着你可以表达任何计算。

小语言和 C 语言处于两个极端。对于小语言来说，不仅计算机的体系结构被抽象掉了，其中一些语言可以表达的程序种类也有限制——它们在设计上是不具备图灵完备性的。虽然听上去这些语言非常受限，但实际上它们为优化和静态分析开辟了全新的可能性。而且，就像抽象出内存管理可以消除一大类错误一样，尽可能地抽象出算法也有助于消灭更多的错误。

静态分析

功能不是十分强大的语言更容易推理，而且可以提供比通用语言更强的保证。例如，Dhall 是一种用于生成配置文件的全功能编程语言，如果你不想冒险让部署脚本崩溃或将它们置于无限循环中，则可以考虑 Dhall，因为它可以保证：

1.不崩溃；

2.在有限的时间内结束。

第一点的实现方式是不抛出异常，任何可能失败的操作（例如获取空列表中的第一个元素）都会返回一个可选的结果，其中可能包含值，也可能不包含。第二，为了保证结束，Dhall 不允许程序使用递归定义。在其他函数式编程语言中，递归是表达循环的主要方式，但在 Dhall 中，你必须依赖内置的 fold 函数。缺少通用的循环结构意味着 Dhall 不是图灵完备的语言，但由于它不是一种通用的编程语言，所以也没有这个必要。

如果语言很小，理解起来就更容易。例如，你很难确认 Python 程序是否有副作用，但对于 SQL 来说却很简单，你只需检查查询是否以 SELECT 开头。

对于 Nile，STEPS 团队看到了对图形调试器的需求。Bret Victor 想出了一个工具，可以告诉你在屏幕上绘制特定像素的代码。你可以通过 YouTube 观看 Alan Kay 的演示，也可以自己动手尝试一下。这样的工具是完全可行的，因为 Nile 是一种易于推理的小型语言——想象一下，如果用 C++ 编写同样的一款工具会是什么样子？

对速度的要求

强大的编程语言不仅会增加出现 bug 的可能性，还会对性能产生不利影响。例如，一个程序没有用算法来表达，运行时可以自由选择；我们可以用更快的表达式来替换，当然前提是我们能证明它们能产生相同的结果。

例如，SQL 查询并没有规定应该如何执行查询，数据库引擎可以自由使用它认为最合适的任何查询计划，例如应该使用一个索引、多个索引的组合，还是直接扫描整个数据库表。现代数据库引擎还会收集有关列的值分布的统计信息，这样它们就可以即时选择最优的查询计划。如果查询是通过算法的方式描述的，那就不可能了。

Nile 语言如此紧凑的“秘密武器”之一是 Jitblt，这是一种用于图形渲染的即时编译器。从 STEPS 和 Cairo 团队之间的讨论可以清楚地看出，Cairo 的许多代码都是手动优化像素的合成操作，理论上这部分工作可以交给编译器。因此 Cairo 团队的 Dan Amelang 实现了这样的一个编译器，它就是 Jitblt。这意味着，图形流水线的优化工作可以与渲染内容的纯数学描述分离，这也是 Nile 的运行速度与手动优化过的 Cairo 一样快的原因。

小语言，大潜力

那么，STEPS 项目最后怎么样了？他们最终得到了“堆积起来有 3 立方英里的判例法”，还是设法创建了一个“可以印到 T 恤衫上的操作系统”？他们的最终结果是 KSWorld，这是一个完整的操作系统，包括文档编辑器和电子表格编辑器，大约有 17000 行代码。虽然无法印到 T 恤衫上，但我仍然认为这个项目是成功的。

KSWorld 的创建表明小语言有很大的潜力。然而，我们还有许多问题没有解决，例如这些小语言之间应该如何互通？它们应该编译成一个通用的中间表示吗？或者使用不同的运行时，然后通过通用协议（例如 UNIX 管道或 TCP/IP）相互通信？或者，也许每种语言足够小，可以用各种不同的宿主语言重新实现（如正则表达式）？亦或者，我们可以结合使用这些方式？

无论怎样，我认为我们需要一种不同的方式来构建软件。小语言能否成为这条发展道路上的一部分，也许我们还没有答案，但重要的是我们必须停止不断堆砌砖头，同时还需要想出一种更好的办法。