Paul Graham：百年编程语言

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

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

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

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

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

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

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

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

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

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

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

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

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

（编辑：西安站长网）

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