抽象性
高级语言比汇编语言更接近人类语言，而某些高级语言又比其他语言更进一步。举例来说，C语言是一种低层次语言，很接近硬件，几乎堪称可移植的汇编语言，而Lisp语言的层次则是相当高。
如果高层级语言比汇编语言更有利于编程，你也许会认为语言的层次越高越好。一般情况下确实如此，但不是绝对的。编程语言可以变得很抽象，完全脱离硬件，但也有可能走错了方向。比如，我觉得Prolog语言就有这个问题。它的抽象能力强得不可思议，但是只能用来解决2%的问题，其余时间你苦思冥想、运用这些抽象能力写出来的程序实际上就是Pascal语言的程序。
另一个你会用到低层次语言的原因就是效率问题。如果你非常关注运行速度，那么最好使用接近机器的语言。大多数操作系统都是用C语言写的，这并非偶然。不过，硬件的运行速度越来越快了，所以使用C这样的低层次语言开发应用程序的必要性正在不断减少，但是大家似乎还是要求操作系统越快越好。（另一种可能是，人们还是希望“缓存区溢出攻击”继续存在下去，以便让大家时时保持警惕）^。
^「最常见的几种入侵计算机的手法都是利用了C语言的某些特点。当你在C语言中为输入的内容分配出一片内存（也叫“缓存”）时，它会被分配在当前运行代码的返回地址旁边。所谓“返回地址”指的是一块特定内存，当前代码运行完毕以后，就要运行这块内存中包含的代码。也就是说，它实标上是计算机下一步要做的事情。
假定有人打算入侵你的计算机，他们猜出你会为某种输入分配256字节的缓存，于是他们就提交多于256字节的内容，目的是覆盖旁边的“返回地址”。那么，当前代码运行完毕之后，程序的控制权就交给了他们指定的内存地址。这个地处通常是缓存的首地址，缓存中是入侵者事前编好的机器码。于是，入侵者的程序就运行在你的计算机上了。
如果使用更抽象的高级语言，上面的事情是不可能发生的。伹是，在C语言中，一旦接受用户输入的时候你没有检奔输入长度，就创造出了一个安全漏洞。利用这种漏洞的攻击行为就被称为“缓冲区溢出攻击”。在这种攻击中，还有其他方法可以控制计算机，但是覆盖返回地址是最经典的一种。
有意思的是，劫持飞机与“缓冲区溢出攻击”有类似之处。在一般飞机上，乘客区与驾驶舱是相通的，就好像C语言中数据区与代码区是相邻的一样。劫机者一且进入驾驶舱，实际上就相当于把自己从数据提升为代码。」
安全带还是手铐？
语言设计者之间的最大分歧也许就在于，有些人认为编程语言应该防止程序员干蠢事，另一些人则认为程序员应该可以用编程语言干一切他们想干的事。Java语言是前一个阵营的代表，perl语言则是后一个阵营的代表。（美国国防部很看中Java也就不足为奇了。）
自由语言派的信徒嘲笑另一方是“B&D”（奴役和戒律，Bondage and Discipline）语言，很无礼地暗示用那些语言编程的人是下等人。我不知道对方如何反击这些喜欢Perl的自由派，也许他们不喜欢给别人起绰号，因此我就无从知道。
由于防止程序员做蠢事有好几种方法，所以上面的争论逐渐分化成几个较小的议题。目前最活跃的议题之一就是静态类型语言与动态类型语言之争。在静态类型语言中，写代码时必须知道每个变量的类型。而在动态类型语言中，随便什么时候，你都可以把变量设为任意类型的值。
静态类型语言的拥护者认为这样可以防止bug，并且帮助编译器生成更快的代码（这两点理由都成立）。动态类型语言的拥护者认为静态类型对程序构成了限制（这点理由也成立）。我本人更喜欢动态类型，痛恨那些限制我的自由的语言。但是，确实有一些很聪明的人看来喜欢用静态类型语言。所以，这个问题依然值得讨论，并没有固定答案。
面向对象编程
眼下另一个争论的热点则是面向对象编程。它是一种不同的组织程序的方法。假定你要写一个程序，计算二维图形的面积。首先，你必须知道到底是圆形还是正方形。一种解决方法是用一整块的代码判断遇到的是什么图形，然后再用相应的公式计算面积。面向对象编程不是这样，它的方法是写出两个类，一个是圆形类，另一个是正方形类，然后每个类里面用一小块代码（叫做方法）计算该类图形的面积。求面积的时候，你就问要用哪一个类，然后再使用相应的方法得出最后答案。
这两种不同的计算方法可能听上去很相似，事实上，运行代码后，实际计算面积的运算过程也很相似。（这不奇怪，因为你本来就在解决同一个问题。）但是，代码的形式却是大相径庭。在面向对象编程的方式中，计算圆面积和正方形面积的代码可能分散在不同的文件中。与圆形有关的代码都放在一个文件中，与正方形有关的代码则放在另一个文件中。
面向对象编程的优点在于，如果你需要修改程序，计算另一种图形的面积，比如三角形，你只需要再另外增加一块相应的代码就可以了，甚至可以不修改程序的其他部分。但是，批评者会反驳说，这种方法的缺点是，由于增加代码不用考虑其他部分，结果往往导致写出性能不佳甚至有副作用的代码，就好比造房子不考虑已经完成的部分一样。
关于面向对象编程优劣的争论并不像静态类型与动态类型之争那样壁垒分明，因为编程的时候你只能在静态类型和动态类型之中选一种。但是，面向对象编程只是程度不同的问题。事实上有两种程度的面向对象编程：某些语言允许你以这种风格编程，另一些语言则强迫你一定要这样编程。
我觉得后一类语言不可取。允许你做某事的语言肯定不差于强迫你做某事的语言。所以，至少在这方面我们可以得到明确的结论：你应该使用允许你面向对象编程的语言。至于你最后到底用不用则是另外一个问题了。
文艺复兴
有一件事，我想所有软件业的人都会同意，那就是最近出现了很多新的编程语言。直到20世纪80年代，只有大机构才买得起开发编程语言所需的硬件，所以大多数编程语言都是大公司的教授或者研究员开发的。而现在，一个高中生就能搞到所有必需的硬件。
Perl语言的设计者拉里·瓦尔^的例子启发了很多黑客：为什么不动手设计一种自己的语言呢？只要你懂得驾驭开源软件社区，就会有很多人在短期内为你提供大量的代码。
^「Larry Wall（1954-）在大学里主修语言学。1987年为了使管理机房的工作变得方便，他在业余时间创造了Perl语言。——译者注」
结果就是产生了一些也许可以称为“头重脚轻”的语言：它们的内核设计得并非很好，但是却有着无数强大的函数库，可以用来解决特定的问题。（你可以想象一辆本身性能很差的小汽车，车顶却绑着一个飞机发动机。）有一些很琐碎、很普遍的问题，程序员本来要花大量时间来解决，但是有了这些函数库以后，解决起来就变得很容易，所以这些库本身可能比核心的语言还要重要。所以，这些奇特组合的语言还是蛮有用的，一时间变得相当流行。车顶上绑着飞机发动机的小车也许真能开，只要你不尝试拐弯，可能就不会出问题^。
^「提醒各位亲爱的黑客，我只是打一个比方，请不要尝试在车顶绑上飞机发动机。另外，可以认为这类“头重脚轻”的语言存在已久，Fortran语言的流行主要就是因为它的函数库。」
另一个结果就是语言的多样化。编程语言之间总是存在很大区别。Fortran、Lisp、APL都是1970年以前开发出来的，它们之间的区别大得就像海星、熊、蜻蜓之间的区别。新兴的开源编程语言肯定将继承这种传统。
现在好像每隔一段日子就能听到一种新出现的语言。乔纳森·埃里克森把这种现象称为“编程语言的文艺复兴”。人们有时还会用另一个说法，即“编程语言的战争”。这并不矛盾，文艺复兴时期就是存在很多战争的。
实际上，很多历史学家相信战争是文艺复兴的一个副产品^。当时，欧洲活力旺盛可能就是因为它分成许多互相竞争的小国。它们互相毗邻，所以新思想能够从一个国家传播到另一个国家，但是它们又互相独立，使得单个的统治者无法遏制创新的发展。相比之下，中国古代的封建皇朝禁止民间建造大型的远洋船只，阻止了经济的正常发展。
^「参见Carlo Cipolla所著的《枪，帆船，帝国：技术革新在1400～1700年欧洲扩张早期阶段的作用》（Guns，Sails，and Empires: Technological Innovation and the Early Phases of European Expansion 1400-1700），Pantheon，1965年出版。」
所以，程序员活在这个文艺复兴时代可能是一件好事。如果我们所有人都使用同一种编程语言，反而有可能是坏事。
11.百年后的编程语言
很难预测一百年后的人类生活，只有少数几件事是可以确定的。那时，汽车将具备低空飞行能力，城市规划的法规将放宽，大楼可以造到几百层，大街上一天到晚看不见太阳，女性个个都学过防身术。本文只想讨论其中的一个细节：一百年后，人们使用什么语言开发软件？
为什么这个问题值得思考？原因不是我们最终会用上这些语言，而是幸运的话，我们从现在开始就能用上这些语言。
我认为，编程语言就像生物物种一样，存在一个进化的脉络，许许多多分支最终都会成为进化的死胡同。这种现象已经发生了。Cobol语言曾经流行一时，但是现在看来没有任何后续语言继承它的思想。它就像尼安德特人^一样，进化之路已经走到了尽头。
^「尼安德特人（Neanderthal），一种生活在欧洲的古人类，三万多年前已经全部灭绝。——译者注」
我预言Java也会如此。有人写信说：“你怎么能说Java不会成功呢？它已经成功了。”我觉得这要看你的成功标准是什么。如果标准是相关书籍的出版量，或者是相信学会Java就能找到工作的大学生数量，那么Java确实已经成功了。当我说Java不会成功时，我的意思是它和Cobol—样，进化之路已经走到了尽头。
这只是我的猜测，未必正确。这里的重点不是看衰Java，而是提出编程语言存在一个进化的脉络，从而引导读者思考，在整个进化过程中，某一种语言的位置到底在哪里？之所以要问这个问题，不是为了一百年后让后人感叹我们曾经如此英明，而是为了找到进化的主干。它会启发我们去选择那些靠近主干的语言，这样对当前的编程最有利。
无论何时，选择进化的主干可能都是最佳方案。要是你不幸选错了，变成了一个尼安德特人，那就太糟了。你的对手克鲁马努人时不时就会来攻打你，把你的食物全部偷走。
这就是我想找出一百年后的编程语言的原因。我不愿意押错赌注。
编程语言的进化与生物学进化还是有区别的，因为不同分支的语言会发生聚合。比如，Fortran分支看来正在与Algol^的继承者聚合。理论上，不同的生物物种也可能发生聚合，但是可能性很低，所以大概从来没有真正出现过。
^「Algol语言诞生于20世纪50年代，是最早的计算机语言之一，对后来的许多语言产生了极大的影响。——译者注」
编程语言之所以可能出现聚合，一个原因是它的概率空间^较小，另一个原因是它的突变不是随机的。语言的设计者们总是有意识地借鉴其他语言的设计思想。
^「概率空间是一个数学术语，大致指概率的可能取值范围。这里的意思是，不管编程语言怎么变，它的形式总是很有限的。——译者注」
对于语言设计者来说，认清编程语言的进化路径特别有用，因为这样就可以照着样子设计语言了。这时，认清进化的主干就不仅有助于识别现存的优秀语言，还可以把它当作设计语言的指南。
任何一种编程语言都可以分成两大组成部分：基本运算符的集合（扮演公理的角色）以及除运算符以外的其他部分（原则上，这个部分可以用基本运算符表达出来）。
我认为，基本运算符是一种语言能否长期存在的最重要因素。其他因素都不是决定性的。这有点像买房子的时候你应该先考虑地理位置。别的地方将来出问题都有办法弥补，但是地理位置是没法变的。
慎重选择公理还不够，还必须控制它的规模。数学家总是觉得公理越少越好，我觉得他们说到了点子上。
你仔细审视一种语言的内核，考虑哪些部分可以被摒弃，这至少也是一种很有用的训练。在长期的职业生涯中，我发现冗余的代码会导致更多冗余的代码，不仅软件如此，而且像我这样性格懒散的人，我发现在床底下和房间的角落里这个命题也成立，一件垃圾会产生更多的垃圾。
我的判断是，那些内核最小、最干净的编程语言才会存在于进化的主干上。一种语言的内核设计得越小、越干净，它的生命力就越顽强。
当然，猜测一百年后人们使用什么编程语言，这本身就是一个很大的假设。也许一百年后人类已经不编程了，或者直接告诉计算机想做什么，计算机就会自动完成。
不过，到目前为止，计算机智能并没有取得太大进展。我猜测一百年后，人们还是使用与现在差不多的程序指挥计算机。可能有一些我们今天需要编程解决的问题，那时已经不需要编程了，但是我想，那时还会存在大量与今天一样的编程任务。
你可能认为只有那些自以为是的人才会去预言一百年后的技术。但是，请不要忘记，软件发展的历史已经走过了50年。在这50年中，编程语言的进化其实是非常缓慢的，因此展望一百年后的语言并不是虚无缥缈的想法。
编程语言进化缓慢的原因在于它们并不是真正的技术。语言只是一种书写法，而程序则是一种严格符合规则的描述，以书面形式记录计算机应该如何解决你的问题。所以，编程语言的进化速度更像数学符号的进化速度，而不像真正的技术（比如交通或通信技术）的进化速度。数学符号的进化是缓慢的渐变式变化，而不是真正技术的那种跳跃式发展。
无论一百年后的计算机是什么样子，我们基本上可以断定它们的运行速度一定会快得多。如果摩尔定律依然成立，一百年后计算机的运行速度将是现在的74乘以10的18次方倍（准确地说是73 786 976 294 838 206 464倍）。真是让人难以想象。不过实际上更现实的预测并不是速度会提高这么多，而是摩尔定律最终将不成立。不管是什么东西，如果每18个月就增长一倍，那么最后很可能会达到极限。但那时的计算机比现在快得多大概是毫无疑问的。即使最后只是略微快了100万倍，也将实质性地改变编程的基本规则。如果其他条件不变，现在被认为运行速度慢的语言（即运行的效率不高）将来会有更大的发展空间。
那时，依然会有对运行速度要求很高的应用程序。我们希望计算机解决的有些问题其实是计算机本身引起的。比如，计算机处理视频的速度取决于生成这些视频的另一台计算机。此外，还有一些问题本身就要求无限快的处理能力，比如图像渲染、加密/解密、模拟运算等。
既然在现实中一些应用程序本身的效率较低，而另一些应用程序会耗尽硬件提供的所有运算能力，那么有了更快速的计算机就意味着编程语言不得不应付更多的极端情况，涵盖更大范围的效率要求。我们已经看到这种情况发生了。要是以几十年前的标准衡量，有一些使用新语言开发的热门应用程序对硬件资源的浪费非常惊人。
不仅编程语言有这种现象，这实际上是一种普遍的历史趋势。随着技术的发展，每一代人都在做上一代人觉得很浪费的事情。30年前的人要是看到我们今天如此随意地使用长途电话，一定会感到震惊。100年前的人要是看到一个普通的包裹竟然也能享受一天内从波士顿发件、途经孟菲斯、抵达纽约的待遇，恐怕就要更震惊了。
我已经预测了，一旦未来硬件的性能大幅提高将会发生什么事。新增加的运算能力都会被糟蹋掉。
在我学习编程的年代，计算机还是稀罕玩意。我记得当时使用的微机型号是TRS-80，它的内存只有4K，为了把BASIC程序装入内存，我不得不把源码中的空格全部删除。我一想到那些极其低效率的软件，不断重复某些愚蠢的运算，把硬件的计算能力全部占用，就感到无法忍受。但是，我的这种反应是错的，我就像某个出身贫寒的穷孩子，一听到要花钱就舍不得，即使把钱用在重要场合（比如去医院看病）都觉得很难接受。
某些浪费确实令人厌恶。比如有人就很讨厌SUV（运动型多用途车），即使它采用可再生的清洁能源也改变不了看法，因为SUV来自一个令人厌恶的想法（如何使得小货车看上去更有男子汉气概）。但是，并非所有的浪费都是坏的。既然如今的电信基础设施已经如此发达，再掐着时间打长途电话就有点锱铢必较了。如果有足够的资源，你可以将长途电话和本地电话视为同一件事，一切会变得更轻松。
浪费可以分成好的浪费和坏的浪费。我感兴趣的是好的浪费，即用更多的钱得到更简单的设计。所以，问题就变成了如何才能充分利用新硬件更强大的性能最有利地“浪费”它们？
对速度的追求是人类内心深处根深蒂固的欲望。当你看着计算机这个小玩意，就会不由自主地希望程序运行得越快越好，真的要下一番功夫才能把这种欲望克制住。设计编程语言的时候，我们应该有意识地问自己，什么时候可以放弃一些性能，换来一点点便利性的提高。
很多数据结构存在的原因都与计算机的速度有关。比如，今天的许多语言都同时有字符串和列表。从语义上看，字符串或多或少可以理解成列表的一个子集，其中的每一个元素都是字符。那么，为什么还需要把字符串单列为一种数据类型呢？完全可以不这么做。只是为了提高效率，所以字符串才会存在。伹是，这种以加快运行速度为目的、却使得编程语言的语义大大复杂的行为，很不可取。编程语言设置字符串似乎就是一个过早优化的例子。
如果我们把一种语言的内核设想为一些基本公理的集合，那么仅仅为了提高效率就往内核添加多余的公理，却没有带来表达能力的提升，这肯定是一件很糟的事。没错，效率是很重要，但是我认为修改语言设计并不是提高效率的正确方法。
正确做法应该是将语言的语义与语言的实现予以分离。在语义上不需要同时存在列表和字符串，单单列表就够了。而在实现上做好编译器优化，使它在必要时把字符串作为连续字节的形式处理^。
^「我相信，Lisp Machine Lisp（Lisp语言的一种方言）是第一个具体表达这样一种观点的语言：变量的声明（除了动态类型变量之外）只是优化的建议，对一个正确程序本身的含义不构成影响。Common Lisp（Lisp语言的另一种方言）则好像第一个明确提出了这一点。」
对于大多数程序，速度不是最关键的因素，所以你通常不需要费心考虑这种硬件层面上的微观管理。随着计算机速度越来越快，这一点已经越发明显了。
语言设计时，对实现方式少作限制还会使得程序具备更大的灵活性。语言的规格发生变化不仅是无法避免的，也是合理的。通过编译器的处理，按照以前规格开发的软件就会照常运行，这就提供了灵活性。
essay（论文）这个词来自法语的动词essayer，意思是“试试看”。从这个原始意义来说，论文就是你写一篇文章，试着搞清楚某件事。软件也是如此。我觉得一些最好的软件就像论文一样，也就是说，当作者真正开始动手写这些软件的时候，他们其实不知道最后会写出什么结果。Lisp语言的黑客早就明白数据结构灵活性的价值。我们写程序的第一版时，往往会把所有事情都用列表的形式处理。所以，这些最初版本可能效率低下得惊人，你必须努力克制自己才能忍住不动手优化它们，这就好像吃牛排的时候必须努力克制自己才能不去想牛排是从哪里来的一样，至少对我来说是这样的。
一百年后的程序员最需要的编程语言就是可以让你毫不费力地写出程序第一版的编程语言，哪怕它的效率低下得惊人（至少按我们今天的眼光来看是如此）。他们会说，他们想要的就是很容易上手的编程语言。效率低下的软件并不等于很烂的软件。一种让程序员做无用功的语言才真正称得上很烂。浪费程序员的时间而不是浪费机器的时间才是真正的无效率。随着计算机速度越来越快，这会变得越来越明显。
我觉得，放弃字符串类型已经是大家可以接受的想法了。Arc语言已经这样做了，看上去效果不错。以前用正则表达式很难描述的一些操作，现在用回归函数可以表达得很简单。
这种数据结构的扁平化趋势会怎么发展？我极其努力地设想各种可能，得到的结果甚至令我自己都吓了一跳。比如，数组会不会消失？毕竟数组只是散列表的一个子集，其特点就是数组的键全部都是整数向量。进一步说，散列表本身会不会被列表取代呢？
还有比这更惊人的预言。在逻辑上其实不需要对整数设置单独的表示法，因为可以把它们也看作列表，整数n可以用一个n元素的列表表示。这一样能完成数学运算，只是效率低得让人无法忍受。
编程语言会发展到放弃基本数据类型之一的整数这一步吗？我这样问并不是真的要你严肃思考这个问题，更多的是希望打开你对未来的思路。我只是提出一种假想的情况：如果一股不可抗拒的力量遇到了一个不可移动的物体，会发生什么事。具体就本文而言：一种效率低得不可想象的语言遇到了性能强大得不可想象的硬件，会发生什么事。我看不出放弃整数类型有什么不妥。未来相当漫长。如果我们想要减少语言内核中基本公理的数目，不妨把眼光放得远一点，想一想如果时间变量t趋向无限会怎么样。一百年是一个很好的参考指标，如果你觉得某个想法在一百年后仍然可能是难以令人接受，那么也许一千年后它也依然难以令人接受。
让我说清楚，我的意思不是说所有的整数运算都用列表来实现，而是说语言的内核（不涉及任何编译器的实现）可以这样定义。在现实中，任何进行数学运算的程序可能都是以二进制形式表示数字，但是这属于编译器的优化，而不属于语言内核语义的一部分。
另一种消耗硬件性能的方法就是，在应用软件与硬件之间设置很多的软件层。这也是我们已经看到的一种趋势，许多新兴的语言就被编译成字节码^。比尔·伍兹曾经对我说，根据经验判断，每增加一个解释层，软件的运行速度就会慢一个数量级。但是，多余的软件层可以让编程灵活起来。
^「字节码（byte code）是已经经过编译但是需要进一步处理才能变成机器码的中间代码。它的好处是与硬件和软件环境无关，在编译器的配合下，可以在不同的操作系统上运行。字节码的典型运用就是Java语言。——译者注」
Arc^语言最初的版本就是一个极端的例子，它的层很多，运行速度非常慢，但是确实带来了相应的好处。Arc是一个典型的“元循环”（meta circular）解释器，在Common Lisp的基础上开发，很像约翰·麦卡锡在他经典的Lisp论文中定义的eval函数。Arc解释器一共只有几百行代码，所以很便于理解和修改。我们采用的Commom Lisp版本是CLisp，它本身是在另一个字节码解释器的基础上开发的。所以，我们一共有两层解释器，最上面那层效率低下得惊人，但是语言本身是能用的。我承认只是勉强可用，但是确实能用。
^「Arc是Lisp的一种方言，由本书作者提出，目前由他本人和罗伯特·莫里斯负责开发。——译者注」
即使是应用程序，使用多层形式开发也是一种很强大的技巧。自下而上的编程方法意味着要把软件分成好几层，每一层都可以充当它上面那一层的开发语言。这种方法往往会产生更小、更灵活的程序。它也是通往软件圣杯——可重用性（reusability）——的最佳路线。从定义上看，语言就是可以重用的。在编程语言的帮助下，你的应用程序越是采用这种多层形式开发，它的可重用性就越好。
可重用性这个概念多多少少与20世纪80年代兴起的面向对象编程有些关联。不管怎样寻找证据，也不可能把这两件事完全分开。某些使用面向对象编程开发出来的软件确实具有可重用性，但是这不是因为它使用了面向对象编程，而是因为它的开发方法是自下而上的。以函数库为例，它们具有可重用性，是因为它们属于语言的一部分，而不是因为它们采用面向对象或者其他编程方法。
顺便说一句，我不认为面向对象编程将来会消亡。我觉得，除了某些特定的领域，这种编程方法其实没有为优秀程序员带来很多好处，但是它对大公司有不可抗拒的吸引力。面向对象编程使得你有办法对面条式代码进行可持续性开发。通过不断地打补丁，它让你将软件一步步做大。大公司总是倾向于采用这样的方式开发软件。我预计一百年后也是如此。
既然是谈论未来，最好谈谈并行计算（parallel computation），因为看上去并行计算好像就是为未来而存在的。无论怎么想，并行计算似乎都是未来生活的一部分。
它会在未来实现吗？过去二十年，人们都在说并行计算马上就会来临。但是，到目前为止，它对编程实践并没有太大影响。这是真的吗？芯片设计师已经不得不把它考虑在内，为多CPU计算机开发系统软件的程序员也是如此。
但是，真正的问题在于，并行计算到底能达到哪个抽象层次？一百年后它就会影响到开发应用软件的程序员吗？或者，它还只是编译器作者需要考虑的事情，在应用软件的代码中根本就无处寻觅？
一种可能是，大多数可以用到并行计算的场合，人们都会放弃使用并行计算。虽然我总的预测是未来的软件会挥霍掉大部分新增的硬件性能，但是并行计算是一个特例。我估计随着硬件性能得到惊人的提升，如果你明确地说想要并行计算，那么肯定可以得到它，但是通常情况下你不会用到它。这意味着，除了一些特殊的应用程序，一百年后的并行计算不会是那种大规模的并行计算（massive parallelism）。我预料，对于普通程序员来说，一切更像对进程进行分叉，然后让多个进程在后台并行运行。
这是编程进行到很后期才要做的事情，属于对程序的优化，类似于你想开发一种特定的数据结构来取代现有的数据结构。程序的第一个版本通常会忽略并行计算提供的各种好处，就好像编程开始时会忽略某种特定的数据结构给你带来的好处一样。
除了某些特定的应用软件，一百年后，并行计算不会很流行。如果应用软件真的大量使用并行计算，这就属于过早优化了。
一百年后会有多少种编程语言？从最近来看，出现了大量的新语言。硬件性能提高是一个原因，这就允许程序员根据使用目的在运行速度和编程便利性之间做出不同的取舍。如果这就是未来的趋势，那么一百年后强大的硬件只会使得语言数目变得更多。
伹是，另一方面，一百年后的常用语言可能只有很少几种。部分原因是基于我的乐观主义，我相信在未来，如果你的作品确实很出色，你可能选择的是一种开发起来很方便的语言。使用这种语言写出来的软件第一版的运行速度很慢，只有对编译器进行优化设置后运行速度才会提升。既然我抱有这种乐观主义，那么我还要做一个预言。有些语言可以达到机器的最高效率，另一些语言的效率则慢到刚刚可以运行而已，两者之间存在巨大的差距。我预言一百年后，这段差距之间的各个点上都会有对应的编程语言存在。
因为这段差距正在变得越来越大，所以性能分析器（profiler）将变得越来越重要。目前，性能分析并没有受到重视。许多人好像仍然相信，程序运行速度提升的关键在于开发出能够生成更快速代码的编译器。代码效率与机器性能的差距正在不断加大，我们将会越来越清楚地看到，应用软件运行速度提升的关键在于有一个好的性能分析器帮助指导程序开发。
我说将来可能只有很少几种常用语言，但没有把用于特定领域的“小众语言”（little language）算进去。我觉得，这些嵌入式语言的想法很不错，一定会蓬勃发展。但是我判断这些“小众语言”会被设计成相当薄的一层，使得用户可以一眼看出在底下作为基础的通用型语言，这样就减少了学习时间，降低了使用成本。
谁来设计这些未来的语言？过去10年最激动人心的趋势之一就是开源语言的崛起，比如Perl、Python和Ruby。语言设计已经被黑客接管。到目前为止这样到底是好是坏还看不清楚，但是发展势头令人鼓舞。比如，Perl就有一些绝妙的创新。不过，它也包含了一些很糟糕的想法。对于一种充满进取心、大胆探索的语言来说，这也是很正常的事。以它现在这种变化的速率，大概只有上帝才知道一百年后Perl会变成什么样。有一句俗话说，如果你自己做不到，那就去当老师。这在语言设计领域不成立，我认识的一些最出色的黑客就在当教授。但是，当老师的人确实有很多事情不能做。研究性职位给黑客带来了一些限制。在任何学术领域，都有一些题目是可以做的，另一些题目是不可以做的。不幸的是，这两类题目的区别通常取决于它们写成论文后看上去是不是很高深，而不是取决于它们对软件业的发展是否重要。最极端的例子可能就是文学，文学研究者的任何成果几乎对文学创作者都毫无影响。
虽然科学领域的状况要稍好一点，但是研究者可以做的题目与能够对设计优秀语言有所帮助的题目之间的交集小得令人沮丧。（奥林·希弗斯曾经对这一点表达不满，而且说得头头是道。）比如，研究变量类型的论文好像多得无穷无尽，尽管事实上静态类型语言看来无法真正支持宏（在我看来，一种语言不支持宏，那就不值得使用了）。
新语言更多地以开源项目的形式出现，而不是以研究性项目的形式出现。这是语言的一种发展趋势。另一种发展趋势是，新语言的设计者更多的是本身就需要使用它们的应用软件作者，而不是编译器作者。这似乎是好的趋势，我期待它继续保持下去。
一百年后的物理学基本上不可能预测。但是计算机语言不一样，现在就动手设计一种一百年后可以吸引使用者的新语言，这在理论上似乎是可能的。
设计新语言的方法之一就是直接写下你想写的程序，不管编译器是否存在，也不管有没有支持它的硬件。这就是假设存在无限的资源供你支配。不管是今天还是一百年后，这样的假设好像都是有道理的。
你应该写什么程序？随便什么，只要能让你最省力地写出来就行。但是要注意，这必须是在你的思维没有被当前使用的编程语言影响的情况下。这种影响无处不在，必须很努力才能克服。你也许觉得，对于人类这样懒惰的生物，喜欢用最省力的方式写程序是再自然不过的事情。但是事实上，我们的思想可能往往会受限于某种现存的语言，只采用在这种语言看来更简单的形式，它对我们思想的束缚作用会大得令人震惊。新语言必须靠你自己去发现，不能依靠那些让你自然而然就沉下去的思维定势。
采用程序的长度作为它耗费工作量的近似指标是个很有用的技巧。这里的程序长度当然不是指字符的数量，而是指各种句法元素的总长度，基本上就是整个解析树的大小。也许不能说最短的程序就是写起来最省力的程序，但是当你一心想把程序写得简洁而不是松松垮垮时，你就更接近省力这个目标，你的日子也会变得好过得多。所以，设计语言的正确做法就变成了，看着一段程序，然后问自己是不是能把它写得更短一点？
实际上，用想象出来的一种一百年后的语言来写程序，这件事情的可靠程度，取决于你对语言内核的估计是否足够正确。常规的排序，你现在就可以写出来。但是，想要预测一百年后的语言使用什么函数库就很难了。很可能许多函数库针对的领域现在还根本不存在。比如，如果SETI@home计划^成功，我们就需要与外星人联系的函数库了。当然，如果外星人的文明高度发达，已经到了用XML格式交换信息的地步，那就不需要新的函数库了。
^「SETI@home是一个寻找地球以外智慧生命的科学实验、由加州大学伯克利分校发起并主持。它使用射电望远镜监听太空中的无线电信号，然后用计算机进行数据分析，如果发现有些信号不可能自然产生，就可以证明外星文明的存在。1995年，该项目决定向志愿者开放，使用全球联网的大量计算机进行分布式计算，1999年5月开始正式运行。详细情况参见u。——译者注」
另一个极端是，我觉得今天你就能设计出一百年后的语言内核。事实上，在有些人看来，大部分语言内核在1958年就已经设计出来了^。
^「Lisp语言的第一版规格说明书是1958年发布的。——译者注」
如果今天就能使用一百年后的编程语言，我们会用它编程吗？观古而知今。如果1960年就能使用今天的编程语言，那时的人们会用它们吗？
在某些方面，回答是否定的。今天的编程语言依赖的硬件在1960年并不存在。比如，Python这样的语言，正确的缩进（indentation）在编写时很重要，但是1960年的计算机没有显示器，只有打印机终端，所以编写起来就不会很顺利。但是，如果把这些因素排除在外（你可以假设，我们只在纸上编程），20世纪60年代的程序员会喜欢用现在的语言编程吗？
我想他们会的。某些缺乏想象力、深受早期编程语言思想影响的人可能会觉得不可能。（没有指针运算，如何复制数据？没有goto语句，如何实现流程图？）但是我想，那时最聪明的程序员一定能轻松地使用今天的大多数语言，假定他们能得到的话。
如果我们现在就能拥有一百年后的编程语言，那就至少能用来写出优秀的伪码^。我们会用它开发软件吗？因为一百年后的编程语言需要为某些应用程序生成快速代码，所以很可能它生成的代码能够在我们的硬件上运行，速度也还可以接受。相比一百年后的用户，我们也许不得不对这种语言做更多的优化，但是总的来看，它应该仍然会为我们带来净收益。
^「伪码又称虚拟代码，用来抽象地描述算法，而不是现实存在的编程代码。——译者注」
现在，我们的两个观点就是：（1）一百年后的编程语言在理论上今天就能设计出来；（2）如果今天真能设计出这样一种语言，很可能现在就适合编程，并且能够产生更好的结果。如果我们把这两个观点联系起来，那就得出了一些有趣的可能性。为什么不现在就动手尝试写出一百年后的编程语言呢？
当你设计语言的时候，心里牢牢记住这个目标是有好处的。学习开车的时候，一个需要记住的原则就是要把车开直，不是通过将车身对齐画在地上的分隔线，而是通过瞄准远处的某个点。即使你的目标只在几米开外，这样做也是正确的。我认为，设计编程语言时，我们也应该这样做。
12.拒绝平庸
1995年，罗伯特·莫里斯和我一起创办了Viaweb。我们打算开发软件，让用户可以自己搭建网上商店。当时，我们的创意是把软件放在服务器端，使用普通的网页作为用户界面。
当然，那个时候许多人可能都想到过这个主意。但是，就我所知，Viaweb是第一个互联网应用程序。在我们看来，这真的是很新颖的想法，所以我们就把公司命名为Viaweb，意即我们的软件通过网络使用，而不是运行在你的桌面电脑上^。
^「在英语中，via是一个介词，意为“经过……”，所以Viaweb的意思就是经过网络。——译者注」
另一个特别之处是，这个软件主要采用Lisp语言开发^。它是最早的用Lisp语言开发的大型应用程序，在此之前，Lisp语言主要用于大学和实验室中。
^「一开始的时候，Viaweb有两个部分——编辑器和订单处理系统。前者用Common Lisp开发，主要供用户搭建自己的网站。后者用C语言开发，主要用来处理订单。在Viaweb的第一版中，Lisp是最主要的开发语言，因为订单处理系统非常小，占用的代码很少。2003年1月，Yahoo发布了Viaweb编辑器的新版本，采用C++和Perl开发。但是，为了把原始程序翻译成C++，他们可能不得不专门写一个Lisp解释器，因为据我所知，Viaweb所有的页面生成模板还没变，都是使用Lisp代码。（参见Greenspun写的Tenth Rule一书第198页。）」
秘密武器
埃里克·雷蒙德写过一篇文章《如何成为一个黑客》（How to Become aHacker）。文中有一部分专门谈到，在他看来，如果你想当一个黑客，应该学习哪些语言。他建议从Python和Java入手，因为它们比较容易学。想当高级一点的黑客，还应该学习C和Perl。前者用来对付Unix系统，后者用来系统管理和开发CGI脚本。最后，真正非常严肃地把黑客作为人生目标的人，应该考虑学习Lisp：
Lisp很值得学习。你掌握它以后，会感到它给你带来的极大启发。这会大大提高你的编程水平，使你成为一个更好的程序员。尽管在实际工作中极少会用到Lisp。
在讨论学习拉丁语有何价值时，你往往也会听到这一类的话。拉丁语无助于你找工作（也许古典文学教授的工作除外），但是它可以训练你的思维，帮助你更好地运用母语（比如英语）进行写作。
但是且慢，拉丁语的比喻并不完全适合Lisp语言。拉丁语无助于你找工作的原因是因为没有人说拉丁语。如果你用它写作，没有人能看懂。但是，Lisp是一种计算机语言，无论我们程序员使用哪一种语言与计算机交谈，它都能听懂。
如果埃里克·雷蒙德没有说错，Lisp语言确实可以使你成为更好的程序员，那么为什么你不使用它编程呢？如果画家有一支让他画得更好的画笔，我觉得他应该会用这支笔完成所有的画作，对不对？我在这里不是想证明埃里克·雷蒙德错了。他的观点整体上非常正确，他对Lisp语言的看法确实是大多数人的看法，但是这里面就是有一个矛盾：Lisp语言能让你成为更好的程序员，但你却不用它，这难道不奇怪吗？
为什么不用呢？编程语言毕竟是一种工具。如果Lisp语言真的能开发出更好的程序，你就应该用它。如果它无助于编程，那么就不会有人需要它。
这不仅仅是一个理论问题。软件业是竞争非常激烈的行业，而且容易出现垄断。在不考虑其他情况的条件下，某家公司的软件更快更好用，就会把竞争者赶出这个市场。一旦你开始创业，你就会更深切地感受到这一点。一般情况是，创业公司要么赢得一切，要么彻底失败。你要么成为富翁，要么一无所获。创业的时候，如果你选择了错误的技术，竞争对手就会一举打败你。
罗伯特·莫里斯和我都很了解Lisp语言，我们相信自己的直觉，找不出任何不使用它的理由。我们知道其他人都用C++或Perl开发软件， 但是我们不觉得这说明了什么问题。如果别人用什么技术，你也用什么技术，那么你大概只能使用Windows了。选择使用哪一种技术的时候，你不能考虑别人的做法，只能考虑什么样的技术能最好地完成工作。
图12-1 我和罗伯特·莫里斯在Viaweb，1996年年初
创业公司尤其如此。大公司可以互相模仿，但是创业公司就不行。我觉得很多人没有意识到这一点，尤其是一些创业者。
大公司每年平均成长大约10%。所以，如果你掌管一家大公司，只要每件事都做到大公司的平均水准，你就能得到大公司的平均结果，也就是每年成长大约10%。
如果你掌管创业公司，当然也可以这样。你把每件事都做到平均水准，就能得到平均结果。问题在于，小公司的平均结果就意味着关门倒闭。创业公司的生存率远低于50%。所以，如果你掌管创业公司，最好做一些独特的事情，否则就会有麻烦。
回到1995年，我们懂得一些竞争对手不懂的事情（至少在我们看来是如此），这些事情甚至直到今天都很少有人懂：如果开发只在自己服务器上运行的软件，这意味着你想用什么语言就能用什么语言。如果开发桌面软件，就完全不一样了，大多数情况下你只能使用操作系统所用的开发语言。10年前，开发桌面软件就意味着要使用C语言。但是，对于互联网软件，你能使用任何你想用的语言。如果你还同时拥有操作系统和语言的源码，那么你的自由就更大了。
但是，这种新出现的自由是一把双刃剑。既然你可以使用任何语言，你就不得不思考到底使用哪一种语言。如果你的公司对这种选择的自由视而不见，而竞争对手看到了，那么你就有被击败的危险。
如果选择哪种语言都行，你到底使用哪一种语言？我们选择Lisp。首先，很明显，对于这个市场来说，快速开发出产品是很重要的。我们所有人都是从零开始，所以能够快速做出新功能的公司就会取得巨大的竞争优势。我们知道Lisp语言真的非常合适快速开发软件，而且我们的软件运行在服务器端，你一写完代码就能发布出去，所以这又进一步放大了快速开发的效果。
如果其他公司不想使用Lisp语言，那就更好了。这会让我们拥有技术优势。我们不能放过任何有利的因素。创办Viaweb的时候，我们对于如何经营一家公司毫无经验，对市场推广、雇用员工、融资、发展新客户等都一无所知。在此之前，我和莫里斯甚至连一夭正式上班的经历都没有。我们唯一擅长的事情就是开发软件。我们希望这一点可以弥补我们的劣势。任何在软件开发上面有助于我们获得优势的事情我们都不能放过。
可以这样说，我们使用Lisp只是一个大胆的冒险。我们设想如果用Lisp语言开发自己的软件，就能比竞争对手更快地写出新功能，还能做到他们做不到的事情。同时，因为Lisp是一种抽象层次非常高的语言，所以就不需要非常庞大的开发团队，这会降低成本。如果我们的设想是正确的，那么我们就能用更少的钱做出一个更好的产品，从而获得利润。最终，我们将独占市场，竞争对手什么也得不到，到头来只能退出这个行业。我们当时心里就是这么盘算的。
这次冒险的结果如何？多少有点出人意料，它竟然达到了我们的设想。我们前前后后遭遇到很多竞争对手，一共大概有二三十个，但是他们的软件没有一个能与我们竞争。我们的软件运行在服务器端，用户可以“所见即所得”地搭建网上商店，感觉就像在操作桌面软件。我们的竞争对手使用CGI脚本。我们在功能上总是遥遥领先于他们。有时，他们出于绝望，试图引入我们没有的功能。但是，有了Lisp语言的帮助，我们的开发周期很短。有时候，竞争对手刚刚发布新闻稿宣布将引入新功能，我们就能在一两天内做出自己的版本。当对手找来的记者抽出时间打电话过来想了解我们的反应，我们就会告诉他我们已经有了这个功能。
竞争对手一定觉得我们好像拥有了某种秘密武器，能够破解他们内部的通信或者其他机密。事实上，我们的确拥有秘密武器，但是没他们想的那么复杂。从来没有人向我们泄露他们的内部机密，只是我们的开发速度比别人想象的更快而已。
9岁时，我碰巧读过弗雷德里克·福赛思的小说《刺杀戴高乐》（The Day of the Jackal）。小说的主角是一个刺客，有人雇他暗杀法国总统。那个刺客必须通过警察的岗哨才能到达可以俯视总统行进路线的公寓。他扮成柱着拐杖的老头从警察身边经过，没有引起任何人的怀疑。
我们的秘密武器很类似上面的情景。我们使用一种奇特的人工智能语言开发软件，它的语法非常古怪，大量使用括号。多年来，要是听到别人这样描述Lisp语言，我会勃然大怒。但是现在，这却成了我们的优势。在竞争中，你的对手无法理解你的技术优势，这可是再宝贵不过了。商场如战场，对手摸不透你，你的胜算就增加了。
虽然有些令人难为情，但是我必须承认，就是因为这个原因，在Viaweb创业期间我从来没有公开谈论过Lisp语言。我们对新闻媒体闭口不谈Lisp，如果你在我们的网站上捜索Lisp，只会发现我在个人介绍中提到过两次，那是我写的两本关于Lisp的书。这是故意的，创业公司对竞争对手应该越保密越好。如果他们不知道（或者不关心）我们的软件用什么语言开发，我就要把这个秘密保持下去^。
^「莫里斯觉得不用这么保密，因为即使竞争对手知道我们使用Lisp语言，对他们也不会有帮助：“如果他们真的聪明，早就已经在用Lisp编程了。”」
最了解我们技术的人就是客户。他们不关心Viaweb用什么语言开发，但是发现它真的很好用。Viaweb可以让用户在几分钟内搭建起漂亮的网上商店。因此，主要通过口碑效应，我们得到了越来越多的新客户。1996年年底，我们支持的网上商店大约是70家。1997年，变成了500家。6个月后，雅虎收购我们的时候，我们有1070个用户。更名为Yahoo Store之后，这个软件继续主导市场，它是雅虎获利最丰厚的业务之一，用它搭建的商店成为“雅虎购物”（Yahoo Shopping）的基础。我在1999年离开了雅虎，所以不知道现在的准确用户数量，但是我上一次听到的数字是超过了2万。
Blub困境
Lisp语言到底好在什么地方？如果它真的这么好，为什么没有得到广泛使用呢？这种问题听起来有点像绕口令，但是实际上回答起来很简单。Lisp语言的好处不在于它有一些狂热爱好者才明白的优点，而只在于它是目前最强大的编程语言。它没有得到广泛使用的原因就是因为编程语言不仅仅是技术，也是一种习惯性思维，非常难于改变。当然，上面两句话都需要进一步解释。
我先从一个争议极大的命题开始讲起：编程语言的编程能力有差异。至少不会有人反对高级语言比机器语言更强大这一观点。今天的大多数程序员通常情况下都不会想用机器语言编程，而是使用一种高级语言，然后再让编译器帮你把它翻译成机器语言。这种观念甚至已经移植到了硬件，从20世纪80年代开始，硬件的指令集都是针对编译器而不是针对程序员设计的。
大家都知道，徒手用机器语言写出整个程序是一件很蠢的事。但是，把这个观点推广到一种更普遍的情况，知道的人就不多了。如果你有好几种语言可以选择，在不考虑其他因素的情况下，你不选择最强大的那种语言就是一件很蠢的事^。
^「如果从图灵等价（Turing-equivatent）的角度来看，所有语言都是一样强大的，但是这对程序员没有意义。（没人想为图灵机编程。）程序员关心的那种强大也许很难正式定义，但是有一个办法可以解释，那就是有一些功能在一种语言中是内置的，但是在另一种语言中需要修改解释器才能做到，那么前者就比后者更强大。如果A语言有一个运算符，可以移除字符串中的空格，而B语言没有这个运算符，这可能不足以称A语言比B语言强大，因为你可以在B语言里写一个函数实现这个功能。但是，如果A语言支持某种高级功能（假定是递归），而B语言不支持，你就不可能通过自己编写函数库解决了，所以这就代表A语言比B语言更强大。」
上面这个观点有许多例外情况。如果在开发的程序必须与另一个程序紧密配合，那么可能最好还是使用后者的开发语言。如果你的程序只是要做一些很简单的事（比如整数运算或者位操作），那就不妨使用一种比较靠近机器的低层次语言，主要原因是这样运行起来会更快一些。如果你的程序很短，只是为了特定场合一次性使用，那么你最好根据自己要解决的问题选择具有最强大函数库的语言，不过，总的来看，对于应用程序来说，还是应该选择总体最强大、效率也在可接受范围内的编程语言，否则都是不正确的选择，就好像你选择机器语言编程一样，只是程度上有差异而已。
大家都公认机器语言属于非常低层次的语言。但是，至少在社会上很多人眼里，高级语言其实也差不多。但事实并非如此，高级语言与机器语言的差别很大。从技术上看，“高级语言”并不是一个定义很清晰的名词。在高级语言与机器语言之间并不存在一条明确的分界线。语言的抽象性是一条连续曲线，从最强大的语言一直到最底层的机器语言，每一种语言的能力都有差异^。
^「语言之间的关系或许还可以比喻成栅格结构（lattice），从下往上朝着顶端慢慢收窄。具体的形状在这里并不重要，重点是语言之间至少存在着一种偏序关系（partial order）。」
以Cobol语言为例，通过编译器，它可以被编译成机器语言。从这个角度来说它是一种高级语言。但是，有谁会真的把Cobol当成与其他高级语言（比如Python）—样强大的语言？比起Python，它可能更接近机器语言。
Perl 4如何？与Perl 5相比，它不支持闭包。所以，大多数Perl的黑客都认为Perl 5比Perl 4更强大。如果你同意这一点，就意味着你也认可一种高级语言可以比另一种高级语言更强大。因此，必然能够接着推导出，除了某些特殊情况，你就是应该使用目前最强大的语言。
不过在现实中这个结论很少能落实。到了一定年龄之后，程序员极少主动更换自己的编程语言。不管习惯使用的是哪一种语言，他们往往认为这种语言已经足够好了。
程序员非常忠于他们心爱的语言，我不想伤害任何人的感情，所以为了解释我的观点，我假设有一种Blub语言。它的抽象程度正好落在编程能力曲线的中点。它不是最强大的语言，但是要比Cobol或机器语言更高级。
我们假设Blub程序员既不使用机器语言也不使用Cobol语言。他认为前者是编译器的工作，后者他不知道有什么用（Cobol语言甚至连XX功能也没有，Blub语言就具备这个功能）。
只要这位程序员向曲线下方望去，他就肯定知道自己正在看的是一些比较低层次的语言。因为那些语言明显不如Blub语言强大，缺少他习惯使用的某些功能。但是，当他向曲线上方望去，他不会意识到自己正在看更高层次的语言，而是仅仅觉得自己正在看某些奇怪的语言。他可能认为那些语言也许与Blub一样强大，但是加入了不少怪东西。他觉得Blub语言已经够用了，不用再考虑那些语言了。这时，他的思维就是已经被Blub同化了。
但是，当我们转换视角，把自己想象成使用曲线更上方某一种语言的程序员并往下看的时候，我们就会发现，自己也同样轻视Blub语言。你怎么用Blub语言完成工作呢？它甚至连YY功能都没有！
通过归纳法我们就会知道，唯一洞悉所有语言优劣的人必然是懂得最强大的那种语言的人。（这大概就是埃里克·雷蒙德所说的Lisp语言使你成为一个更好的程序员的意思。）由于Blub困境的存在，你无法信任其他人的意见：他们都满足于自己碰巧用熟了的那种语言，他们的编程思想都被那种语言主宰了。
我自己的经历也证实了这个看法。高中时我喜欢用Basic语言编程。这种语言功能很弱，甚至不支持递归，很难想象没有递归还怎么编程。但是我那时根本没觉得有损失，Basic语言控制了我的思维。当时我非常精通Basic语言，只要是学过的部分都能熟练地使用。
雷蒙德推荐的五种黑客应该学会的语言，其强大程度各有不同，分布在编程能力曲线五个不同的点上。它们的相对位置是一个敏感的话题。我只想说，我认为，Lisp语言在最上方。为了证明这个论断，让我告诉你，我发现Lisp有一个功能，其他四种语言都没有。我觉得，没有宏（macro）的话，那些语言怎么编程呢^？
^「把宏说成一种独立的功能有误导之嫌。在实际运用中，如果没有其他Lisp功能（比如闭包和函数的rest参数）的配合，Lisp的宏也不会有太大作用。」
许多语言自称也有宏，但是Lisp的宏是独一无二的。信不信由你，Lisp宏的作用与括号有关。Lisp语言的设计者大量使用括号并不是为了标新立异。Blub语言的程序员会觉得Lisp代码看上去很怪，有那么多括号，但这是有原因的。它们是Lisp与其他语言存在巨大差异的外在表现。
Lisp代码由Lisp数据对象构成。其他语言的源代码一般由字符组成，字符串是主要数据类型之一，但是Lisp语言不完全是这样。经过解析器处理之后，Lisp代码就变成了你可以遍历的数据结构。
如果你理解编译器的工作原理，那么事实是，与其说Lisp有一种很奇特的语法，还不如说它根本没有语法。一般的源代码程序经过编译器解析会生成解析树。Lisp的奇特之处就在于，你可以完全写出程序，控制这种解析树，进行任意的存取操作。Lisp的这种程序就叫做宏，它们可以用来生成其他程序。
生成其他程序的程序？什么时候需要用到它们？如果你用Cobol语言思考，会觉得很少需要用到它们。如果你用Lisp语言思考，会发现它们无所不在。我要是在这里举一个Lisp宏功能强大的实例，可能更便于说明问题。你看这个例子！是不是很方便啊？但是如果这样做，对于不懂Lisp语言的人来说，这篇文章就不知所云了。本文没有办法把所有事情都解释清楚，无法帮助你彻底理解这门语言。我在Ansi Common Lisp一书中已经尽可能地简化内容、快速讲解，但是也要到全书篇幅将近一半的地方（第11章）才能讲到宏。
