Paul Graham：百年编程语言

如果一些应用逐渐降低对效率的要求，而另一些应用继续要求占用最新的硬件能提供的所有速度。那么更快的计算机就意味着语言必须覆盖一个更广泛的效率范围。我们已经看到了这种事的发生，一些用新近流行的语言来实现的程序如果用几十年前的标准来衡量的话，那对机时的“浪费”是惊人的。

这不只是发生在编程语言上的一个现象，而是一个普遍的历史趋势。当技术更新换代了以后，后一代都能做前一代会认为是浪费的事情。三十年前的人肯定会觉得我们随心所欲地打长途电话是件令人惊讶的事，一百年前的人们一定会更惊讶于从波士顿经过孟菲斯到达纽约的包裹一天就能送到。

我现在就可以告诉你，一百年后当我们有了更快的硬件以后那些新增的处理能力都做了些什么？它们都将被“浪费”掉！

我从计算机能力还很珍贵的时候开始学习编程。我还记得那时候从我的Basic程序中节省出所有能节省的空间以便装入一个4K大小的TRS－80，在这个无止境的重复上我花费了很大的精力，把机器的能力发挥到极限，最终还是受不了这种低效。但是现在看来，我那时拼命节约机器资源的直觉是错误的——就如同一个从小受过贫穷的煎熬的人，连去看医生这样很重要的事情也不舍得花钱。

某些浪费固然是可耻的，譬如SUVs（译注：Sport Utility Vehicle，运动型多功能轿车）就被证明是一种拙劣的产品，即使它载油量很大且不会产生污染。SUV之所以拙劣，是因为它为了解决一个拙劣的问题——怎么让一辆小型货车看上去更威猛。不过不是所有的浪费都是坏的。我们有证据来支持这一点，打长途电话的时候你不会繁琐地一分钟一分钟地数时间，如果有足够的资源，无论是打长途还是短途，你可能会觉得都是一样的。

有好的浪费，也有不好的浪费。我对好的浪费感兴趣，就是那种花更多的开销，但是能获得更简单的设计。我们如何从浪费更新、更快的硬件的机时中获取好处呢？

在这个计算机处理能力很弱的时代，对速度的渴求在我们心中早已根深蒂固，我们应该有意识地克服这种想法。在语言设计中，我们应该有意识地寻找一切机会，用执行效率来换取哪怕很小的使用便利性。

大多数数据结构都是由于速度的原因而存在。譬如，当今很多语言都既有字符串又有列表（list）。从语义上讲，字符串是列表的一个子集——其元素为字符，因此你为什么需要一种单独的数据类型呢？真的不需要。字符串的存在，只是因为效率的原因。但是这种用扰乱语言语义的手法来使程序运行更快的做法是没有说服力的。语言中包含字符串类型就是一种不成熟的优化。

如果我们把语言的核心看成是一组公理集，那么只简单地为了效率的好处而往这个公理集里面添加公理，却不能增加语言的表达力的话，这种添加就是丑陋的。效率是很重要，但是我不认为那种获取效率的方法是正确的。

我认为解决问题的正确方法是将程序的内涵与它的实现细节分离。不要既有列表又有字符串，只要有列表就够了，如果有必要，可以通过某种方式给编译器以建议，允许编译器把字符串按照相邻字节来存放。

既然速度在程序的绝大部分地方都无关紧要，那么你通常就不必为这种小事操心了，这一点随着计算机速度越来越快，将越来越正确。

人们很少注意到程序的实现也应当使程序变得更有弹性。一个程序往往在编写的过程中会发生需求变化，这是不可避免的，也是应当受到欢迎的。

“essay”（译注：企图；小品文）一词源于法语的一个动词“essayer”，意思是“尝试”，也指为了“试图”推演出某一结论而写的东西。软件也跟essay一样，作者往往并不确知哪些才是他们真正要表达的东西，我认为一些最好的程序也是essay。

Lisp（译注：一种表处理语言，用于处理包含有表格的数据的编程语言，被广泛地运用于人工智能研究）黑客（hacker，译注：黑客指掌握尖端电脑技术的人，而不是人们常说的网络入侵者,下同）们已经了解到弹性数据结构的价值，我们倾向于在程序的第一个版本中用列表（list）来处理一切数据。这种最初的版本是如此惊人地低效，因为它有意地避免去想它到底要做什么的细节，就像——至少对我来说——是吃牛排的时候有意避免去想它来自哪里一样。

一百年后程序员将需要什么语言？最可能是那种只需要最少的精力就写出 “非常低效”的“第一版程序”就搞定问题的语言。至少，我们目前可以如此描述这种语言。而用他们的话说，他们需要一种容易编程的语言。

低效的软件不是拙劣的，真正拙劣的是使程序员做不必要的工作的语言。浪费机器时间不是低效，浪费程序员的时间才是真正的低效。这个道理随着计算机越来越快，也将会越来越明白。

我想去掉字符串（string）这种数据结构已经指日可待了。我们在Arc（译注：Lisp的一种方言）中就已经是这么做的，而且成功了。一些用正则表达式描述起来相当拙劣的操作，在Arc中用递归函数就很容易描述了。

像这种扁平的数据结构还能存在多久？我审慎而全面地思考了各种可能性，结果连我都大吃一惊。譬如，我们将会放弃数组吗？毕竟，数组只是一种以整数向量为键值的哈希表（hash table），而我们会连哈希表都用列表来取代吗？

有的预测甚至比这个更骇人听闻。譬如McCarthy在1960就描述过的Lisp语言中连数字（number）都没有。逻辑上讲，你并不一定需要一个关于数字的单独的符号，因为你可以用列表来表示数字，整数n可以用一个n个元素的列表来表示，你可以用这种方式进行数学计算。只不过这样不堪其低效。

现实中没有人被建议用列表来实现数字操作，事实上McCarthy在1960年的论文在那时也根本没有指望被实现。那只是一项理论探讨，只是尝试给图灵机（Turing Machine）创造一种优雅的替代。出人意料的是，有人却根据那篇文章做出了一个可工作的Lisp解释器。不过数字不是用列表来表示，而是跟其他语言里一样，用二进制的方式来表示的。

编程语言会发展到去掉数字这种基本数据类型的程度吗？我这么问不是信口开河地制造耸人听闻的未来问题。情况就如同无坚不摧的矛遇到了无所不克的盾——在这里是无比低效的代码遇到了无比丰富的硬件资源。我认为这完全有可能，因为未来还相当长。如果某种做法可以减少语言的核心公理的数目，那么它随着时光飞逝会越来越值得“下注”。如果某种想法在一百年后依然是荒唐的，在一千年后或许未必荒唐。

（编辑：孝感站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!