易栈网-膘叔

这是javaeye上的一篇访谈翻译（摘自程序员杂志），里面有一段关于PHP的安全性的话有点意思，用该页面下面的评论来说，搞的就象几个中国哥们在聊天一样。

我是觉得他们就象在一个group里的聊天记录。啥时候我也把QQ群或者MSN群里的聊天记录整理一下，也来个啥啥啥访谈。。。

原文地址：http://www.javaeye.com/news/4143-masters-listening-to-talk-4-php-founder-rasmus-lerdorf-interview-2

原文如下：

《程序员》杂志上连载的《ＰＨＰ创始人访谈录》 的第二部分。


Chris DiBona ： PHP 这个名字代表什么？

Rasmus Lerdorf ：　PHP是 ， 恩 。 Hypertext Preprocessor ， 这名字很蠢， 就是 PHP。  Zee v 与 Andi 是97年中加入进来的， 他们当时使用 php/fi， 在用到深度嵌套中碰到了一些问题， 他们都是计算机专业的， 知道如何写解析器 ， 不像我是通过 hack 状态机这种方式来实现的 ， 我想他们看到我程序的时候，一定对它竟然能工作感到惊奇吧 。

Chris DiBona ： 呵呵，竟然可以工作

Rasmus Lerdorf ： 他们是自愿做这些工作的， 当时我有点太累了，感觉自己像是在给半个因特网写程序， 人们不是给我发补丁来修补程序，而是。。。

Leo Laporte： 这是我的程序， 把 bug 给改了吧。

Rasmus Lerdorf ： 是的 ， 改了这个 Bug,  给我写个程序做这个。 我跟他们说做实现这个很容易，只要这么做， 他们说：“ 好吧，这是最麻烦的， 那剩下那些bug呢”

Chris DiBona ：赶紧把 bug 修复了吧

Rasmus Lerdorf : 我当时的确很郁闷， 简直要把我掏空了。 当时感觉要么我就快要死了，否则我得把它移交到一个更大的 team 来做 。

Leo Laporte： 等等， 在我们继续谈论前，我觉得这是一个很有趣的话题， 这在开源社区并非罕见的情况吧。这种事情常常发生， 人们在说：“我管理不了这个社区了，我不干了，我简直要疯掉了”， chris 你肯定经历过很多这种情形， 这对于开源社区是不是个问题啊。

Chris DiBona ： 是的，实际上我跟Rasmus探讨过这个问题， 每隔五个月，就有人公开在社区挑起这种事端， “天哪，开源项目完蛋了， 有人离开社区了”。 你知道的， 其实有人进入，有人离开这是很正常的。

Leo Laporte：事实上这事最近发生在 Zend Framework 社区了

Chris DiBona ：是啊，让我们来谈谈吧，Rasmus

Rasmus Lerdorf : Zend Framework 是一个分离的项目，实话说，我也不是很清楚 ，你得问问他们，我也不清楚原因。

Chris DiBona ： 从某一方面来说，实际上对大多数社区而言，某些人悄悄地离开了这也没有什么，尽管我不愿意这么说。

Leo Laporte： 对于用户而言，我们有时候的确不太满意所用的产品。

Rasmus Lerdorf ：直到 php 3 ，实际上只有我一个人在做，当某人给我发了个 php 的补丁，我一定会重新写一遍，因为这是我的产品

Leo Laporte： 看来你不擅长移交工作。

Rasmus Lerdorf ：我也不清楚开源的理论，当时也没什么开源的东西，我自己也是后来才想清楚了这些。没过多久，我在多伦多大学找了份工作， 建立一个对话访问系统。我想那大概是 97 年吧，哦，是 96年，偶尔我还能收到一些关于 php 的补丁，有些 bug 是我从来没碰到过的， 我碰到些困难， 有个在日本的程序员给我发了一些补丁，非常酷， 还有有一些在日本的朋友帮我做了咨询方面的工作，但是这并不是经常性的。 一年之后我想通了 ， 我的确需要鼓励这种贡献，人们提交了 patch， 我不能接管然后自己再重写， 我应该接收它， 放弃控制。给他人以权力随心所欲的做自己想做的事情。对于大多数开源的开发者来说，这很难，即便在现在，开源项目是他们孩子， 他们应该控制它，但是对于长期发展来说， 你应该放手， 让其他贡献者做他们要做的事情 ， 你不能做太多限制。

Leo Laporte： 看来，我们作为用户应该更激进一些，呵呵

Rasmus Lerdorf ： 这没关系， 你应该意识到这点，这些人大部分也都是在家里做开源开发的，百分之九十的开源开发者不管他们是做什么。他们把孩子哄上床，为开源项目贡献出两个小时，然后 他们打开自己的邮件，发现一大堆愤怒的信息，全都是"这里有 Bug, 另外这里还有 Bug， 这个 bug 使得我们上百万的电子商务操作无法进行" ， 但他们只能说：“好吧，我已经在晚上贡献了2个小时， 这确实不是我应该太过在乎的事情（你的上百万电子商务程序）"。 所以说，人们对这些开源项目的开发者应该给予一些尊重。

Leo Laporte： 开源是如此繁荣，我想说你们这些人才是开源社区的源动力，我们所能做的就是给予你们以应得的尊重。

Chris DiBona ： 恩， 我发现 Rasmus 的车子有点脏了,呵呵

Leo Laporte： 呵呵,我愿意为他擦洗车子，我欠他的太多了，我在服务器上运行了那么的 php 程序 ，从日志跟踪程序到 drupal .

Rasmus Lerdorf : 你不欠我什么，不欠我任何东西，我们 php 项目现在有 1100个开发人员。

Chris DiBona ： 看来你现在已经把移交工作做的很好了

--------------------------------------------------------------------------------------------

Leo Laporte：  1100 个开发者可不是个小数目啊。

Rasmus Lerdorf ：是的, 如果你修复了 PHP 项目的一个bug, 发来一个不错的补丁, 那么PHP 社区就非常欢迎你的到来。

Leo Laporte：  我知道Perl 社区老早就说起开发 Perl 6 了, 不知道 PHP 6 的号角是否已经吹响.

Rasmus Lerdorf ：我们不太善于做市场方面的工作, 但是 PHP 6 工作的确正在进行了.

Leo Laporte：  跟我们讲点这方面的事情吧

Rasmus Lerdorf ：PHP 6 最大的一部分改进在于对 Unicode 的支持. PHP 6 任何一部分代码都是基于 utf16 编码的.

Leo Laporte：  这大概是 PHP 6 大部分被重写的地方之一吧.

Rasmus Lerdorf ：是的, Unicode 很艰深, 我跟 200 多名懂得 unicode 的开发者开过一个会, 其中包括一些日本的开发人员,他们工作于 IBM 公司, 知道很多 ICU 项目的东西. ICU 是 IBM 的 Unicode 项目, 当时 ICU 项目并不是很好, 它太大了. 它的代码比 PHP 的源码还大, 差不多有10倍了吧.

Leo Laporte：  等等, 你说什么, ICU 项目的代码量是 PHP 的10倍

Rasmus Lerdorf ：它太庞大了, 太让人吃惊了, 而且它不是模块化的, 这意味着你无法从中取出你所需要的部分. 但是现在 ICU 也发展了, 我们可以取出我们需要的部分, 所以如今在 PHP 项目中加入 ICU 支持是可行的, 这使得 PHP 可以在任何地方完全支持 Unicode , 这是 Php 6 最大的改动, 此外的改进还有“命名空间”等其它特点.

Chris DiBona ：那其它的库是否也要因此重写以支持 unicode 呢?

Rasmus Lerdorf ：你说的是库和扩展吧, 有一些函数是要重写的, 基本上涉及到传递字符串或者操作字符串的函数都需要重新审核一下, 是的,这是很大的工作量. 大概在年底会有一个alpha 的测试版发行, 这个版本只是说: 大家看看,测试一下, 看看你现有的代码中有多少因为采用这个版本而无法运行, 估计大多数 Php 5 的代码都不会有什么问题, 我们并不担心, 或许你马上就可以利用它实现一些 unicode 的有趣功能. 如果你正确使用它, 熟悉这个版本的过程中就不会有太多的麻烦, 不过也有可能出现一些我们没考虑到的问题, 所以我们希望尽早发布测试, 而不是像某些语言一下等上5年.

Leo Laporte：  我在自己的服务器上运行的是 php4, 顺便说一句, 非常感谢你们的工作, 开发了这么好的产品. 像很多人一样, 我使用的是 Php 4

Rasmus Lerdorf ：恩, 它的确工作的很好, 如果你没什么必要的话, 也可以不升级...

Chris DiBona ：火是很可怕的( 注解: 5(five) 和 fire 英文发音相同)

Leo Laporte：  哈哈, 是的, 我并不怕火, 呵呵, 我只是不想换版本, 因为它现在工作良好, 是吧?

Rasmus Lerdorf ：是不应该害怕升级的, 直到我们认为完全可以抛弃这个版本之前, 我们将继续提供 php 4 的安全补丁. 对于大多数产品来说, 在 php 4 上良好运行的程序都应该在 php5 上运行. 最困难的是那些大型的 ISP, 它们有成百的用户, 上千个运行的 PHP 程序, 其中若是有几个程序无法运行, 这对他们来说,的确很可怕, 如果没人抱怨升级的问题, 的确没这个必要冒险去升级版本. 但是 PHP 5 的确有一些很吸引人的功能, 比如简单 XML 处理支持, Soap 扩展, 相当快的 Soap 处理, 如果你程序中要处理 Web 服务, 需要解析大量 XML  那么用 PHP 4 来处理就相当痛苦了, 这是我们分支出 PHP 5 版本的主要关注点.

Leo Laporte：  好吧, 为了支持 PHP 5 我要去重新编译我的 Apache 了, 你们两个继续谈.

Chris DiBona ：好啊, 待会见.

Leo Laporte：  Twit.tv 服务器宕机了, 我一会再来.

Chris DiBona ：你可以给 Rasmus 写邮件.

Leo Laporte：  你能给我写代码吗?  Rasmus

Chris DiBona ：奇怪， Drupal 好像运行 Php 5 没什么问题?

Leo Laporte：  我也不知道为什么我要运行 php4, 好像Drupal 最新版本 5.1.4 重新编译支持 php5 , 如果没有什么特别的原因, 是否应该将程序运行从 PHP 4 转到 PHP 5 呢?

Rasmus Lerdorf ：恩 ...

Chris DiBona ：会运行更快一些吗?

Rasmus Lerdorf ：也许不会那么快吧, 有一些程序会运行的很快, 有一些程序的运行速度和原来差不多, 这取决于你的代码做什么, 如果你的代码恰巧使用了我们做大量工作优化的部分, 那么速度就会很快, 否则就和原来速度差不多.

Leo Laporte：  让我们来谈谈人们常常说的 PHP 的一些问题吧, 有一些人经常抱怨 PHP 的性能问题, 我从来没碰到这些困扰, PHP 的扩展性很好.

Rasmus Lerdorf ：你混淆了两个概念, 性能和扩展性没有什么联系。

Leo Laporte：  是吗? 让我们来谈谈这个.

Rasmus Lerdorf ：是的, 性能是单一服务器对单一请求的服务有多快; 而扩展性是指你能扩展的宽度, 比如, 如果你有10万个并发访问, 你如何能将它控制在一定的响应时间之下.

Leo Laporte：  我想两者都很重要,但是扩展性更重要一些

Rasmus Lerdorf ：是的, 但是从某方面说, 性能也很重要, 你可以更换一个更快的CPU, 但是无法并排放大量的服务器, 如果单一请求的响应延迟是半秒钟, 那么并排放500个服务器, 除非你有大量的访问请求, 否则每个请求的响应时间还是半秒钟. 性能问题跟响应延迟有关, 你可以在单一服务器上服务于更多的请求, 扩展性则更多与架构有关, 你要确定你所做的不要和某个服务器紧密绑定, 我们在 PHP 中做的很多事情都有这么一个概念叫做"share nothing"的架构(不共享任何东西), 就像一个 "PHP 黑箱", 你接受一个php 请求, 然后处理该请求, 任何关于这个请求的东西都在这个请求结束后消失, 没有什么东西可以跨越请求存在的, 你要建立一个这样的系统, 每个请求都是相互独立存在的, 因为每个请求可能来自不同的服务器, 你可能在一个负载均衡程序的后面放了 500 个服务器, 那么程序也能将照常运行. PHP 的 Session 机制默认是保存在本地的 tmp 目录中的, 但是我们提供了一个很简单的机制将 session 保存在数据库中, 所以我们在 php 中做的任何事情都保证它是可扩展的, 这也是为什么yahoo 和 flick 的程序员采用 php 的原因. 因为扩展性是内建在 php 之中的. 有人说 php 是不可扩展的, 是因为他们不了解如何去实现扩展性. 就我而言, 我们没有碰到任何扩展性的问题, 所以你可能看不到我们关于扩展性方面讨论的文章. 但你不能说, PHP 不可扩展仅仅因为我们没有讨论它的可扩展性问题

Leo Laporte：  哈哈

Rasmus Lerdorf ：有时候这真让人头疼. 恩, 关于性能的问题, 你能做的事情不多, PHP 像大多数脚本语言一样, 分为两步访问. 首先是将磁盘上的文本编译为 op-code  , 然后将  op-code  传递给执行程序, 这有点像 Java 的字节码. 我们可以把  op-code  放到缓存中, 比如我们已经用了多年的 APC , 还有其它一些产品. 它们将编译好的  op-code  放到共享内存中, 如果第二次请求 php 脚本的时候, 我们将看到, 嗨, 检查一下共享内存,  这是 inode , 我们的共享内存中是否有这个缓存过这个 inode 块, 如果有的话, 我们可以直接执行共享内存的  op-code , 这将会使得代码提速达30至40 倍之多.

Leo Laporte：  这有点类似 python 的 pyc 字节码, 只是你没有在磁盘上保存编译的版本

Rasmus Lerdorf ：是的, 因为性能最慢的地方就是读取磁盘.

Leo Laporte：  这并不能节省多少时间, 是吧?

Rasmus Lerdorf ：是节省不了多少,   op-code 本身就是很小的文件, 500 字节和1000 字节在文件系统中可能都是占用一个块, 你从大小上节省不了什么. 相反你应该避免这种磁盘操作, 任何这类操作都是挺耗费时间的. 不经过任何拷贝操作, 直接从共享内存中执行代码是最快的. 如果我们修改了磁盘上的代码, 我们需要告诉 APC , 可能需要重新启动 web 服务器.

Leo Laporte：  这么说系统需要足够的内存以运行程序了

Rasmus Lerdorf ：所有高性能的网站都会用到缓存的

Leo Laporte：  这么说我们将为运行 PHP 投入更多的内存了.

Chris DiBona ：那么 Zend 提供了些什么, 更好的解析器? 他们确实在销售一些性能优化的产品.

Leo Laporte：  他们也有一些缓存的产品吧

Rasmus Lerdorf ：一样的, 他们本身也没有  op-code   缓存, 他们也提供这方面的缓存产品， 你可以选择.

Leo Laporte：  你有自己喜欢的缓存产品吗?

Rasmus Lerdorf ：我比较喜欢的是 APC , 不是我创建的它, 别人创建的, 我只是帮着他们让其良好运行. 我需要一个缓存得以开始这方面的工作.

Leo Laporte：  习惯上, 如果你运行一个访问量比较大的网站, 通常都会要用到一个缓存系统.

Rasmus Lerdorf ：是的,你应该有一个, 你可以从 Zend 公司购买, 或者试一试开源的缓存系统.

Chris DiBona ：APC  是什么意思?

Rasmus Lerdorf ：Alternative PHP　Cache,  PHP 是开源语言, 所以我们需要一个开源的缓存系统, APC 运行的很好.

Leo Laporte：  不错, 我要在我的服务器上实验一下. 谈谈 PHP 的安全性吧, 你对安全性考虑的有多少?

Rasmus Lerdorf ：这么多年有很多讨论 PHP 安全性的问题, 我觉得有一些是正常的, 大多数批评对 PHP 是很不公平.

Leo Laporte：  有很多不好的实现

Rasmus Lerdorf ：的确有很多很烂的代码, 我们无法把他们都修复了, 有一些错误的确是我们的问题, 我们的程序确实有 bug , 我们会尽量正确地修复它. 但是还有很多是我们无论如何都无法解决的. PHP 比别的语言跟容易出现这种问题, 因为它比其它语言更容易学习, 也就是说越是缺少编程经验的人越容易采用 PHP , 有一些代码的确写的不那么安全, 结构也不好. 而且 PHP 项目的命名也是个问题, 人们总喜欢用 PHP 来命名自己的项目.

Leo Laporte：  是啊, 宝贝, 这可是用PHP写的. 不用其它名字来命名项目了.

Rasmus Lerdorf ：呵呵, 我也不知道为什么我们会有这个问题,  别人就不会起 Python Mailman  这样的名字. 其它语言开发的项目不会起名为 Perl XXX, Python XXX, Ruby XXX , 当然 Ruby on rails 是个例外. 你看, 这么多项目都以 PHP 命名, 他们似乎都想打上 PHP 的标签.

Leo Laporte：  Php Myadmin 也是其中之一, 有很多这种方式命名的项目

Rasmus Lerdorf ：任何一个关于这些项目的 bug 都会归到 PHP 头上, 如果 Mailman 出现了安全性的问题, 你的第一反应不是 Python 出了什么安全性问题, 至少通过名字关联不会这么想, 你最多只是说:"Mailman 这程序太蠢了", 如果 PHP 的项目出了问题, 他们就会说:"PHP 又出问题了, 这个语言的确不安全, 看看这些问题吧"

Leo Laporte： 你有什么类似 perl 的一些措施限制程序员去做正确的编程吗？

Rasmus Lerdorf ： 我们有很多级别的错误报告机制， 你可以打开开关，如果你访问一些未赋值的变量， 就会出现警告等等。

Leo Laporte： 你在 yahoo 工作

Rasmus Lerdorf ：  是的

Leo Laporte： 它们用了很多 php 代码,  你可以说说他们都是在什么地方采用 php 开发的。

Rasmus Lerdorf ：  几乎所有 yahoo 网站都采用了吧

Leo Laporte： 是吗？ 这倒是可以作为 php 扩展性的一个好的典范， 任何人说 php 扩展性不好的，都可以去看看 yahoo . yahoo 的邮件系统也是用 php 写的吧

Rasmus Lerdorf ： 老版本的邮件系统不是基于 php 的。

Leo Laporte： apple 的网站是基于 php 的吗？

Rasmus Lerdorf ： 说实在的，我也不知道。

Leo Laporte：它们大部分都是基于 javascript

Rasmus Lerdorf ：  apple 的网站很多都是基于客户端的技术，我不知道它们有什么地方用到了服务端的技术， 客户端也不是我所关注的技术。

Leo Laporte：我非常喜欢 Yahoo 的邮件系统， 它可是 ajax 技术运用的一个良好示范啊。太感谢你了，Rasmus，给我们提供了这么好的语言， 可以做许多强大的事情。

Chris DiBona ：非常方便

Leo Laporte： 1100 名开发人员， php 社区可真是强大啊， 真让人惊奇。

Chris DiBona ： Pretty Handy Processor （Chris 开玩笑解释 PHP 命名)

Leo Laporte： 哈哈，你又来了， 不过这个解释我喜欢

Rasmus Lerdorf ： 大概是人们讨厌 Perl 吧。

Leo Laporte： 哈哈， 这个理由我接受。

Rasmus Lerdorf ： 对不起，对不起，Larry ( Larry 是 Perl 语言的创始人）

Leo Laporte： 我们确实想采访一下 Larry 。

《程序员》杂志的一位作者袁泳先 生，曾经说过高德纳是一位文艺复兴时期式的天才人物，这说的是他的博学，以及他同时具备的灵巧的编程能力。在分工越来越细致的现代社会，这确实非常罕见， 就像一个人自己制造一架飞机，他既要考虑空气动力学问题，也要考虑飞机上的每棵螺丝钉的固定方式。也确实使我们想到达芬奇，后者创造了享誉后世的《蒙娜丽 莎》，《计算机编程艺术》在计算机领域的影响可以与之媲美，同时也是机器设计方面的专家。从计算机科学史上说，高德纳正是生逢其时。1936年，图灵发表了《论可计算数及其在判定问题上的应用》一文，确立了可计算模型。1953年，巴克斯发明了Fortran语言。从1960年 代起，高德纳以他的博识与耐心开始了《计算机编程艺术》的写作，该书旨在对计算机科学理论的数学背景与历史，做一梳理和总结。现在大学计算机系的《数据结 构》课程的内容基本来自该书。有人更是把它与牛顿的《自然哲学和数学原理》并列，选为对世界历史发生影响的十大科学著作，这不无理由。高德纳本人在36岁时，获得了计算机科学的最高荣誉---图灵奖。从1993年起，他主要专心致力于完成七卷本的《计算机编程艺术》一书。几个星期以前，我们采访了他。使我们特感幸运与欣悦的是，高德纳先 生对我们的采访表现出极大的热诚，在繁忙工作中抽出宝贵时间，细致地回答了我们的问题，并在通信中特别强调希望用他的中文名字。从这里，不难看出他对中国 和中国文化的热爱。这在采访的本文中也有所体现。当我们谈到最早的算法时，他特别提到《九章算术》，这本即使中国人也很少读过的书。或者我们可以将此看作 一种激励，正如高德纳在采访中所说，计算机科学的思想来自世界各个地域、各种文明。可以期待，今天的中国也会产生如刘徽、秦九韶那样的数学高手，对计算机 科学与技术做出独特的贡献。以下是采访的本文:

本刊记者：什么是最早的算法？

高德纳：我想，第一个“真正的”算法可以追溯到大约4000年前，它们以楔型文字记载在粘土板上。我在文章“史前巴比伦算法”中对此有过讨论（我将其翻译为现代注记方式），这篇文章也重印为我的书《计算机科学论文精选》的第十一章。

当然，这些早期的算法并不是很精巧。它们解释了如何以计算的方式解决这些问题，但后来发现使用代数方法能更好地解决它们。最早的“有意义的”算法,它对于今天的程序员们仍然很重要,是最大公约数的求解。其中一个算法被称为欧几里德算法，它被记载于欧几里德几何原本上,尽管它来自于欧多克索斯和其它一些更早期的人物。这种算法基于辗转相除法。另一个算法仅需要除以二，因此非常适合当前的二进制计算机。这个算法可能发源于2000年前的中国——这要取决于我们如何理解经典的《九章算术》中一些句子的隐藏的含义（我在我的书《半数值算法》的340到341页和中文版的309页讨论了这个问题）。

本刊记者：奥运会今年夏天在中国举行，这是对于中国来说是一件很重要的事情，因为它有一些特殊的含义，也许是一个符号，表示中国人能像接受希腊火炬一样接受西方文化。希腊先哲毕达哥拉斯说过“我喜欢作为奥运会的观众胜过成为一个运动员或商人”。现在很多中国人也成为了奥运会观众，我来问个问题：为什么希腊人发现的数学对于人类文明（包括计算机科学）如此重要？

高德纳： 希腊数学家发明的最伟大的东西是严格证明的概念。这个概念将数学与其它知识区别开来，其它知识往往是基于事实的累计、由老师传授给学生的并由社会共识所评 估（举个例子，物理中，并不知道一个假设的真假，而只能等着所谓专家们的想法越来越趋于统一。但是在数学中，很多事情都是无可辩驳的，或者说不存在不同的 观点），纵观人类历史，那些没有遵从希腊方式理解数学的文明把数学认为是应该记忆的规则而不是可以由逻辑推演而来的事实。在这些文明（例如古代中国、日 本、印度和哥伦布发现之前的美洲等）中，人们发现了很多重要的数学原理但是也犯了很多错误，因为学生否决老师是不明智的！这也是为什么我如此感激史前的希 腊数学家教会其他人如何真正的证明问题。

另一方面，我希望澄清一点，我相信所有文明之间都是相互学习的。我为计算机科学这个全世界成千上万的人的共同成果而庆祝，每个人都为此贡献了他们从经验中而来的重要观点。

本刊记者：如何看待数学和计算机科学之间的关系，特别是数学和算法学习之间的关系？

高德纳：你可以参照我对第二个问题的回答，我认为数学对于程序员最重要的意义在于它告诉我们如何证明我们的程序将会在所有情况下正常工作。若非如此，我们就得为此担心，尽管我们的程序通过了已有的所有测试，但或许明天它在处理另外一些新数据时就会出错。

当然，仅仅知道程序能正常工作这一点并不够。有了数学，我们可以证明一个程序比另一个程序快成千上万倍。某些时候，我们甚至能证明程序是“最好的”（best possible）——根据某些标准，没有其它程序会比它好。

本刊记者：这个问题是关于您的书《计算机编程艺术（The Art of Computer Programming）》，写这本书的主要目的是什么呢？您是否试图构建一个算法体系？您是如何选择主题呢？

高德纳：我写《计算机编程艺术》的主要目地是组织和理解一些广泛被各种程序使用的最基础的想法。只要可能，我使用数学给出对于每种基础的方法的对于精 确效率的计量的理解。此外，我尽量叙述每一种方法的历史，因为理解这些方法是如何被发现的有助于我们在现时和今后发明新的方法。

但是，书的主题是1962年 选定的，这时计算机科学还没发展到一个作者无法掌握的规模。因此，没有像操作系统、并行处理、分布式处理之类的资料。此外，我更多地使用整数而不是浮点 数。我把高级数学主题，例如数值分析、计算几何留给别人讨论。我关注的是程序员与机器间的低层次接口，为支持高级应用程序而用于构建库和工具的基础的子程 序。然而，尽管将主题列表做了如此多限制，我这个关于计算科学的一小部分仍旧是一个如此巨大的主题，我需要为剩下的内容工作20年！所以，我希望一直保持健康。

本刊记者：我的很多朋友都尝试过阅读《计算机编程艺术》，但是他们发现这非常困难。我听说一个小说家——詹姆斯乔伊斯（James Joyce），《尤利西斯》（Ulysses）的作者——有人为他的小说写了本书，名字叫《乔伊斯小说指导》，我不知道有没有针对《计算机编程艺术》的类似书籍，比如 《计算机编程导论阅读指导》。您能给《计算机编程艺术》的读者一些建议吗？

高德纳：《计算机编程艺术》不是为所有人写的。大约每50个人中就有一个能发展出独特的看问题的方式，这使他们成为真正的程序员。像你我这样的人，倾向于将知识用特殊的形式在脑中组织以便于更好地利用电脑。每50人中的另外49人不该从事编程这一行，尽管他们可以使用计算机完成一些不需要编程的任务。

对程序员来说，拥有非程序员的朋友是非常重要的，所以对于你所说的你有朋友阅读《计算机编程艺术》非常困难，我并不觉得奇怪。当然，你的朋友也许不应该阅读你看过的所有书籍，你也不应期待能轻易看懂他们的书籍！最好的方法是团队合作，用天分和技巧作为补充。

本刊记者：您认为对最近一些年来说，计算机科学最需要解决的问题是什么?

高德纳：我在所有地方都看到很大的发展的潜能。所以，从这些同样精彩的候选者中我无法选择。机器人、加密、制图（mapping）、动态规划、大量文本或大量DNA序列的搜索等等，都亟待提高。

总 的来说，我认为我期待的主要进步来自于程序员和非程序员的合作。比如，人类能更好地理解动作。我相信很多针对医生、化学家、物理学家、生物学家等的将数据 以动画形式表现出来的工具应该被开发出来。要实现它们，需要优秀的程序员实现动画，与能够理解人类视觉能力的优秀的图形设计师一起工作，与知道哪些数据需 要被理解的优秀的医生、化学家、物理学家和生物学家一起工作。

本刊记者：我听说狄克斯特拉（Edsger W. Dijkstra）曾经试图解决这样的问题：什么是正确的程序？所谓的形式证明？现在在软件工业中，我们主要依靠测试而编写正确的程序。有没有可能在理论上找到一种方法让我们知道程序是否正确，尤其是对大规模的程序？

高德纳：在我回答第二个问题的时候，我提到使用数学去证明（不是重复地测试直到你找不到错误）的重要性。狄克斯特拉和其他人都发展了验证正确性方法，这些方法可以放大,以验证“大”程序。但是，如你指出的，软件工业界并没有真正遵从他们的建议。部分的问题在于——“大”的含义一直在变：当我们有一个可以工作的大程序，人们常常就想写一个更大的，这也就更加难以验证。验证技术从没有跟上人们对于代码体积越来越大的胃口。

我将会试着同时从理论和实践上解释我的态度。拿我的程序TeX做例子，它按照今天的标准来说并不“大”，它只有500页的代码。我并没有完成对于TeX完全的形式化的正确性证明，尽管我非常喜欢数学证明。但是，我已经非常熟悉验证的基础，我知道如何非形式化地使用它们——大体上我知道如何证明正确性，如果我有时间去研究每一个琐碎的细节（grind through the gory details）。

没有这些基础知识，我的程序可能会经常崩溃，像你我知道的一些商业软件一样。有了这些知识，我就能写出非常稳定和好用程序，但也仅是在我测试了它之后！

让我从另一个不同角度再说一遍：没有理论，我不知道程序可被证明的正确是什么意思，我挣扎前进（flounder）。但是尽管有了理论，我也不能确定我的程序是好的，除非我进行了广泛的测试！

为什么？因为在现实中，没有程序能被真正被证明是正确的：假定的“证明”可能包含错误。如果某人给我看一个经过形式化证明的程序，我不得不检查一下验证过程有没有错误。验证过程也许由机器完成，但是机器逻辑也许是错误的，如此这般。这是一个永无终点的循环。

数学展示给我们理想，我们可以检查证明，直到我们认为它们是合理的。但是只有不会犯错的超人能真正得出证明是正确的结论。

进一步来说，证明程序是否满足它的规格说明（specification）的想法也是值得怀疑的，因为规格说明本身可能是不正确的。实际上TeX并没有精确的规格说明，如果有，我也认为它完全没有用处！（不是每个人同意我这个观点，但他们应该设计并实现一个完美排版软件，在我已完成了TeX这个排版软件的时候。）

总之，我认为将“形式证明”和“测试”分裂开来是危险的。最好的做法是正确地同时使用两种方法。我在我的著作《Literal Programming》的第十章和第十一章详细地讨论了TeX的调试（在《Digital Typography》的第三十四章中讨论了后续开发）。

本刊记者：我们的杂志名字叫《程序员》，所以我的最后一个问题是：什么是程序员，您如何看待程序员？

高德纳：程序员选取一个抽象的算法，并将其转化为以某种定义良好的语言写成的程序中的具体形式，程序才可以被机器执行。

“算法”之于“程序”就类似于“信息”之于“数据”： 信息是理想化的抽象的概念，它或多或少可以由某种精确的方法将其编码为数据，以完美地表达。一个算法是一种理想化的可计算的为某些任务服务的过程，它或多 或少可以由某种精确的方法将其编码为程序，以完美地表达。但是程序员事实上不仅仅是写程序的人。真正的任务是编写可以被人们阅读的程序，而不仅仅是编写可 以被机器分析的程序，因为人们会需要验证它（非形式化的）、修改它和维护它。这就是为什么我坚信“作文式程序设计（literate  programming）”——像文学创作那样写程序，写出自己的风格，为他人所欣赏。
原文：http://blog.csdn.net/programmer_editor/archive/2008/12/11/3501111.aspx