本文分析了编程语言变得过于庞大复杂的原因，并讨论了如何进行控制。
改编自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 这个语言开始，我们仍然可以欣赏它的小巧。当一种语言很小巧时，添加的每个功能都能直观地感觉到语言的规模大小有显著比例的增加。一个功能的特定好处对它的拥护者来说总是可以看到的。对于小巧的语言来说，人人都可以看到新功能增加复杂性的总体成本。
因此，我请每个对编程语言有影响的人在考虑新功能时，设置一个更高的标准，而不只是这个标准：“如果我们也用这种方式来编写，是不是会更好？”我认为，EcmaScript-2015 处于中间地带，无限制的增长还不可避免。作为社区，我们需要对 EcmaScript-2015 已经发展到的规模有共同的恐慌感。理想情况下，随着我们的规模接近不可逆转的临界点，我们的恐慌感应该进一步增加而不是减少。
一些区别
- 基本语法——不能通过对其他语法的局部扩展忠实地解释的特殊形式
- 语义状态——计算操作的状态
- 内核内置——内置库中提供功能的部分，如果不存在，那么无法通过用户代码提供。
- 非内核 intrinsics——内置在可以用 JavaScript 实现的库中，但是，语义状态或内核内置依赖这些库。比如，借助代理，能够采用用户代码实现数组（Array）。但是，其他内核内置已经特别依赖于数组，使其比任何置换都有特权。
- 语法糖——可以通过对基本语法的局部扩展来解释的语法
- 全局便利库——可以通过非特权用户代码实现，但是，在原始全局命名空间中给出标准的全局命名路径
- 标准便利模块——祝福社区开发的模块成为标准
根据我对增长成本和极简主义的紧迫感，我把这些按顺序列出。对所有这些，我们仍然需要训练纪律。只是对最后一项，我们应该考虑绝对大小的增长是无限的；当我们等待候选者通过事实上的社区接受过程首先证明自身时，只限制增长率。理想情况下，TC39 无论如何都应该不再是最后一项的瓶颈，因为外部事实和法律上的过程完全能够独立地讨论和发展标准便利模块。
本文文字及图片出自 InfoQ
你的反应是：