也不知道什么原因，最近很多阅读器里面我的博客内容都只有摘要了。 因为我自己没订自己的博客，直到读者和我说了才知道。
事实上我的博客一直输出的是 RSS 2.0 格式，里面包含全文和摘要，从来没改过设置，不知道是不是动了什么插件，还是 Google Reader 或者 Feedburner 出了什么问题，看到的只是摘要了。 不管怎样，我改了一下源代码，往 description 标签里强行插入了博客内容，让阅读器以为这个是摘要。这下，不管什么阅读器都应该看到全文了。
恢复艾未未博客的过程中， 最让人扼腕叹息的就是从 2009 年四月份开始， 新浪网很流氓的让艾未未的博客只输出摘要，尽管艾未未在后台设置了输出全文。 这样， 很多的数据，现在都只有摘要，没有全文。 不管从读者还是从作者角度来说，全文输出都是比摘要输出更好的选择，也有利于信息的传播。 我一直支持全文输出，肯定不会为了赚点所谓的PV摘要输出的 :)
以后等祖国大陆光复后，新浪这种为虎作伥罪行累累的无良企业，肯定会接受历史的审判，我们都等着呢。
整一个月零一天前，我在北京和 zuola 老师见了一面，商量怎么恢复 aiweiwei 老师被新浪和谐掉的博客的内容。 因为 Google Reader 这些阅读器实际上缓存了博客的 feed, 而我以前又有专门抓 Google Reader 内容的代码，所以很容易就抓到了所有的数据。
根据我抓到的数据，我说几个统计数据： Aiweiwei 老师从 2007 年 7月22 日 开博一来，到 2009年5月27日被和谐，一共有 1639 篇文章。
这 1639篇文章中， 有这样几个数据：
从2008 年 11月 27 日某个一直想要说法的公民死亡开始，aiweiwei 的博客上每天贴了一张 “蜡烛”， 从”一“ 开始到 ”蜡烛 一百八十一 09.05.27“ 结束，中间只缺了 08年12月14日这一天。 我也写博客，我知道坚持一天贴一张图需要的坚持和毅力。 但就这样的贴图，都被新浪删除了不少。
“5.12遇难学生名单 补充” 系列，从“一”开始， 到 “一百三十二”, 里面全是一个一个活生生的名字。 这些文章，平均被新浪删除三次，艾未未老师也不和新浪发火，删了三次，就重新贴三次。 因为 aiweiwei 老师把新浪的删除日志也贴出来，所以，像以下这样的句子在我抓到的数据里比比皆是， 比如，数据中有以下这几行：
您的文章《5.12遇难学生名单补充（二) 09.03.17″>已被管理员转移到回收站。给您带来的不便，深表歉意。
您的文章《被删除文章 5.12遇难学生名单补充（二) 09.03.17″><已被管理员转移到回收站。给您带来的不便，深表歉意。
您的文章《被删除文章 5.12遇难学生名单补充（二) 09.03.17″> 已被管理员删除。给您带来的不便，深表歉意。
就 “被删除文章 5.12遇难学生名单补充（二) 09.03.17” 这篇文章， aiweiwei 贴了三次。 像这种文章，一般刚贴出来，新浪就很快删除了，所以我们读者根本看不到痕迹。可是，这些痕迹在 RSS 里面每条都有，所以很容易看到一条条这样触目惊心的删除，贴，再删除，再帖。在看不到数据之前，我们都不知道这样列着遇难学生名单的文章居然能被这样删三次，贴三次。这种持久的删了再帖的耐心，我想普通人是做不到的。
我知道有人不喜欢艾未未老师，以为他是在搞行为艺术，是想出名，看了数据之后，我想至少大家能够对他做的事情多点支持和理解，也就行了。
为了让更多的人看到 aiweiwei 老师在新浪博客上付出的心力和做的事情，我愿意将我抓到并处理后的数据与所有的人分享。 因为数据非常大， 想要的读者请给我发邮件。您拿到数据之后，可以直接导入任何 WordPress 博客。另外，我有一整套的从 Google Reader 恢复 WordPress 的代码，只要您的 WP 博客有人订阅，全文输出，如果数据因为某些原因丢失了， 我的代码可以帮你很快的恢复博客。 稍后等我有空，我会把代码和恢复中的技术要点全部贴出来。
在高级语言是怎么来的子系列的第一篇中， 我们结合当时硬件的特点，分析了 FORTRAN 为什么一开始不支持递归。但是 FORTRAN 本身是怎么来的这个问题其实还是没有得到正面回答，本节我们就谈谈 FORTRAN 语言本身是怎么来的。
其实，FORTRAN 语言也是现实驱动的。 所以我们还是回到当时，看看当时程序员的需求和软硬件条件，看看 FORTRAN 是怎么来的。 了解历史的另一个好处是， 因为 FORTRAN 的发展历史正好和高级语言的发展历史高度重合，所以了解 FORTRAN 的背景，对于理解其他高级语言的产生都是大有帮助的。
1. 困难的浮点计算
我们先从硬件的角度说起。 大致从 1946 年第一台计算机诞生，到 1953 年，计算机一直都缺少两件非常重要的功能，一个叫浮点计算，一个叫数组下标寻址，这两个功能的缺失直接导致了高级语言的兴起。 我们依次单个分析。读者对浮点计算应该都不陌生，用通俗的话说就是如 0.98×12.6 这样的实数乘法，或者 0.98 + 12.6 这样的实数加法的运算。用行话说，就是用计算机进行大范围高精度数的算术运算。
学过二进制的同学都知道，二进制整数之间的乘法和加法等运算都是相对简单的，和正常的十进制运算是一样的，只是把加法和乘法这些基本操作用更加简单的逻辑或(OR) 和 逻辑与 (AND) 实现而已，在电子电路上也很好实现。 因此，就是世界上最早的电子计算机，ENIAC，也是支持整数的乘法加法等算术操作的。
可是浮点运算就不一样了。 因为一个额外的小数点的引入，在任何时候都要注意小数点的对齐。 如果用定点计数，则计数的范围受到限制，不能表示非常大或者非常小的数。所以，浮点数一般都是用科学记数法表示的，比如 IEEE 754 标准。（不熟悉 IEEE 754 的读者也可以想像一下如何设计一套高效的存储和操作浮点数的规范和标准，以及浮点算法）， 科学记数法表示的浮点数的加减法每次都要对齐小数点，乘除法为了保持精度，在设计算法上也有很多技巧，所以说，相比较于整数的运算和逻辑运算，浮点运算是一件复杂的事情。落实到硬件上就是说，在硬件上设计一个浮点运算，需要复杂的电路和大量的电子元器件。在早期电子管计算机中，是很少能做到这么大的集成度的。因此，不支持浮点也是自然的设计取舍。在计算机上放一个浮点模块这个想法，需要等电子工业继续发展，使得电子管体积小一点，功耗低一点后，才能进入实践。
2. 关于浮点计算的一些八卦
关于浮点，这里顺带八卦一点浮点计算的事情。在计算机芯片设计中，浮点计算一直是一个让硬件工程师头疼的事情，即使到了386时代，386 处理器 (CPU)的浮点乘法也是用软件模拟的，如果想用硬件做浮点乘法，需要额外购买一块 80387 浮点协处理器 FPU，否则就在 386 上做软件的模拟。这样做的原因在一块硅片上刻蚀一个 CPU 和一个FPU 需要的集成度还是太高，当时的工艺根本没法实现。真的把 FPU 和 CPU 融在一起刻蚀到一块硅片上，已经是 1989 年的事情了。当时，Intel 把融合了 80386 和 80387 的芯片改了改，起了个名字叫 80486，推向了市场。带着浮点的处理器的普及，使得个人计算机能做的事情变多了。极度依赖于浮点计算的多媒体计算机（视频和声音等多媒体的压缩，转换和回放都是要依赖于浮点运算的），也正好随着 80486 的流行，逐渐普及开来。
在处理器上融合浮点运算依然是困难的。即使到今天，很多低端的处理器，都不带有浮点处理器。 所以，号称能够上天入地的，被移植到很多低端设备比如手机上的 Linux 内核，必然是不能支持浮点运算的，因为这样会破坏内核的可移植性。我们都知道， 在内核模式下，为了保证内核操作的原子性，一般在内核从事关键任务的时候所有中断是要被屏蔽的，用通俗的话说就是内核在做事情的时候，其他任何人不得打 扰。 如果内核支持浮点运算，不管是硬件实现也好，软件模拟也罢， 如果允许在内核中进行像浮点计算这样复杂而耗时的操作，整个系统的性能和实时响应能力会急剧下降。 即使是在硬件上实现的浮点运算，也不是件容易的事情，会耗费CPU较多的时钟周期，比如 Pentium 上的浮点数除法，需要耗费 39 个时钟周期才行，在流水线设计的CPU中，这种占用多个时钟周期的浮点运算会让整个流水线暂停，让CPU的吞吐量下降。在现代 CPU 设计中，工程师们发明了超标量，乱序执行，SIMD 等多种方式来克服流水线被浮点运算这种长周期指令堵塞的问题，这都是后话了。
正因为对于计算机来说，浮点运算是一个挑战性的操作，但又是做科学计算所需要的基本操作，所以浮点计算能力就成了计算机能力的一个测试标准。我们常常听说有一个世界上前 500 台最快的超级计算机列表，这里所谓的“快”的衡量标准，就是以每秒钟进行多少次浮点计算(FLOPS) 为准。按照 Top500.org, 即评选世界上前 500 台超级计算机的机构 2009年6月的数据，世界上最快的计算机，部署在美国能源部位于新墨西哥的洛斯阿拉莫斯国家实验室 (Los Alamos National Laboratory)，当年造出第一颗原子弹的实验室。这台超级计算机，浮点计算速度的峰值高达 1456 TFlops，主要用来模拟核试验。因为美国的所有核弹头，海军核动力航母中的反应堆以及核试验，都由能源部国家核安全署(NNSA) 管理，所以能源部一直在投资用超级计算机进行核试验。 在 1996 年美国宣布不再进行大规模的物理核试验后的这么多年，美国能源部一直用超级计算机来做核试验，所以在 Top500 列表中，美国能源部拥有最多数量的超级计算机。
3. 数组下标寻址之障
言归正传，我们刚才说了在早期计算机发展史上，浮点计算的困难。除了浮点计算，还有一件事情特别困难，叫做数组下标寻址。用现代通俗的话说，就是当年的计算机，不直接支持 A[3] 这样的数组索引操作，即使这个操作从逻辑上说很简单：把数组 A 的地址加上 3，就得到了 A[3] 的地址，然后去访问这个地址。
这个困难在今天的程序员看来是不可思议的。 为什么这么简单的数组下标寻址机制最一开始的计算机没有支持呢？ 原来，当年的计算机内存很小，只有一千到两千的存储空间，所以，描述地址只需要几位二/十进制数（BCD)。从而，在每条指令后面直接加一个物理地址是可行且高效的寻址方式。这种寻址方式，叫做直接寻址，当时所有的机器，都只支持直接寻址，因为在机器码中直接指出操作数的准确地址是最简单直接的方法，计算机不需要任何复杂的地址解码电路。但坏处是，这个设计太不灵活了，比如说 A[3] 这个例子，就没法用直接寻址来表示。
一般情况下，如果知道数组A， 对于 A[3] 这样的例子，用直接寻址问题去模拟间接寻址的困难还不是很大，只要程序员事先记住数组 A 的地址然后手工加上 3 就行了 （A也是程序员分配的，因为当时没有操作系统，所以程序员手工管理内存的一切）。可是，也有一些情况这样直接寻址是不行的。比如说，当时计算机已经能支持跳转和判断指令了，也就是说，可以写循环语句了。我们可以很容易看到， 以 i 为循环变量的循环体内，对 A[i] 的访问是不能写成一个静态的直接寻址的，因为 i 一直在变化，所以不可能事先一劳永逸的定好 A[i] 的所在位置，然后静态写在程序中。
这样，即使写一个简单的 10×10 矩阵的乘法，程序员就不得不死写 10的三次方即1000 行地址访问，而没办法用几行循环代替。当时的一些聪明人，也想了一些方法去克服这个问题，比如说，他们先取出 A 的地址，然后做一次加法，把结果，也就是当时 A[i] 的地址，注射到一个读内存的 LOAD 指令后面。然后执行那条 LOAD 指令。比如我要读 A[i]，我先看，A的地址是 600，再看看 i 是3， 就加上 i，变成603，然后，把后面的指令改成 LOAD 603， 这样，就可以读到 A[i]。这个小技巧之所以可行，要感谢冯诺依曼爷爷的体系设计。在冯诺依曼计算机中，数据和程序是混在一起不加区分的，所以程序员可以随时像修改数据一样修改将要运行的下一条程序指令。就这样，靠着这个小技巧, 好歹程序员再也不要用1000行代码表示一个矩阵乘法了。
4. SpeedCoding 的出现
计算机本来就是用来做数学计算的，可是科学计算里面最最基本的两个要素–浮点计算和数组下标访问，在当时的计算机上都缺少支持。这种需求和实际的巨大落差，必然会召唤出一个中间层来消弭这种落差。 其实计算机科学的一般规律就是这样：当 A 和 C 相差巨大的时候，我们就引入一个中间层 B，用 B 来弥合 A 和 C 之间的不兼容。 当年的这个中间层，就叫做 SpeedCoding，由 IBM 的工程师 John Backus 开发。
SpeedCoding，顾名思义，就是让程序员编程更快。它其实是一个简单，运行在 IBM 701 计算机上的解释器。它允许程序员直接写浮点计算和下标寻址的指令，并且在底层把这些 “伪指令” 翻译成对应的机器码，用软件模拟浮点计算，自动修改地址等等。这样，程序员就可以从没完没了的手工实现浮点运算和下标寻址实现中解放出来，快速的编程。这个 SpeedCoding，这可以算得上是 FORTRAN 的种子了。
虽然这个解释器超级慢，程序员用这个解释器也用得很爽，也不感到它非常慢。 这是因为当年计算机浮点计算都绕不过软件模拟，即使最好的程序员用机器码而不用这个解释器，写出来的程序，也不比这个解释器下运行快多少。另一个更加重要的原因是，这个解释器极大的减少了程序员 debug 和 code 的时间。随着计算机速度的提高，当年一个程序耗费的计算成本和程序员编程耗费的人力成本基本上已经持平了，所以，相比较于写更加底层的机器码，用了 SpeedCoding 的程序员的程序虽然慢点，但人力成本瞬间降成 0，总体下来，用 SpeedCoding 比起不用来，总体成本还要低不少。
好景不长，因为客户一直的要求和电子工业的发展，IBM 在 1954 年，终于发布了划时代的 704 计算机，很多经典的语言和程序，都首次在 704 上完成了。比如之前我们在本系列的D篇中提到的 Steve Russell 的 LISP 解释器，就是在 704 上完成的。 704 计算机一下子支持了浮点计算和间接下标寻址。 这下用 SpeedCoding 的人没优势了，因为机器码支持浮点和下标寻址之后，写机器码比写 SpeedCoding 复杂不了多少，但是速度快了很多倍，因为 SpeedCoding 解释器太慢了，以前因为浮点和解释器一样慢，所以大家不在意它慢，现在浮点和寻址快了，就剩下解释器慢，写机器码的反而占了上风，程序员也就不用 SpeedCoding 了。
5. FORTRAN 创世纪
在 704 出来之前，做 SpeedCoding 的 John Backus 就认识到，要想让大家用他的 SpeedCoding, 或者说，想要从软件工具上入手，减少程序的开发成本，只有两个方法： 1. 程序员可以方便的写数学公式 2. 这个系统最后能够解析/生成足够的快的程序。他认为，只有达到了这两点，程序员才会乐意使用高级的像 SpeedCoding 这样的工具，而不是随着硬件的发展在机器码和 SpeedCoding 这样的工具之间跳来跳去。他本人通过实现 SpeedCoding, 也认识到如果有一个比机器码高级的语言， 生产效率会高很多倍。那么，现在唯一的问题就是实现它，当然，这就不是一个小项目了，就需要 IBM 来支持他的开发了。 所以，在 1953年，他把他的想法写成了一个文档，送给了 IBM 的经理。项目在 1954 年， 704 发布的当年，终于启动。John Backus 领导的设计一个能达到上面两点的编程系统的项目的成果，就是日后的 FORTRAN。
和现在大多数编程语言不一样，FORTRAN 语言的设计的主要问题不是语法和功能，而是编译器怎么写才能高性能。John Backus 日后回忆说，当时谁也没把精力放在语言细节上，语言设计很潦草的就完成了（所以其后正式发布后又经过了N多修订），他们所有的功夫都是花在怎么写一个高性能的编译器上。这个高性能的编译器很难写，到 1957 年才写好，总共花了 IBM 216 个人月。等到 FORTRAN 一推出，不到一年的时间，在 IBM 总共售出的 60 台 704上，就部署了超过一半。现在没啥编程语言能够这么牛的攻城掠地了 ：）
6. 结语
放到历史的上下文中看，FORTRAN 的出现是很自然的。一方面，复杂的数学运算使得一个能够表述数学计算的高级语言成为必须，计算机的发展也为这个需求提供的硬件条件；另一方面，随着计算机的发展，程序员的时间成本一直不变，但是计算的成本一直在降低，用高级语言和用机器码在性能上的些许差异变得可以忽略。这样的历史现实，必然会召唤出以少量的增加计算机工作量为代价，但能大幅度降低程序员时间成本的新的工具和设计。这种新的工具，新的设计，又对程序设计产生革命性的影响。在整个编程发展的历史上，FORTRAN 和其他高级语言的出现可以说是第一波的革命；而后， UNIX和C语言的兴盛，使得系统编程的效率得到革命性提升，可以算是第二波革命；而面向对象方法，使得复杂的 GUI 等系统的编程效率得到提升，应该算得上是第三波革命。到如今，现在各种各样的方法论就更加多了，且看以后回看，哪种方法和工具能够大浪淘沙留下来。
上节我们提到了 LISP 中, 因为 eval 的原因, 发展出了运行时环境这样一个概念。基于这个概念，日后发展出了虚拟机技术。但这段历史并不是平铺直叙的，实际上，这里面还经历了一个非常漫长而曲折的过程， 说起来也是非常有意思的。 这一节我们就着重解释虚拟机的历史。
我们 21 世纪的程序员，凡要是懂一点编程技术的，基本上都知道_虚拟机_和_字节码_这样两个重要的概念。 所谓的字节码 (bytecode)，是一种非常类似于机器码的指令格式。这种指令格式是以二进制字节为单位定义的（不会有一个指令只用到一个字节的前四位），所以叫做字节码。所谓的虚拟机，就是说不是一台真的计算机，而是一个环境，其他程序能在这个环境中运行，而不是在真的机器上运行。现在主流高级语言如 Java, Python, PHP, C#，编译后的代码都是以字节码的形式存在的， 这些字节码程序， 最后都是在虚拟机上运行的。
1. 虚拟机的安全性和跨平台性
虚拟机的好处大家都知道，最容易想到的是安全性和跨平台性。安全性是因为现在可执行程序被放在虚拟机环境中运行，虚拟机可以随时对程序的危险行为，比如缓冲区溢出，数组访问过界等等进行控制。跨平台性是因为只要不同平台上都装上了支持同一个字节码标准的虚拟机，程序就可以在不同的平台上不加修改而运行，因为虚拟机架构在各种不同的平台之上，用虚拟机把下层平台间的差异性给抹平了。我们最熟悉的例子就是 Java 了。Java 语言号称 一次编写，到处运行(Write Once, Run Anywhere)，就是因为各个平台上的 Java 虚拟机都统一支持 Java 字节码，所以用户感觉不到虚拟机下层平台的差异。
虚拟机是个好东西，但是它的出现，不是完全由安全性和跨平台性驱使的。
2. 跨平台需求的出现
我们知道，在计算机还是锁在机房里面的昂贵的庞然大物的时候，系统软件都是硬件厂商附送的东西（是比尔盖茨这一代人的出现，才有了和硬件产业分庭抗礼的软件产业），一个系统程序员可能一辈子只和一个产品线的计算机打交道，压根没有跨平台的需求。应用程序员更加不要说了，因为计算机很稀有，写程序都是为某一台计算机专门写的，所以一段时间可能只和一台庞然大物打交道，更加不要说什么跨平台了。 真的有跨平台需求，是从微型计算机开始真的普及开始的。因为只有计算机普及了，各种平台都被广泛采用了，相互又不互相兼容软件，才会有软件跨平台的需求。微机普及的历史，比 PC 普及的历史要早10年，而这段历史，正好和 UNIX 发展史是并行重叠的。
熟悉 UNIX 发展史的读者都知道， UNIX 真正普及开来，是因为其全部都用 C，一个当时绝对能够称为跨平台的语言重写了一次。又因为美国大学和科研机构之间的开源共享文化，C 版本的 UNIX 出生没多久，就迅速从原始的 PDP-11 实现，移植到了 DEC，Intel 等平台上，产生了无数衍生版本。随着跨平台的 UNIX 的普及， 微型计算机也更多的普及开来，因为只需要掌握基本的 UNIX 知识，就可以顺利操作微型计算机了。所以，微机和 UNIX 这两样东西都在 1970年 到 1980 年在美国政府，大学，科研机构，公司，金融机构等各种信息化前沿部门间真正的普及开来了。这些历史都是人所共知耳熟能详的。
既然 UNIX 是跨平台的，那么，UNIX 上的语言也应当是跨平台的 （注: 本节所有的故事都和 Windows 无关，因为 Windows 本身就不是一个跨平台的操作系统）。UNIX 上的主打语言 C 的跨平台性，一般是以各平台厂商提供编译器的方式实现的，而最终编译生成的可执行程序，其实不是跨平台的。所以，跨平台是源代码级别的跨平台，而不是可执行程序层面的。 而除了标准了 C 语言外，UNIX 上有一派生机勃勃的跨平台语言，就是脚本语言。（注：脚本语言和普通的编程语言相比，在能完成的任务上并没有什么的巨大差异。脚本语言往往是针对特定类型的问题提出的，语法更加简单，功能更加高层，常常几百行C语言要做的事情，几行简单的脚本就能完成）
3. 解释和执行
脚本语言美妙的地方在于，它们的源代码本身就是可执行程序，所以在两个层面上都是跨平台的。不难看出，脚本语言既要能被直接执行，又要跨平台的话，就必然要有一个“东西”，横亘在语言源代码和平台之间，往上，在源代码层面，分析源代码的语法，结构和逻辑，也就是所谓的“解释”；往下，要隐藏平台差异，使得源代码中的逻辑，能在具体的平台上以正确的方式执行，也就是所谓的“执行”。
虽说我们知道一定要这么一个东西，能够对上“解释”，对下“执行”，但是 “解释” 和 “执行” 两个模块毕竟是相互独立的，因此就很自然的会出现两个流派：把解释和执行设计到一起 和 把解释和执行单独分开来 这样两个设计思路，需要读者注意的是，现在这两个都是跨平台的，安全的设计，而在后者中字节码作为了解释和执行之间的沟通桥梁，前者并没有字节码作为桥梁。
4. 解释和执行在一起的方案
我们先说前者，前者的优点是设计简单，不需要搞什么字节码规范，所以 UNIX 上早期的脚本语言，都是采用前者的设计方法。 我们以 UNIX 上大名鼎鼎的 AWK 和 Perl 两个脚本语言的解释器为例说明。 AWK 和 Perl 都是 UNIX 上极为常用的，图灵完全的语言，其中 AWK, 在任何 UNIX 系统中都是作为标准配置的，甚至入选 IEEE POSIX 标准，是入选 IEEE POSIX 卢浮宫的唯一同类语言品牌，其地位绝对不是 UNIX 下其他脚本语言能够比的。这两个语言是怎么实现解释和运行的呢？ 我从 AWK 的标准实现中摘一段代码您一看就清楚了:
int main(int argc, char *argv[]) { ... syminit(); compile_time = 1; yyparse(); ... if (errorflag == ) { compile_time = ; run(winner); } ... }
其中, run 的原型是
run(Node *a) /* execution of parse tree starts here */
而 winner 的定义是:<br />
Node *winner ; /* root of parse tree */
熟悉 Yacc 的读者应该能够立即看出, AWK 调用了 Yacc 解析源代码，生成了一棵语法树。按照 winner 的定义, winner 是这棵语法树的根节点。 在“解释”没有任何错误之后，AWK 就转入了“执行” (compile_time 变成了 0)，将 run 作用到这棵语法树的根节点上。 不难想像，这个 run 函数的逻辑是递归的（事实上也是），在语法树上，从根依次往下，执行每个节点的子节点，然后收集结果。是的，这就是整个 AWK 的基本逻辑: 对于一段源代码, 先用解释器（这里awk 用了 Yacc 解释器），生成一棵语法树，然后，从树的根节点开始，往下用 run 这个函数，遇山开山，遇水搭桥，一路递归下去，最后把整个语法树遍历完，程序就执行完毕了。（这里附送一个小八卦，抽象语法树这个概念是 LISP 先提出的，因为 LISP 是最早像 AWK 这样做的，LISP 实在是属于开天辟地的作品！）Perl 的源代码也是类似的逻辑解释执行的，我就不一一举例了。
5. 三大缺点
现在我们看看这个方法的优缺点。 优点是显而易见的，因为通过抽象语法树在两个模块之间通信，避免了设计复杂的字节码规范，设计简单。但是缺点也非常明显。最核心的缺点就是性能差，需要资源多，具体来说，就是如下三个缺点。
缺点1，因为解释和运行放在了一起，每次运行都需要经过解释这个过程。假如我们有一个脚本，写好了就不修改了，只需要重复的运行，那么在一般应用下尚可以忍受每次零点几秒的重复冗余的解释过程，在高性能的场合就不能适用了。 **
缺点2，因为运行是采用递归的方式的，效率会比较低。 我们都知道，因为递归涉及到栈操作和状态保存和恢复等，代价通常比较高，所以能不用递归就不用递归。在高性能的场合使用递归去执行语法树，不值得。
缺点3，因为一切程序的起点都是源代码，而抽象语法树不能作为通用的结构在机器之间互传，所以不得不在所有的机器上都布置一个解释+运行的模块。 在资源充裕的系统上布置一个这样的系统没什么，可在资源受限的系统上就要慎重了，比如嵌入式系统上。 鉴于有些语言本身语法结构复杂，布置一个解释模块的代价是非常高昂的。本来一个递归执行模块就很吃资源了，再加一个解释器，嵌入式系统就没法做了。所以，这种设计在嵌入式系统上是行不通的。
当然，还有一些其他的小缺点，比如有程序员不喜欢开放源代码，但这种设计中，一切都从源代码开始，要发布可执行程序，就等于发布源代码，所以不愿意公布源代码的商业公司很不喜欢这些语言等等。但是上面的三个缺点，是最致命的，这三个缺点，决定了有些场合，就是不能用这种设计。
6. 分开解释和执行
前面的三个主要缺点，恰好全部被第二个设计所克服了。在第二种设计中， 我们可以只解释一次语法结构，生成一个结构更加简单紧凑的字节码文件。这样，以后每次要运行脚本的时候， 只需要把字节码文件送给一个简单的解释字节码的模块就行了。因为字节码比源程序要简单多了，所以解释字节码的模块比原来解释源程序的模块要小很多；同时，脱离了语法树，我们完全可以用更加高性能的方式设计运行时，避免递归遍历语法树这种低效的执行方式；同时，在嵌入式系统上，我们可以只部署运行时，不部署编译器。 这三个解决方案，预示了在运行次数远大于编译次数的场合，或在性能要求高的场合，或在嵌入式系统里，想要跨平台和安全性，就非得用第二种设计，也就是字节码+虚拟机的设计。
讲到了这里，相信对 Java, 对 PHP 或者对 Tcl 历史稍微了解的读者都会一拍脑袋顿悟了: 原来这些牛逼的虚拟机都不是天才拍脑袋想出来的，而是被需求和现实给召唤出来的啊！
我们先以 Java 为例，说说在嵌入式场合的应用。Java 语言原本叫 Oak 语言，最初不是为桌面和服务器应用开发的，而是为机顶盒开发的。SUN 最初开发 Java 的唯一目的，就是为了参加机顶盒项目的竞标。嵌入式系统的资源受限程度不必细说了，自然不会允许上面放一个解释器和一个运行时。所以，不管Java 语言如何，Java 虚拟机设计得直白无比，简单无比，手机上，智能卡上都能放上一个 Java 运行时（当然是精简版本的）。 这就是字节码和虚拟机的威力了。
SUN 无心插柳，等到互联网兴起的时候, Java 正好对绘图支持非常好，在 Flash 一统江湖之前，凭借跨平台性能，以 Applet 的名义一举走红。然后，又因为这种设计先天性的能克服性能问题，在性能上大作文章，凭借 JIT 技术，充分发挥上面说到的优点2，再加上安全性，一举拿下了企业服务器市场的半壁江山，这都是后话了。
再说 PHP。PHP 的历史就包含了从第一种设计转化到第二种设计以用来优化运行时性能的历史。 PHP 是一般用来生成服务器网页的脚本语言。一个大站点上的PHP脚本, 一旦写好了，每天能访问千百万次，所以，如果全靠每次都解释，每次都递归执行，性能上是必然要打折扣的。 所以，从 1999年的 PHP4 开始， Zend 引擎就横空出世，专门管加速解释后的 PHP 脚本, 而对应的 PHP 解释引擎，就开始将 PHP 解释成字节码，以支持这种一次解释，多次运行的框架。 在此之前， PHP 和 Perl, 还有 cgi, 还算平分秋色的样子，基本上服务器上三类网页的数量都差不多，三者语法也很类似，但是到了 PHP4 出现之后，其他两个基于第一种设计方案的页面就慢慢消逝了， 全部让位给 PHP。 你读的我的这个 WordPress 博客，也是基于 PHP 技术的，底层也是 Zend 引擎的。 著名的 LAMP 里面的那个 P， 原始上也是 PHP，而这个词真的火起来，也是 99年 PHP4 出现之后的事情。
第二种设计的优点正好满足了实际需求的事情，其实不胜枚举。比如说 在 Lua 和 Tcl 等宿主语言上也都表现的淋漓尽致。像这样的小型语言，本来就是让运行时为了嵌入其他语言的，所以运行时越小越好，自然的，就走了和嵌入式系统一样的设计道路。
7. 结语
其实第二种设计也不是铁板一块，里面也有很多流派，各派有很多优缺点，也有很多细致的考量，下一节，如果不出意外，我将介绍我最喜欢的一个内容： 下一代虚拟机：寄存器还是栈。
说了这么多，最后就是一句话，有时候我们看上去觉得一种设计好像是天外飞仙，横空出世，其实其后都有现实，需求等等的诸多考量。虚拟机技术就是这样，在各种需求的引导下，逐渐的演化成了现在的样子。
[养成习惯了， 每过段时间就推荐几本读过的书]
这次回国，蒙博文视点的周筠老师安排，在敏感词日，和博文的两位编辑徐定翔，许莹，还有微软亚研院的邹欣老师一起吃次饭（还有未鹏，Tiny, Solrex, 刘江）。 当天晚上在霍炬婚礼上，邹欣老师托未鹏送给我一本他写的《移山之道》。在此要狠狠的谢谢邹欣老师。
一般我对微软开发路线上的书是不怎么感冒的，不过这本书的前言就非常吸引人，所以我拿起来就没放下，当天乘地铁的时候看，等飞机的时候看， 在飞机上也一直看。 这是一本非常引人入胜的技术书。虽然我对微软的技术和内部规约不太熟悉，但书中说的敏捷开发的那些规约和规范，还是让我深有共鸣的。
这本书最大的特点是那些有趣的小故事和对话，虽然都是杜撰，实际中原型可不少。 就像我前段时间在《读品选择标准》中说的， 这些一手的小故事，和精心提炼的对话，都是富矿，是具有非常高的挖掘价值的，各种水平的开发人员都能从这些小故事中，学到很多东西。当然我自己的团队项目开发的经验还是太少了，现在也就只对一小部分的故事有深刻同感。 对了，这本书中的漫画和人物设计也很有意思，我几乎都能在周围的人中找到了漫画人物的原型。
另一本书是最近淘到的，叫做 《China Road》, 是 NPR 中国记者 Rob Gifford 写的。 此人在中国 6 年，说一口流利的普通话。08年背起一个大背包，通过从上海，到新疆的 312 国道上的所见所闻，写成了一本书。作者认为， 312 国道就像 美国的 66 号公路一样，是中国大道，沿线风土人情最能反映当下中国的情况。书中关于天朝各处的人物，思想都有记述。我想，若干年后，此书必然成为西方记者观察天朝的经典，因为就连我这样的天朝人，看了之后都觉得作者见识思考高度深度都让人佩服。
我研究了一下，前一本书封面上的道，和后一本书每一张开头的道，是同一个字体，所以，我就把他们都叫做 “关于道的书”。 前一本书值得推荐给每一个雄心壮志实践敏捷方法的软件开发团队，后一本书推荐给对天朝未来走向感兴趣的知识青年。