产品沉思录 产品沉思录 产品沉思录 产品沉思录
小语言是编程的未来

小语言是编程的未来

小语言是为解决特定问题而设计的编程语言，如SQL和正则表达式。随着软件复杂性的增加，传统大型代码库难以管理，而小语言可以通过简化表达和提高可理解性来应对这一挑战。小语言的功能较弱但更易推理，能够减少错误并提升性能。STEPS项目展示了小语言的潜力，未来可能需要探索不同小语言之间的通信方式。

我很喜欢这个概念，Little Languages，小语言。

Little Languages，小语言，设计用来解决非常具体问题的小语言。

例如

小语言的定义来自 Jon Bentley 的论文《Programming pearls: little languages》

他还有其他的定义，Domain-specific languages (DSL:s)

但是还是小语言的叫法最好，因为“小语言”强调了它们的小特性。

▎为什么我们需要小语言？

如果你从工程学历史的角度来看今天的软件，今天的大多数软件非常像一个埃及金字塔，上百万的砖块堆叠在一起，没有结构完整性，只是通过蛮力和成千上万的奴隶完成。— Alan Kay, from A Conversation with Alan Kay

我们在软件工程社区中遇到了一个真正的问题: 随着应用程序复杂性的增长，它的源代码也会变得越来越大。然而，我们理解大型代码库的能力在很大程度上仍然是固定的。根据 Sourcegraph 2020年的调查《大代码的出现》 ，大多数受访者表示，他们的代码库规模造成了以下一个或多个问题:

更糟糕的是，应用程序似乎以惊人的速度增长: 在 Sourcegraph 调查中，大多数受访者估计他们的代码库在过去十年中增长了100到500倍。作为一个具体的例子，Linux 内核开始于1992年的大约10000行代码。20年后，它的重量达到了3000万行。这些代码是从哪来的？我不认为“更多的特性”足以解释代码量的增加; 相反，我认为这与我们构建软件的方式有关。向程序添加新特性的一般方法是将它们堆叠在已有的特性之上，这与构建金字塔的方法没有什么不同。问题在于，就像金字塔一样，后面的每一层都需要比上一层更多的砖块。

你真的需要几百万行代码来构建一个现代化的操作系统吗？

2006年， Alan Kay 的项目 STEPS 开始挑战这一假设。个人计算(操作系统，应用程序和其他支持软件)本质上是20亿，2亿，2千万，2百万，20万，2万，2千行代码吗？科学的发展是通过相互交织的实证研究和理论模型，因此我们作为科学家的第一个问题是: 如果我们建立一个个人计算机现象的工作模型，它是否会崩溃成为一些简单的东西，比如所有电磁波谱的麦克斯韦方程，或者可以放在衬衫口袋里的美国宪法？如果是这样的话，如果能够证明它比另一个巨大的混沌极端更接近简单的结局，那将是非常有趣的。麦克斯韦方程组是一组描述电磁学、光学和电路基础的方程组。它们很酷的一点是，即使它们的视野如此之广，它们也足够紧凑，可以放在一件 T 恤上。

它们如此简洁的一个原因是 Del 符号的使用来描述向量微积分运算。值得注意的是，Del 并不是一个真正的算子ーー它更像是一个速记，使向量微积分中的一些方程更容易处理。如果有可能为编程创建相当于 Del 符号的东西呢？就像 Del 可以使向量演算更易于管理一样，有没有符号可以。助我们以同样的方式推理程序？这个问题是为 STEPS 项目提供动力的“强大想法”之一：我们还认为，创建适合要解决的问题的语言使得解决问题更容易，使得解决方案更易于理解和缩小，并且直接符合我们的“主动数学”方法的精神。这些“面向问题的语言”将被创建并用于大大小小的问题，以及不同层次的抽象和细节。这个想法是，当您开始在应用程序中找到模式时，您可以用一种小语言对它们进行编码ーー这种语言将允许您以比其他抽象方式更紧凑的方式来表达这些模式。这不仅可以阻止应用程序不断增长的趋势，而且实际上还可以在开发过程中缩小代码库！

▎为什么不是高级语言？

可能会说“为什么我们不能发明一种更高层次的通用语言呢?”

就我个人而言，我相信我们已经达到了通用语言表达能力的报酬递减。如果有更高的层次，它会是什么样子？

以 Python 为例ーー它的级别非常高，看起来已经非常像伪代码了。

通用语言的问题在于，您仍然必须将问题转换为算法，然后用目标语言表示算法。

现在，高级语言非常擅长描述算法，但是除非目标是实现算法，否则它就是偶然复杂度。

▎Less is more

小型语言的另一个特征: 功能较弱的语言和更强大的运行时 runtimes

正则表达式和 SQL 不允许您分别表示文本搜索和数据库操作以外的任何内容。

这与 C 语言形成了鲜明的对比，C 语言没有运行时，你可以在冯·诺伊曼结构上表达任何可能的东西。

▎更容易推理

功能较弱的语言更容易推理，并且可以提供比通用语言更强的保证。

如果语言很小，推理起来就更容易了。

例如，要确定一个任意的 Python 程序是否没有副作用是很困难的，但是在 SQL 中却很简单。

只需检查查询是否以 SELECT 开始。

▎对性能的需求

更强大的编程语言不仅会增加 bug 的可能性，而且还会对性能造成损害。

例如，如果一个程序没有用算法来表达，运行时可以自由选择自己的表达式。

如果我们能够证明它们产生相同的结果，那么慢表达式可以替代快表达式。

例如，SQL 查询并不规定查询应该如何执行ーー数据库引擎可以自由地使用它认为最合适的任何查询计划。

例如，它是否应该使用索引、索引的组合，或者只是扫描整个数据库表。

现代数据库引擎还收集关于其列值分布的统计信息，因此它们可以动态地选择统计上最优的查询计划。

如果查询是通过算法来描述的，那么这是不可能的。

▎STEPS 项目怎么样了

他们是否设法创建了一个小到可以放在一件 T 恤上的操作系统？

STEPS 结果是 KSWorld，一个包括文档编辑器和电子表格编辑器的完整操作系统，最终大约有17000行代码。

虽然你需要一件非常大的 T 恤才能把这些都装进去，但我仍然认为这是一种成功。

KSWorld 的创建似乎表明，在小语言领域存在巨大的潜力。

然而，还有许多问题没有得到解答，比如:

这些小语言之间应该如何交流？

它们是否应该编译成一个通用的中间表示？

或者不同的运行时是否应该并行存在，并通过一个公共协议(例如 UNIX 管道或 TCP/IP)彼此通信？

或者每种语言都足够小，可以在各种不同的主机语言(比如正则表达式)中重新实现？

也许未来的道路是所有这些的结合？

无论如何，我坚信我们需要想出一种不同的构建软件的方法。

也许小语言会成为这个故事的一部分，也许它们不会。

重要的是，我们停止在彼此之间堆砌砖头，用足够长的时间来想出更好的东西。

推荐阅读

相关文章