本文分析了编程语言变得过于庞大复杂的原因，并讨论了如何进行控制。

改编自2015年的es-discuss主题帖子。“Common Lisp”不是主题。它只是众多说明性反例的其中之一。

自2007年以来，我一直是JavaScript标准委员会的成员。关于TC39，我们欣赏语言简单性的价值。但是，随着时间的流逝，我们对日益增长的复杂性失去了警惕。我们必须更好地理解这是如何自然发生的，如果不加以控制，那么代价是什么，以及该怎么办。本文不仅仅针对TC39，还针对所有那些希望影响JavaScript标准或任何面临类似压力的人。请从我们的错误中汲取教训！

Algol、Smalltalk、Pascal和早期的Scheme语言都因为小巧美观而备受称赞。早期的C语言和JavaScript语言因为很多事情受到合理的批评，但是很少被误认为是美观的。但是，它们很小，这方面受到了恰当和广泛的赞赏。当一种编程语言很小的时候，我们欣赏它通常是因为“我可以学整个内容，然后就可以掌握它了”，然后“我知道一切。我很高兴没有我不知道的”。对于C语言和JavaScript语言，很少有人认为他们实际上知道全部内容了——事实上，细节相当复杂。尽管如此，这种感觉还是让人们对日常使用的满意度大大增加了。

JavaScript的小巧美学贯穿EcmaScrip-5。对于EcmaScript-5和EcmaScript-2015，我都参与了很多工作，并且我为自己在这两项工作中做出的贡献感到自豪。EcmaScript-2015 的规模更大一些，尽管如此，它仍然是一种更好的编程语言。考虑到我们工作的起点，如果在规模上没有增加，那么我们不可能在JavaScript的实用性方面获得这些成果。对EcmaScript-5发展到EcmaScript-2015所添加的大多数新增功能，我不后悔。对其中的很多功能，如果我们把EcmaScript-2015标准流程重做一遍，我可能会做类似的添加工作。

把EcmaScript-5发展到EcmaScript-2015，添加的每个功能都必须通过一个非常高的标准。从心理上讲，这对我们所有人都有意义，因为我们从EcmaScript-5这个语言开始，我们仍然可以欣赏它的小巧。当一种语言很小巧时，添加的每个功能都能直观地感觉到语言的规模大小有显著比例的增加。一个功能的特定好处对它的拥护者来说总是可以看到的。对于小巧的语言来说，人人都可以看到新功能增加复杂性的总体成本。

JavaScript的未来？

一旦一种编程语言超过了一定的复杂度，比如LaTex、Common Lisp、C++、PL/1和现代Java，那么编程体验就更像是从一个看似无尽的功能海洋中划出一部分功能供个人使用，而功能海洋中的大部分我们从不会去学习。而一旦感到一种编程语言变成无限时，新功能的特定好处仍然显而易见。但是，新功能增加复杂性的总体成本不再可见。那些讨论新功能的人不再感觉到这些。无穷加上1还是等于无穷。甚至，一个很大的数字加上1后还是一个很大的数字。这不是一刀毙命的死亡，导致了这些怪物无限制地成长。

因此，我请每个对编程语言有影响的人在考虑新功能时，设置一个更高的标准，而不只是这个标准：“如果我们也用这种方式来编写，是不是会更好？”我认为，EcmaScript-2015处于中间地带，无限制的增长还不可避免。作为社区，我们需要对EcmaScript-2015已经发展到的规模有共同的恐慌感。理想情况下，随着我们的规模接近不可逆转的临界点，我们的恐慌感应该进一步增加而不是减少。

一些区别

保持小的非均匀压力

随着我们从核心语言转向标准化库，极简主义的紧迫性变得越来越弱。整个标准语言可以看作是由以下主要部分组成：

基本语法——不能通过对其他语法的局部扩展忠实地解释的特殊形式
语义状态——计算操作的状态
内核内置——内置库中提供功能的部分，如果不存在，那么无法通过用户代码提供。
非内核intrinsics——内置在可以用JavaScript实现的库中，但是，语义状态或内核内置依赖这些库。比如，借助代理，能够采用用户代码实现数组（Array）。但是，其他内核内置已经特别依赖于数组，使其比任何置换都有特权。
语法糖——可以通过对基本语法的局部扩展来解释的语法
全局便利库——可以通过非特权用户代码实现，但是，在原始全局命名空间中给出标准的全局命名路径
标准便利模块——祝福社区开发的模块成为标准

根据我对增长成本和极简主义的紧迫感，我把这些按顺序列出。对所有这些，我们仍然需要训练纪律。只是对最后一项，我们应该考虑绝对大小的增长是无限的；当我们等待候选者通过事实上的社区接受过程首先证明自身时，只限制增长率。理想情况下，TC39无论如何都应该不再是最后一项的瓶颈，因为外部事实和法律上的过程完全能够独立地讨论和发展标准便利模块。

原文链接：
The Tragedy of the Common Lisp:Why Large Languages Explode

创作场景

Common Lisp 的悲剧：为什么大型编程语言会大到爆