Feb 2, 2012 - 编程珠玑番外篇 -M. 软件工具的设计哲学1

Comments

我们通过工具的设计者和使用者的视角观察工具,讨论工具背后的设计哲学和对应的学习曲线。

设计者和使用者

从某种意义上来说,工具是个联系使用者和设计者的桥梁。工具的设计者为解决一类问题而设计工具,工具的使用者也是为了解决一类问题而使用工具的。这两者对于工具都有自己的理解。工具的设计者通常会预测此工具会被用来解决怎样的问题,在设计工具时预见使用者的偏好,而工具的使用者则根据所面临的问题选择合适的工具。

在理想情况下,设计者和使用者对问题的理解 (Vision) 是类似或者重叠的。这时候,工具的设计者能够完全理解使用者的需求,而使用者完全理解这个工具的长处和短处。成语“得心应手”说的就是这样的一种情况:掌握了一样工具,因此使用起来非常顺利。

在现实中,设计者和使用者对问题的理解可能是有差异的,随之对工具的使用方法的理解也有所不同。有时候,工具的使用者能够将工具用到远超出设计者想象的地步。有两个著名的例子可以说明这个问题。第一个例子是出自 Bell 实验室的 AWK 语言。从 AWK 的三位作者的角度看,这是一个与 sed 互补的,处理文本记录的语言。而AWK在贝尔实验室内部推广开来后,三位作者发现其他团队用 AWK 来写作大的数据管理系统,而三位作者本人从来没有写过超过一百行的 AWK 脚本。第二个例子是 C++ 的模版 (template)。模版的设计者的初衷是让 C++ 在处理对象时更加灵活,而自从C++模版的图灵完全特性被发现后,写作一些通用的库成为可能。如C++的Boost库,即重度依赖于模版。设计模版的人未必想到 Boost 库那样对模版的奇妙运用。这两个例子,都充分说明了工具的设计者未必能够充分体验到自己设计的工具的强大之处。

另一种情况是工具的设计者是解决问题的专家,对问题有深刻的理解,而工具的使用者则没有能够完全体验到工具的强大。工具的使用者因此需要学习如何使用工具,学会像工具的设计者那样思考,从而领略到工具的强大之处,达到得心应手的地步。对于完成学校教育后的成人来说,大多数学习都是在学习工具的使用。那么,如何学习软件工具呢?

在我看来,虽然工具千差万别,学习工具的用法也大相径庭,不过如果细细总结,工具的设计者所奉行的套路无非就两种,所对应的学习方法也有两种。我把这两种设计讨论形象地称为瑞士军刀工具链。这两种设计哲学背后的假设,以及相应的学习曲线是不同的。

设计者的哲学一:瑞士军刀

瑞士军刀以方便著称,一把军刀包含了很多小部件,配合使用能够解决很多野外生存问题。不少计算机工具借用了这个类比。在Google 上搜索 “The swiss army knife of” 会发现很多软件工具号称某领域的瑞士军刀(见表一)

工具名称 用途领域 广告词
BusyBox 嵌入式 Linux 命令集 The Swiss Army Knife of Embedded Linux
Perian Apple QuickTime 组件管理 Perian – The swiss-army knife of QuickTime® components
Sox 音频文件编辑 The Swiss Army knife of sound processing programs
Netcat TCP/IP 数据包分析 TCP/IP Swiss Army Knife
FFMpeg 视频和视频流文件编/解码 The swiss army knife of Internet Streaming
Kanif 计算机集群管理 Cluster management and administration Swiss Army knife

从表一我们不难发现,这些宣称为“瑞士军刀”的工具有一个共同特点:都是针对某个特定领域的问题而设计的。这一点和瑞士军刀是相似的。瑞士军刀的多功能,并不是指这是一把砍树修桥盖房子的万能刀,而是说在野外生存这个领域内,军刀能够解决许多问题。回到表一,用过这些工具的读者一定有所体会:这些工具解决所在领域的复杂问题的能力是非常强的。比如,FFMpeg 内置多种视频编、解码器,众多格式能够相互转换,支持的视频编码格式比任何商业软件都要多。这些优势让 FFMpeg 几乎能解决所有现实中遇到的视频处理问题。因为这些工具针对特殊领域,且功能强大,用瑞士军刀做比喻是很形象的。

除了自称为“军刀”的这些工具外,还有许多耳熟能详的工具属于此类。如平面设计软件 Photoshop,是融许多复杂图像算法和插件于一体的图像处理之瑞士军刀;GNU 的 GCC 编译器,是集语法分析,代码优化,代码生成等功能于一体的专门负责程序编译的瑞士军刀。这些软件包的内部结构,都不是一个单一的程序,单一的部件,而是一揽子的部件,一箩筐的功能模块。

瑞士军刀巧妙地将众多小工具紧凑地组合到了一起。同样,我们说的军刀工具的一大优雅之处也是类似的,即通过一个统一的控制界面,将这一揽子的部件有机地组合在了一起。设计模式里,这种组织功能的方式称作为 Facade 模式,具体指以一个命令或者一个统一的界面抽象内部复杂的操作。如 FFMpeg 和 GCC 这样几乎无所不能的软件包,都可以通过一个单一的命令 (ffmpeg 或 gcc) 加不同的参数调用。在 GUI 程序的世界,所有的 Photoshop 插件都可以通过 Photoshop 的图形界面菜单调用。Facade 模式隔开了用户和“军刀”工具复杂的内部逻辑,让用户从一个”抽象”的层面理解工具。正如我们开车并不一定要了解引擎是怎么工作一样,工具的使用者不需要关系这些工具的内部是如何运转的。

总结这类工具的特点,瑞士军刀是一种把各种工具组合到一起,一起解决一个复杂问题的设计哲学。核心是。设计模式里的facet 模式,一个领域的问题,而不是一个特定的工具。这里实际上是一类工具,而非一个单独的工具。这一类工具被精巧地安排在一起,对外提供一个一致的服务接口,让用户以简单的控制方式完成相对复杂的任务。

领域知识假设和学习曲线

“瑞士军刀“工具都是面向特定领域的。无论是图片,视频处理,还是查看TCP包信息,这些工具都假设了使用者知道图片处理,视频处理或者TCP包的结构等知识。心理学上把这些为了解决特定领域问题而所需的知识叫做”领域模型“(domain model)。工具的设计者是不负责教授这些知识的。因此,作为工具的使用者,掌握这些特定领域的知识就成了使用工具的前提。一般的软件都是基于领域模型的。比如,平面图形处理工具 Photoshop 假设图片是个多层次的物体,如果我们不了解这个模型,就完全不知道为啥这个软件为啥比系统自带的 Paint 复杂几千倍。

因为军刀背后蕴含着领域知识假设,学习军刀工具就不仅仅是学习工具的使用本身,而是学习背后的领域知识。如果不了解背后的领域知识,即使我们会操作这样工具,依然谈不上是个熟练的使用者。相信诸位读者都属于“懂计算机”的一类人。现实中,我们这类人常常因为“懂计算机”,而被家人和朋友要求编辑图像,做个视频或者做个网页等等。有些要求还特别专业,让只会写程序的人非常吃力。究其原因,是因为程序员群体掌握的,只是编程的领域知识。如图像,视频处理所需要的领域知识,均是编程之外的了。即使像 Eclipse 这样专门给程序员用的软件,也隐含假设了使用者需要重构,设计模式等等的知识。不掌握这些知识的程序员用 Eclipse 也仅仅是将其当成一个花哨的编辑器使用而已。

因为需要领域知识做铺垫,军刀工具的学习曲线是因人而异的。对于有的人来说,如果本来就知道工具背后的假设,学习计算机操作就毫不费力。以我爸爸为例,本身用计算机并不熟练,但他学过画画,作图感一流,若干年前从书店随便买了一本 Photoshop 入门后就把 Photoshop 玩得很熟。而我知道这个软件每个选项的意义,却处理不出什么像样的图。对于我爸来说,他的学习曲线就很平缓,而对于我来说,就很陡峭。

学习曲线不一样这一点在计算机语言的学习上尤为明显(计算机语言是众多编程特性的大糅合,是典型的军刀设计)。像 Google 这样的公司面试时完全不考察语言细节,很多人入职的时候都不会 Java。因为我们相信任何合格的程序员都能很快学会 Java 这个语言。道理很简单,只要考察一个人掌握了Java 语言背后的领域知识,即面向对象的设计,数据结构,控制结构等等,就有充分理由相信这个人学 Java 毫不费力。但是,话说回来,每个语言背后的领域假设都有细微的差别。比如 Lua 只支持哈希表,Awk 支持哈希表也支持记录处理,Vim 里一切都是文本对象等等。真的领会这些领域模型并且将这些语言用得纯熟,没有长时间的投入是不可能的,这就是为何 Peter Norvig 强调“十年学会程序设计”。这两种对待编程语言的态度是不矛盾的。引申出来,对于语言或者工具的初学者来说,要分情况学习军刀工具。在不熟悉领域知识的情况下,应该找一本非常简单的书熟悉领域模型,获得一个 Big picture,而非上来就想着要解决手头的问题。而对于已经熟悉领域模型的人,比如会了一个 MVC 框架再学另一个的人,随便捡起一本 In Action 或者 Cookbook 也能事半功倍;有人甚至书都不需要买,看看文档就可以了。不清楚内情的可能会把这类人叫做强人,其实了解了背后的底细后,所有人都可以如此。

最后谈一下军刀工具的设计策略。我们说了,军刀工具背后蕴含的是领域知识。因此,设计军刀工具的人,必然需要是对问题有深刻理解的领域专家。这一点很好理解,因为很难想象一个不懂图像处理的人会指导 Photoshop 的设计,或者一个不懂统计的人会设计 R。不过,即使是最资深的专家,也未必能设计出一个能覆盖到所有问题的工具。这时候,工具的扩展性就成了一个重要的考量。可以这么说,几乎所有成熟的军刀工具,最后一定会进化出一个插件系统,用以扩展功能。插件系统的好与坏是考验设计者功力的时候。像 Firefox 和 Photoshop 这样的工具,若不是第三方插件,至多是一个普通的软件。加入插件系统后,这些工具成为了一个平台,从而衍生出了无数的新用例。即使像功能小巧和 Emacs 格格不入的 Vim, 最终也进化出了插件系统。这是一样工具成熟的体现。

总结一下军刀工具的特点如下:

  •  面向特定领域,覆盖该领域大部分问题
  • 由领域专家设计,使用者需要了解该领域的基本知识才能熟练运用工具
  • 内部由众多小模块组成,对外提供一致,简单的控制界面
  • 常常具有强大的插件系统,以方便用户扩展现有系统

Nov 24, 2011 - 编程珠玑番外篇 -L. Plan 9 管道工的启发

Comments

Smalltalk 作者 Alan Kay 曾说过,对象不是 Smalltalk 的本质,对象间的消息传递才是。对于操作系统中的基本对象–进程,类似的说法也是成立的:进程不是操作系统的本质,进程间的通信才是。像 Mach 这样的微内核操作系统的全部,就是一个供进程传递消息的框架。

进程间通信的技术细节繁杂,以Linux 系统为例,就有文件,管道,消息队列,信号量,RPC,UNIX Socket, RPC 等等多种方式。Windows 系统还有邮件槽, COM 对象等等。Mac OS 则有 AppleEvent 等等。在这里我们介绍 Plan 9 系统中一个不太为人所知的 IPC 机制:Plumber,或者叫做管道工。我在”开发人员为何应该使用 Mac OS X 兼 OS X 小史“中曾赞扬过 Mac OS X 系统中的 AppleEvent 进程间通信机制对工作效率的提升。和AppleEvent 类似,管道工也是对图形界面下进程间通信的一个尝试,不过在通信的粒度上有所区别。

我们从一个简单的例子入手。在如今网络普及的时代,几乎所有的软件都能自动识别链接。只要打入 http:// 开头的一串字符,就立即转化为一个可点击的链接,点击这个链接则自动召唤出浏览器。我们对此毫不感到新鲜,因为这功能再自然不过。其实这些功能在上世纪90年代还是很少见的。 Plan 9 的管道工,在当时就前瞻地提出一套匹配字符串和自动投递给指定应用程序的机制。我们只需要告诉管道工,用户选中字符串匹配某类型的时候就交由某应用程序处理,管道工即负责具体的程序间的通信。这是对 UNIX 管道机制的一个革新。如我在Mac OS 一文中所说,纯粹的管道机制在图形界面程序中已经不再适用了。

我们所熟悉的URI 处理仅限于浏览器,且只能处理由 RFC 2396 预先定义的 URI 模式。即便如此,我们也能体会到 URI 处理器的方便。像大家熟悉的电驴链接实际上是 ed2k:// 打头的 URI。在浏览器点击后就自动用电骡打开;苹果的 iTunes 的链接实际上是 itms: 打头的 URI;Android 商店的链接其实是 market:// 打头的 URI 等等,都是让用户更加方便的例子。有了这些机制后,我们难以想象没有这些机制而需要拷贝粘贴的日子是如何度过的。

管道工是 URI 处理器的推广形式。在管道工里,不仅仅是 URI,一切的字符串都可能匹配。因为读者可能没有用过管道工,我们仍然以大家熟悉的例子来说明。安装了 Skype 浏览器的插件会自动把网页上的电话号码变成一个特殊的“用 Skype 拨打该电话”的按钮,在 Gmail 里开启一些插件后 FedEx 和 UPS 的包裹号码能自动变成链接直接转到包裹查询网站等等。管道工的功能,就是让我们可以很方便的自定义这些转发功能,而不依赖于应用程序的实现。在 Plan 9 系统中,即使你不装 Skype, 不用 Gmail, 用户依然能够通过制定正则表达式匹配规则,来决定如何处理电话号码和包裹追踪号码等等。

管道工的原作者用编译器和编辑器的例子来说明管道工的作用。我们知道编译器报错语法错的时候,会以一定格式报出发生错误的文件和行号,如

Line 43: Hello.cc syntax error.

我们可以设定规则,在用户点击这些错误信息的时候,让管道工自动匹配和提取文件名,行号,并自动发给编辑器,就省却了我们人工打开编辑器跳到某行这个繁琐的步骤。尽管 IDE 已经通过集成编辑器和编译器的方式绕开了这种进程间通信,这种匹配/转发的通信方式仍然用在不少地方。比如 Vim 就引入了一个叫 errorformat (错误格式)的机制,让编辑器能够理解和匹配“错误格式”,并跳到指定的行。

通过 Plan 9 from user space 这个开源实现,我们可以在 Mac 和 Linux 上使用管道工。不过我们已经有了很多现成的工具能够部分实现管道工的功能。因为我日常只用浏览器和shell,因此简略介绍一下我是如何在浏览器和shell中实现类似于管道工的功能的。

用油猴子或者其他浏览器插件,我们可以将网页中某特定的字符串转变成一个定制的链接。然后,取决于所在平台,我们可以将这些链接和预定义的应用程序挂钩。Mac 下一个好用的工具是 RCDefaultApp ,Linux/Gnome 下的 gconftool-2 也直接支持对 URL-handler 的修改。Windows 下的方法则是修改注册表。(当然这些方法都有安全隐患,所以只适合个人使用)。

在终端里,对于 Linux 用户,urxvt 这个终端非常强大,可以使用 perl 扩展来匹配和执行命令,基本上可以完全实现管道工的这种匹配任意字符串且发送给其他程序的功能。在 Mac OS X 中,iTerm 2 是程序员应该用的终端。该终端目前还没有 urxvt 的强大扩展性,不过也能完成大部分匹配任务。比如说,iTerms 的最新版本支持一个叫做 Sementic History 的功能 (Preference -> Profile -> Advanced)。这个功能使得我们可以直接点击 Terminal 里面的文件名召唤出 Finder。用苹果的可能都知道 Mac 里有个 Proxy Icon (应用程序标题栏里面的小图标)的概念,我们可以直接把这个小图标当成文件的代表,拖来拖去,甚至可以直接拖到 Gmail 中当附件。我们其实可以把 iTerms 2 里面的文件名直接当成一个对象拖来拖去。

因为我日常只使用浏览器和终端,Plan 9 的管道工给我的启发是,如果有一套好的进程间通信机制,拷贝粘贴是完全没有必要的。如果你和我一样基本不用鼠标,并且认为拷贝粘贴是一个降低工作效率的事情,那么我建议你尝试一下用管道工的思想去改善你的工作流,看看哪些拷贝粘贴是可以由计算机完成的。

Oct 14, 2011 - UNIX 痛恨者手册读后笔记

Comments

UNIX 痛恨者手册[PDF]可以算是一本奇书了。一般的技术书,写作缘由大多是作者特别喜欢某样技术,兴高采烈地拿出来和读者分享。而此书的几个作者,都是因为恨 UNIX 恨到“人生长恨水长东”的境界了,于是乎搞了个邮件组,广泛收集各种愤怒,最后基于邮件组里面张贴的各种抱怨,编撰成了痛恨者手册这样一本书,来专门宣泄对 UNIX 的愤怒,也算得上是空前绝后了。</p>

尽管这本书视角独特,以现在的眼光看,作者的抱怨中,真正属于 UNIX 固有问题的只占 50%,其他如对 sendmail 排山倒海的批评,对 C++ 的尽情嘲弄,实际上都不属于 UNIX 系统特有的。其他的 50%,则颇有历史意义,可以看到当年的 UNIX 系统是何其的“原始”。特别是对照现在的 Linux 来看,可以看出 Linux 作为当年 UNIX 的继承人,在文件系统,安全性,稳定性等等方面的巨大的进步。

除去一些对 UNIX 中具体 BUG 的批评,这本书的背后实际上是三种设计哲学间的交锋,我把这三种哲学叫做 MIT 哲学,UNIX 哲学和 GUI 系统哲学。“MIT 哲学”这个词,是借用那篇著名的 Worse is better 文章中的叫法。MIT 哲学的代表是 LISP 机器,即提供一个 LISP 环境的机器。这个机器提供给用户的,是优雅的编程环境,如统一的内存管理,统一的函数式接口,良好的文档等等,一切程序员所需要的,都给准备好了。但这个系统不管是作为个人计算机还是作为工作站都没有获得成功。

GUI 系统哲学从施乐的 Alto 开始,到90年代中期 Windows 95 出现之前,已经颇有气象,特别是在个人计算机领域,几乎所有的个人计算机厂商都在提供自己的图形界面操作系统。GUI 系统的哲学,是友好的用户界面和一致的使用体验。至于具体的功能,则委托给具体的应用程序实现。

而 UNIX 哲学,则像是一种开放式系统的哲学:除去提供统一的系统调用和标准工具外(POSIX),不强调系统的一致性。UNIX 像是一堆松散的积木堆起来的一个系统,在遵守 POSIX 标准的前提下(其实是个非常松散的标准)各个厂商都可以自己选择积木搭建系统。

UNIX 这种开放的,允许自由搭积木的做法,是和信奉MIT哲学的人水火不容的。这些用户在 UNIX 的因为开放造成的不一致性上尽情吐槽。比如说,UNIX 一个饱受诟病的缺憾是其命令行参数不统一。在命令行下,有的命令加 -h 是显示帮助,有的却是显示隐藏文件,还有的命令压根不接受 -h 参数。这样的问题,反映了 UNIX 在演化过程中缺少一个统一的规划。这在演化路径单一的其他操作系统上是不可想象的。再比如,UNIX 的计算模型很简单,即用 C 语言和 shell 对系统调用做一个胶水包装,不提供内存管理也不提供异常处理,文件系统也很低级,不支持文件恢复也不支持文件的元信息存储。而 MIT 的LISP 机器的计算模型和存储系统看上去都更加高级,统一的函数式接口,自动内存管理等等。用过 LISP 机器的人自然不习惯 UNIX 这种看上去“低级”的操作系统。结果是,用过 LISP Machine 的用户除了抱怨 UNIX 外,只能寻求在 UNIX 上构建一个新的层,来弥补 UNIX 的不足。这事情的一个结果就是造就了Emacs 这个怪兽,到最后几乎所有能在 UNIX 里做的事情,都能在 Emacs 里完成。这样,除了操作系统内核外,Emacs 完全取代了 UNIX 环境。Emacs 功能强大到大家都同意 Emacs 是个万能软件,而 vi 用户则开玩笑说 Emacs 是个缺少一个好编辑器的操作系统。大家都知道,Emacs 的作者正是从 MIT 出来的 Richard Stallman。

痛恨者手册的作者也是在 MIT 的 AI 实验室工作多年的技术人员。为了解释 UNIX 的成功,他借用了 Worse is better 中的说法(Garbriel 断言 C 语言和 UNIX 是终极计算机病毒),把 UNIX 归类为世界上第一个计算机病毒。书中提到,UNIX 和病毒的共同特征为:体积小,可传染多种宿主(可移植),变异快速等等。书中说, UNIX 的普及并不是因为它在技术比其他操作系统更加优越,只是因为可移植,可传染和变异快,才占据了很大一块用户份额。

这个解释我认为是相当精当的。相对于其他操作系统,UNIX 基于C书写,可移植和早期的免费分发方式,即使技术上不够好,仍然像流行性感冒一样蔓延。一传十,十传百,快速攻城略地。当时 UNIX 的风行程度可以从几个侧面来证明。八十年代初雨后春笋一般地冒出了很多新的UNIX公司,SUN 和 SGI 就是是借着 UNIX 成长起来的典型例子。他们短短几年间就靠 UNIX 工作站业务跑上了纳斯达克。微软和苹果是靠个人电脑业务起家的,各自都有自己的操作系统,却也跑到UNIX世界下注,都曾经推出过自家的UNIX发行版(分别叫做 XenixA/UX)。UNIX这个”病毒”在工作站和服务器上的寄生能力极强,直到后来演化能力和传播能力更强的“病毒” Linux 的出现,加上 .COM 泡沫破裂的一场大洗牌,才把 UNIX 的市场份额压了下去。Linux 则彻底继承了所有的“病毒”特性,除去原有的体积小,可移植外,通过开放内核源代码,造就了现在从超级计算机服务器到嵌入式系统无处不在的现状。从设备总量来说,世界上从未有一个操作系统如 Linux 如此成功。

可惜的是 MIT 哲学派本身没有成功的操作系统产品用来作为比较(除了Emacs这个运行在UNIX上的程序外),因此在批评 UNIX 上火力就欠缺了一分。为了写出一本厚厚的痛恨者手册砸向UNIX,就需要来自另外一派,即信奉GUI哲学的用户的愤怒。

这些用户的愤怒,主要集中在易用性上。图形界面操作系统的出现,本质上就是为了解决计算机的可用性问题。在图形界面系统出现之前,掌握计算机的使用需要的是阅读厚厚的手册。图形界面出现后,只需要几分钟的演示,普通用户即可操作计算机完成一些简单的任务。这种效率的本质提升,正是施乐的 Alto 和苹果的 Macintosh 的革命性所在。而 UNIX 所拥有的,是一堆两个字母的命令,不一致的命令行参数,和一个实际上不是为 GUI 系统设计的 X 图形系统。命令难记,X 又臃肿,即使有了这些仍然没有构成一个统一的桌面系统(所以后来才有KDE 和  Gnome),也难怪用户吐槽不已了。

在这类来自 GUI 用户的抱怨中,出乎我意料的一条是对UNIX管道的抱怨。主要的批评点在于管道作为一种 IPC 机制本身不够强大,包括管道不支持双向数据流(双向管道的用例也极少),只能把数据作为字节流而不能传递结构化数据,和指针等等。从传统 UNIX 用户的眼光来看,这些指责是很不公平的。管道的作用是串接程序的输入输出,将小工具串成强大的工具链。但管道并不是 UNIX 上唯一的 IPC 机制,UNIX 有其他的 IPC 机制来支持管道之外的功能。换一个角度看,要求管道支持双向通信,结构化通信等等,正是从 GUI 哲学出发的对管道的批判。在 GUI 世界,进程间的通信有了两种新的方式:1、把小程序全部集成到一个大的多线程窗口程序中来进行线程间通信; 2、通过在不同程序间复制粘贴对象。从这两个角度考虑,自然会要求 UNIX 管道能像线程间通信一样双向,以及支持有结构的对象而不是单纯的字节流。

GUI 程序的这一套新的进程间通信机制,改变了所在平台的软件架构。UNIX 的软件架构,是围绕软件工具(Software Tools) 的概念展开的,归结起来就是每个工具做一件事情,且做到最好的哲学。因为 GUI 程序本身的复杂性,把林林总总的功能,放入一个大程序中让各模块直接在一个进程空间里互相通信成了一个通行的做法。比如电子表格软件中的公式计算,无需代理到 bc 这样的外部计算器中,直接由内置的模块完成。在这种哲学的指导下,为了给提供全面的解决方案,各种商业程序都追求大而全,内置各种可能用到的功能,因此体积也越来越大。几百兆大小的商业软件不足为奇了。UNIX 痛恨者手册推崇这种只能算局部最优的程序构建方法,而反过来抱怨管道这个另一个局部最优不够好,在我看来是有历史局限性的。

总的来说,这本书代表了 UNIX哲学以外的其他两种哲学对 UNIX 尖锐的批评,是值得当成UNIX 发展史的一部分而一读的。

Sep 27, 2011 - 编程珠玑番外篇-L. 高级语言是怎么来的-7

Comments

LISP 语言前传

Lisp 的主要设计者 John McCarthy 曾经就 Lisp 的发展史,专门写过一篇 History of Lisp 的文章。这里介绍的历史,基本史实部分参照了 John McCarthy 的这篇文章,以及同时期 MIT 的关于 Lisp 的技术报告。

Lisp 的历史要从 IBM 的神奇机器 704 说起。此时是 1954 年,尽管距离 1946 年第一台计算机 ENIAC 的出现已经八年了,商用计算机市场还仅仅起步。很早就进入计算机市场的 IBM 做出了一个影响深远的决定:发布一台可以进行浮点计算的,面向科学和工程的电子计算机。这台计算机,很朴素地跟着 IBM 之前发布的 701,702 后,被编号成 704(不知为什么 IBM 从来没公布过 703)。说 704 是神奇机器,是因为这台机器在计算机科学发展史上意义重大:世界上最早的语音合成程序就是由 Bell 实验室的科学家在 IBM 704 上完成的。 Fortran,Lisp 也是最早在 IBM 704 上实现的。

和当年的所有计算机一样,IBM 704 是个百万美元级别的大玩具,不是一般人甚至一般大学能够买得起的。好在 IBM 和大学的关系一向很紧密,在 1957 年的时候,决定捐一台 704 给 MIT。当时在 Dartmouth 教书的 John McCarthy 和在 MIT 教书的 Marvin Minsky 关系很好,因此这台即将到达的 704,即将成为 McCarthy 的新玩具。

当年部署一台计算机的周期很长,为了不让自己闲着,McCarthy 决定一边等机器部署,一边研究一下如果有了这台机器,可以做点什么。当时 Minsky 手里有一个 IBM 的项目,内容是使用计算机证明平面几何问题。既然计算机没来不能写程序,他们就只能从抽象的层面思考问题的解决方法。这个思考的结果,是开发一套支持符号计算的 Fortran 子系统。他们的基本想法是,用一系列的 FORTRAN 子程序,来做逻辑推理和符号演绎。

回头看,这条路的确绕开了没有 704 就写不了程序的路障。因为我们只需要大致了解 Fortran 能够做什么,不能做什么,无需实际 Fortran 编程,就可以假想我们已经有了一系列未来可以实现的子程序,然后只要在数学上证明这些通过子程序的组合,加上自动逻辑推理,就可以证明平面几何定理。这就把一个计算机工程学问题,抽象成了一个数学问题(日后这个领域被正式划归到人工智能的学科中,但在当时这还是属于数学问题)

这样,计算机没来之前,McCarthy 的最终结果,是一个用 Fortran 子程序做列表处理的简单系统。McCarthy 的这条路很现实的做法——如果不用 Fortran 而是自己写一个新的语言的编译器话,可能需要好几年的时间。而 McCarthy 当年还不是终身教授,投入到写作新语言这样旷日持久且不能保证成果的项目中去,不会对他的职业生涯有太大的正面作用。

704 送到 MIT 后, McCarthy 带着两个研究生,将之前计划的 Fortran 列表处理子程序实现了,并命名为 Fortran 列表处理语言 (FLPL) 。然而,因为 Fortran 语言本身的限制,McCarthy 对 FLPL 并不满意。他在写作自动求函数导数的程序时[a],发现 FLPL 的弱点集中体现在两个地方。

第一个问题是递归。我们在 Fortran 语言怎么来的这一节已经提到,704 上的 Fortran 语言是不支持递归的。而 McCarthy 心中所设想的语言,很重要的一条就是递归:没有递归,很多列表处理的函数只能用循环来实现,而循环本身并不是 McCarthy 设想的语言的一部分。熟悉函数求导的链式法则的读者可以想像,没有递归的求导程序是何其难写,因为函数求导过程本身就是递归定义的。

第二个问题是 Fortran 的 IF 语句。IF 家族的分支语句,在计算机程序设计中可以说必不可少。在 McCarthy 那里 IF 就更重要了,因为几乎所有有递归函数的地方就有 IF(因为递归函数需要 IF 判断结束条件)。相信读者都很熟悉这种 IF 结构

IF 条件 THEN
    一些语句;
ELSE
    另一些语句;
END IF

这是从 ALGOL 语言一脉相承下来的,很“自然”的 IF 写法。而早期的 FORTRAN 的 IF 写法却不这么直观,而是

IF (表达式) A B C

取决于表达式的值是小于零,等于零还是大于零,分别跳到(等价于 goto)标签 A, 标签B 或者标签 C。这个 IF 隐含了三个 Goto,可以说和结构化编程的实践截然相反,降低了程序的可读性。 Fortran 首创的这个三分支跳转的 IF 饱受诟病,Fortran 77 开始支持结构化的 IF,而 Fortran 90 标准进一步宣布三分支跳转的用法已经“过时”,不支持使用。

在 McCarthy 那里,Fortran 的三分支跳转 IF 也不方便。为此,在 FLPL 中,他试图用一个叫 XIF 子程序完成类似于 IF 的分支功能,用法是:

XIF(条件, 表达式A, 表达式B)

取决于条件的满足与否,XIF 返回表达式A 或者表达式B 的值。很快,他发现,用子程序的方法实现 XIF,在语义上并不正确。我们知道,在 Fortran 和其他高级语言中,函数参数的值在进入函数之前必须全部确定。在 XIF 这里,不难看出,不管条件满足与否,我们都先要计算表达式A 和表达式B 的值。而 IF 是个分支逻辑,从语义上来说,应该只计算满足条件的分支的值。因此,用函数来实现 IF 是不正确的 [b]。

作为一个旁注,尽管 John McCarthy 早在50多年前就发现了函数实现 IF 是语义错误的,现代的程序员还常常犯这个错误。一个值得一题的例子是 C++ 逻辑运算符重载和短路表达式的不等价性。我们都知道,在 C 语言中,逻辑与 (&&) 和逻辑或( || ) 都隶属于短路表达式,也就是说,对于 A && B 这样的表达式,如果 A 已经确定为 false,就无需计算表达式 B 的值,即 B 的计算被”短路”。以 C 为蓝本的 C++ 一方便保留了这些短路表达式,另一方面在面向对象的特性中,引入了运算符重载。具体来说,只要一个对象定义了 operator&& 成员函数,就可以进行 && 运算。乍一看,这是一个很酷的特性,可以让程序员用 A&&B 这样的数学表达式表达复杂的逻辑关系。然而,仔细想想,  A.operator&&(B) 在语义上并不等价于 C 所定义的 A&&B,原因在于 A.operator&&() 是个函数,在求值之前需要先计算 B 的值,而后者是个短路表达式,本质上相当于

IF A:
 return True
ELSE:
 return B
因为短路表达式不一定会对 B 求值,这两者从语义上就是不等价的。如果 B 不是一个简单的对象,而是一个复杂表达式的时候,对 B 求值可能有副作用,而这个副作用,是写 A && B 并把它当做短路表达式的程序员所没有预见的。按照 C++ Gotcha 的说法,这很容易造成潜在的程序 Bug。实际上,C++逻辑运算符重载是一个危险的特性,很多公司的编程标准都禁止使用逻辑运算符重载。

递归和 IF 两个问题,使得 Fortran 从本质上就不符合 McCarthy 期望,以 Fortran 为宿主的开发列表处理语言也不可能达到 McCarthy 想要的结果。因此,唯一的解,就是抛开 Fortran,从头开始,设计一个新的语言。值得注意的是,此时 McCarthy 正好跳槽到了 MIT 做助理教授,MIT 有足够多的编程强人,可以帮 McCarthy 完成这个编写新语言的任务。这个强人,就是 Steve Russell;这个语言,就是 Lisp。

[a] 读过 SICP 的读者会发现这是一道习题

[b] 读过 SICP 的读者会发现这又是一道习题

 

Aug 7, 2011 - 童子军军规和习惯培养

Comments

我最喜欢的饼干是美国的女童子军饼干。这种饼干由女童子军协会统一制作,然后交给每个童子军支部售卖。参与童子军训练的小女孩通过售卖饼干,学会设定目标,制定计划,协调分配,管理财务,以及领导团队。每年春天,在美国生活的人都会在大大小小的超市门口,看到一群女孩子卖饼干。这些训练,是读书完全不能企及的。男童子军(与女童子军是独立的两个组织)的训练也很有特色,还记得 Up 里面的那个胖嘟嘟的小男孩么?他就是男童子军的一员,为了拿到一枚“野外探险”的徽章,居然误打误撞到南美转了一圈。要是想成为鹰徽童子军(男童子军最高级别),需要一系列的徽章,难度基本上和在 Foursquare 上拿全所有徽章差不多。

男女童子军训练是很多国家儿童素质训练的重要一环。人的性格和习惯到了成年实习就比较难改变了。未成年时期的如童子军训练这样的项目,是培养一个“人”的很好的方式。人生中的最重要的好习惯,往往是在幼年少年时期,甚至在幼儿园学到的。实际上,对好习惯进行有意识的培养是社会教育应有的部分。因为这些好习惯不光可以塑造一个“人”,也能够让所在的社会更加美好。这些好习惯可以推广到生活和工作的很多方面。比如程序员们很熟悉的 Bob Martin 大叔,就围绕这一条男童子军的“整洁”的“军规”,[硬生生写了本叫做 ](http://www.informit.com/articles/article.aspx?p=1235624&seqNum=6)。这条军规的背后,是童子军创始人 Baden-Powell 留给男童子军的最后的话,当你离开一个世界的时候,试着让这个世界比你发现他的时候更加好 (Try and leave this world a little better than you found it)。这句话的指导意义,既用在定义人生上,也可以用在整理房间上,或者对公共场所垃圾的处理上。当然,也可以像 Martin 大叔一样用在代码重构上。

因为内人是女童子军成员,最近准备搬家整理东西的时候,整理出了一大捆女童子军训练的材料,其中一本叫做“6-9年级女童子军手册”的书,我不经意瞄了一眼,觉得有些话写得真好,特别是女童军的“成功生活”的八个原则,因此简单的翻译一下。

女童子军的“成功生活”的八个训练:

  1. 管理你的时间 (Managing Your Time)

  2. 正确处理压力 (Handling Stress)

  3. 学会表达自己 (Speaking up for yourself)

  4. 时刻保持安全 (Stay safe)

  5. 获取管理钱财 (Earning and managing money)

  6. 注意合理消费 (Becoming a responsible consumer)

  7. 准备满意职业 (Preparing for satisfying career)

  8. 做负责任抉择 (Making responsible decision)

这八条原则如果孤立开来看,就和市面上大部分成功学书一样,并无特别之处。不过,考虑到这是未成年时期的训练,效果和成年之后再主动反向训练,难度是有区别的。现代认知心理学的一个基本假设是,人可以通过提高自己的认知能力(心智),改变自己的思维方式,对事情的看法,控制(相对难以控制的)感情,以及获得精神上的愉悦和在现实中的成功等等。少年时期的这些训练,正是对人认知能力的一种系统性的提升。成年之后用认知心理学方法反过来训练大脑和行为习惯,固然目标明确,却有事倍功半之感。

我觉得我小时候很幸运,有意无意的受到了多方面好习惯的训练。相信很多读者都受过类似的好习惯的训练,不过像童子军这样分门别类为这些好习惯设置配套训练项目还是第一次见到。如果将来我有小孩子,一定送他/她参加这样的童子军训练。诸位读者中有不少家长,想必也很注意对小孩的好习惯的培养,或许参阅美国的童子军训练的一些项目会有一些新的启发。