［荐］［转］为什么应该使用 MacOS X（论GUI环境下开发人员对软件的配置与重用）

一周前我和 Tinyfool 闲聊苹果操做系统，都认为对于开发人员来讲，苹
果操做系统（MacOS）是上佳的选择。Tinyfool 笔头很快，立即就写了一篇
长文章，我则笔头很慢，今天才所有码好。他的文章的主要切入点在于 Mac
平台做为目标开发平台的优点，而我这篇的切入点主要是 MacOS 做为一种开
发工具的优点。

开发人员的趁手工具

对于开发人员来讲，全部的开发工具的最大的用途，就是最大限度的提
高开发人员的生产率(productivity)和创造力(creativity)。在咱们这个时
代，使用 GUI(图形界面)是一个提升生产率的好手段。虽然上一代的那些 UNIX
开发人员的确不须要 GUI。一个屏幕，一个键盘，一个编辑器，在陋巷，人
不堪其忧，也不改其乐的黑客比比皆是，但二十多年过去了，现现在开发环
境发生了巨大的变化。好比说，相比较于当年程序员使用的基于文本的环境，
在 GUI 下格式丰富的文档显得更直观，阅读体验更加好；就算工做中不须要
开发任何 GUI 程序，现代开发人员也会使用 GUI 来完成网页图片和文档阅览
等等。所以，即便是最传统的用命令行的开发人员，其实也能沾 GUI 的光。
好比说如今最好的终端程序，都是 X 下模拟的，由于这些模拟的终端的出现，
一些复杂的可视化功能能够在这些终端中实现了，好比 Unicode 的显示
(rxvt-unicode)等等。
对于开发人员，拥有一组很是好用的，可以最大程度的提升生产率的开
发工具乃是一大人生梦想。那么，这套开发工具从何而来呢？大致来讲，这
些工具来自于三个方面：1.经过系统和单一的应用软件提供的；2.经过搭配
使用各类应用软件 3.经过定制和改变现有的应用软件。这三点，对于 UNIX
开发人员是再熟悉不过的了，无非就是写脚本，走管道而已。因此，在前 GUI
时代，这一套哲学很是盛行，开发人员都知道，须要经过安装脚本解析器，
写一些的脚本，配置一些环境等等，才能把刚出厂的 UNIX 系统，改形成本身
使用起来驾轻就熟的系统。基本上任何一个使用 UNIX/Linux 系统多年的人，
机器里面都有各类各样的“私藏”的脚本。离开了这些脚本，他的效率会大
打折扣。

GUI 时代传统的丧失

上世纪 80 年代的时候，GUI 时代和我的计算机普及的时代降临了。今后，

计算机变成了我的电脑，历史上第一次，计算机不是专为开发人员设计，而
是为了普通用户设计。普通用户的需求就是完成一个一个的现实问题，软件
产业提供的解决办法就是为用户提供一个一个的应用软件，而不是让用户自
己一行一行的编程和写脚本，巨大的软件需求瞬间成就了一个巨大的软件产
业。这样的一个间接后果就是，对于普通用户来讲，让一台计算机变成可以
帮助本身完成任务的“我的计算机”的惟一手段，就是叠床架屋的不断的装
各类应用软件。
咱们能够用一个简单的例子说明这种使用模式。咱们都知道，安装
Windows 系统的一个经验原则是把操做系统和应用程序分红两个逻辑盘，一
个在 C 盘，一个在 D 盘。这个磁盘分区的经验原则不光网吧老板知道，连我
大学里面只会点鼠标的那些女同窗都知道。为何有这个奇妙现象呢？其实，
这是由 Windows 系统的用户的典型使用模式决定的。在 Windows 系统上，应
用程序和文档是关键，操做系统只是一个随时能够重装的东西而已，因此干
脆二者分开，互不影响。在这样的使用模式引导下，Windows 系统上格盘重
装是很是低成本的，只要文档不丢，应用程序不丢就行。这种使用习惯，浪
费了多少 geek 男美好的时光为人重装系统，又促成了多少美妙的姻缘:)。总
之，在 GUI 时代，要解决一个问题，就装一个应用程序。至于应用程序之间
的通讯，和用非键盘鼠标的方法控制应用程序等等，都再也不是要考虑的问题，
有这样的需求的人成了非主流，非主流到以至于主流的操做系统和应用软件
都不让你这么干了。操做系统把全部其余的路都封死，就是明摆着告诉你，
要想某样功能，请出门买软件。

Smalltalk 的启示

其实 GUI 时代本来不该该是这样的。咱们都知道，GUI 本来是施乐的
AlanKay 那一帮人作科研作出来的，Bill·Gates 和 Steve·Jobs 各自到施乐
“抄袭”了一部分过来，因而窗口啊按钮啊就处处都是了。他们都看到了图
形界面和面向对象的形，看到了图形界面就是把按钮图标等等对象放好，然
后鼠标点击拖动等等这些表面的东西。由于全部的 GUI 界面都是从文字界面
起步的，因此全部的 GUI 程序，其实就是原来的可执行程序的包装。C++这个
语言的出现也很讨巧，把 C 包装成了一个面向对象的语言，包装对包装，C++
很讨巧的适应了把可执行程序GUI化的趋势，成了GUI时代的主流开发语言。
从表面上看，只要运行这些可执行的程序，就可以看到图形界面，就可以用
鼠标点击操做他们，但是这些东西的底层，都是一个编译过了的可执行程序，
原先 Smalltalk 中的那些运行时环境啊，对象容器啊，都通通不见了，全部
的图形界面程序，仍是直接运行在计算机的 CPU 上，而不是一个虚拟的面向
对象的容器上。而这个面向对象的容器（也叫作“运行时”或者“运行环境”），

才是 Smalltalk 的神。简单的说，Smalltalk 自己具备一个面向对象的运行
时，因此即便到了执行的时候，里面全部的对象仍是能够互联互通的。而 C++
写出来的程序，除了编译以前是面向对象外，只要一编译，就所有变成机器
码，和对象就再也没有任何关系了，也就不存在运行时去动态的查看(inspect)
和改变(modify)这些程序对象的说法。总之，由于历史的局限，这些 GUI 的
平台，都是渐进的照猫画虎的演变的，因此没有一个平台像 Smalltalk 那样
细致地考量过对象的互相通讯的问题，再加上咱们上面说了，反正扩展系统
的方法就是引入新的应用软件而已，自己也没有互联互通的需求，因此这种
抛弃运行时的，不让对象被外部程序控制的实现方法也无所谓很差。
但是开发人员不是普通用户啊，他们依然要改造计算机成为本身的工具
的。在现有的现有工具不能解决问题的时候，要否则本身从新发明轮子，要
否则就复用现有的一些工具，或者从新按本身的需求从新配置这些工具。所
以，和通常用户不同，开发人员须要这些 GUI 的可配置性，也须要这些 GUI
程序之间的互联互通。用黑话来讲，第一个问题关系到 GUI 应用程序的脚本
化，第二个问题关系到 GUI 程序之间的进程间通讯。这两个问题，提及来简
单，但都牵扯到 GUI 系统的根本设计问题。历史在这里开了一个不大不小的
玩笑，把这个惟一的机会给了 MacOSX。其余操做系统，都由于这样那样的原
因，在这两个问题上没有很好的解决方案。

进程间通讯，苹果的方案

花开两朵，各表一只。咱们先说 GUI 程序的进程间通信的问题。所谓的
进程间通讯（IPC），就是两个程序之间的信息共享。咱们都知道，*nix 的一
个强大之处就在于管道，管道是最简单，最廉价也是最经常使用的*nix 进程间通
信的方法。在 GUI 时代，最经常使用的 IPC 机制成了剪切板和鼠标拖放操做。这
两个操做虽然都很直观，但都要人操做，离开了人，程序根本没法自动完成
进程间通讯。而要工做效率的提升，就是要让计算机离开了人的干涉，也能
完成这些任务。为了自动化这些任务，操做系统就不能简单的绘制窗口而后
万事大吉了，它必需要知道哪些程序在运行，哪一个运行的程序能够给哪一个程
序发消息通讯等等，好比说，若是咱们想自动的在阅读器里面选择一个词送
给字典程序查释义，计算机就须要知道字典程序在运行的时候能够接受一个
字符串，可是不能够接受图片。若是咱们把字典程序抽象成一个能够提供“查
字典”服务的对象的话，毫无疑问，若是想要向字典程序发送字符，必须首
先知道字典程序可以接受什么，用什么方式把这个单词发送给字典等等。所
有的这些信息，都必须由操做系统托管才行（不可能每一个应用程序里面都要
记着字典这个程序能接受字符串不能接受图片，这样每一个应用程序都要记下
全部其余可能的应用程序的信息，这是一个平方级别的关系，须要开发人员

开发一个程序的时候还要兼顾其余全部程序，这显然是不现实的）。用行话来
说，必需要有一个统一管理的运行环境，来管理这些程序之间的互相通讯问
题。咱们上面说了，Smalltalk 的神在于一个统一的面向对象的运行时，使
得全部的应用程序能互联互通。但是全部平台上的 GUI 程序的演化进程都没
有走这条路，而是只把外表给模仿走了；有的平台即便想作互联互通，也作
得不完全（好比微软的 OLE，COM 等等）。
是好东西，总会发光的。可是要想让这个好东西被新的操做系统全盘采
纳，要想让一个系统可以从底层到上层所有采用统一的运行环境，就要扔掉
不少的历史包袱。甩掉这种历史包袱，对于任何操做系统都是不容易的。如
果咱们回到当年，必定会幻想，要是有个神人，可以无论市场也无论现有平
台，从头打造一个没有任何历史包袱的干净整洁的 GUI 系统该多好。历史就
是这么戏剧，还真就安排了一我的，作成了这件事情，这我的，就是那个斯
蒂夫乔布斯。
1985 年，乔布斯被苹果扫地出门，成立了 Next 公司，一心想要作出质
量上乘的 GUI 计算机系统。历史给了乔布斯一个所有从头作的机会。这一次，
乔老师和 Next 的开发人员意识到，光照搬 Smalltalk 的形是不行的，要连它
的神也拿过来，重头设计进程间通讯和 GUI 系统。在内核层面，他们用了 Mach
这个为 BSD 设计的微内核。这个操做系统内核就是为了替换已通过时的 UNIX
内核而设计的，其中的一个核心设计哲学就是从新设计进程间通讯；虽然现
在基于微内核的操做系统已经不是什么潮流（为此 Linus 和 Tanenbaum 吵了
一场著名的架)，但在相比较于当时 UNIX 系统的内核（此时 Linux 还没出现
的，UNIX 内核只有 BSD，Bell,SUN 等几套），Mach 算是一个高的起点。在这
个内核上，Next 公司的工程师开始构建面向对象的基础系统。这套系统在
Smalltalk 中已经有了蓝图，所以这些工程师以 Smalltalk 为蓝图，先设计
了一套基于 C 的语言，也就是 ObjectiveC，照搬了 Smalltalk 的经典的[对
象消息:参数]语法。(我我的不喜欢 ObjectiveC 这个语言，Smalltalk 是一
种纯面向对象的动态类型的语言，Next 公司当年彻底有机会用 Smalltalk 语
言的，若是用了 Smalltalk，如今的 Cocoa 框架还会更加漂亮，代码更加干
净；用 ObjectiveC 这个自创的语言，不知道是否是由于专利的考虑，反正
ObjectiveC 这 20 年的全部创新，就是在慢慢的更像 Smalltalk 而已，Java
和 Ruby 这几年也是不断的从 Smalltalk 拿东西）。有了内核，有了语言，Next
构建了一个纯的面向对象的运行环境和类库（和 Java 和.Net 的统一类库想
法相似，只不过超前了十几年)，这套类库，在当时叫作 NextStep,因此全部
的类名前面都带有 NS 前缀，无比丑陋。惋惜的是，当年这个超越时代的类库
太阳春白雪了，话说 Smalltalk 超越了时代 20 年，因此 90 年代中期的时候，
程序员才想起来当年 Smalltalk 的好，出现了 JavaRuby 等等受 Smalltalk
启发的语言。乔老师虽然落后了 Smalltalk5 年，却领先也业界 5-10 年，所

以在 1995 年的时候，Windows95 卖疯了，乔老师的 NextStep 却没动静，只
能把这个类库从新打包当成 Web 类库卖卖，即 WebObjects。这却是无意插柳，
生意不错，由于当时的 Web 开发已经吃尽了没有一个统一的运行环境的苦头
（这也是往后 Java 风行的缘由）。咱们说，是金子总要发光的，可是前提是
要(1)Next 再等几年，等业界回过神来认识到它的好处，(2)得到一个主流的
操做系统支持，把底层全换成乔老师的东西。乔老师也知道这两个条件，所
以加快了和 SUN 合做的步伐，想要把这套系统放到 SUN 的工做站上。可是 SUN
自己有很强的底层技术，那段时间又狂推 Java,因此其实乔老师在 SUN 这条
路上胜算不大，何况 SUN 本身内核技术很强，因此确定要肢解 NextStep 把内
核重写，若是不和 SUN 玩，一来 Next 这家公司可以多撑 5 年都是问题，二来
几乎每家作我的计算机的公司都倒戈微软了，其余作工做站的公司又都有自
己很强的底层技术，不可能用乔老师的玩意儿的，因此看起来乔老师和他的
阳春白雪好像前景不妙。但是天无绝人之路，放眼看当年的市场，只有一家
公司没有倒戈微软，又没有很强的底层技术，又和乔老师有一些渊源，历史
就是这么戏剧，这家公司就是把乔老师扫地出门的苹果。
90 年代中期苹果的日子很很差过，我的电脑市场败给了 Wintel 联盟，
新兴的市场上成绩也一塌糊涂，投资人也不糊涂，把当年让乔老师扫地出门
的 Sculley 也扫地出门了，随后就把乔老师的公司给买了回来，让乔老师复
职负责复兴苹果。因此，上面咱们说的两个条件就这样忽然的知足了：第一，
他如今是老大了，因此能够完全的把原来苹果的系统推倒重来，用本身的新
家伙；第二，原来 Next 公司的那帮工程师不要担忧失业了，如今由苹果负责
发工资了，因此，正好可让这些人着手改造苹果系统，主要的工做就是用
本身带过来的新系统取代苹果的旧系统，而且让新系统的图形界面和旧系统
保持风格的一致。这个工做，从 1995 年 Next 被收购，到 2001 左右的时候才
作好，这 6 年的时间里，乔老师也顺带让苹果从新盈利了。
2001 年发布的 MacOSX,是苹果操做系统的第十代，彻底基于了乔老师在
Next 开发出来的那套类库，因此天然的，具备了一个统一的面向对象的运行
时。这个运行时和类库系统，MacOSX 把它叫作 Cocoa。其实 MacOSX 刚出来的
时候也不怎么好，不过依赖于这套设计精良的底层系统，MacOSX 的迭代开发
周期要比其余操做系统短多了（仅慢于 Linux,不过 Linux 只有内核部分).在
短短的 8 年里，MacOSX 就搞出了 7 次大的版本发布。虽然咱们看 MacOS 好像
从 10.0 到 10.6 只是次版本号在进步，其实每次都是一个 majorrelease,大
致至关于从 Window95 到 Windows98 或者 Windows2000 到 WindowsXP 这样级别
的升级。这样的发布却不改主版本号，一方面是从市场上考虑，另外一方面也
的确说明 OSX 的底层已经处于一个相对稳定的状态。有不少 Windows 程序员
很是推崇.Net。是的，.Net 的确是一个很是好的框架，但是想像一下，苹果
在 1995 年的时候就有了一个统一的运行时，加上这么多年全部的程序都在这

个统一的框架上开发，若是论在 MacOSX 这个平台上的经验积累，应该说 Cocoa
社区是比.Net 社区更加成熟的。

应用程序脚本化

光有进程间通讯的系统还不能算是一个彻底成熟的 GUI 系统，由于进程
间通讯依然是相对底层，而 GUI 上的应用软件是层出不穷的，不可能任何问
题都跑到底层用进程间通讯解决；因此，要想让 GUI 系统进化到易用和易于
定制的水平，就须要开放对 GUI 程序的脚本控制。只有 GUI 程序能被外部控
制了，才能真正的达到搭配使用 GUI 系统的效果。其实，一旦有了一个统一
的运行时，只要开发应用软件的时候统一设计一下脚本接口，用脚本控制 GUI
程序应该不难。好比说，微软的 Office 系列套件，就彻底能够用 VBScript
去控制。惋惜的是，没有一个系统可以实现全系统的控制。要实现全系统的
控制，不只仅要这个系统可以提供底层的支持，更重要的是要能说服全部的
开发人员，或者说让全部的开发人员养成开放脚本接口的好习惯。从技术上
来讲，这不是太大的问题，只要开发人员按照统一的脚本通讯协议，实现特
定的接口就好了，但是，若是一个平台上开发 GUI 的方法太多，开发人员只
选本身喜欢的来，这种标准就不可能统一。好比说 Linux 上 KDE 和 Gnome 都
有本身的脚本化系统，但是开发人员有的用 KDE,有的用 Gnome,有的干脆二者
都不用，这就谈不成有一致的接口。一个平台要想有一致的脚本控制接口，
除非(1).这个平台上就一种 GUI 开发方法，自古华山路一条，要不不作，作
出来的东西就只能是标准的接口；(2).这个平台上大部分的，主流的应用软
件，都实现了这个脚本接口，这样由于这些程序的拉动，其余 GUI 程序想要
融入这个平台上现有的应用软件的圈子相互通讯，那也就必需要实现这个接
口。在 2000 年的时候，又只有一家公司可以同时知足这两个要求，就是苹果。
微软部分作到地了这两条，基本上用 VBA 统一了 Office 的控制，可是跳出
Office，微软的 OLE 对象模型几乎没有任何用武之地，与之捆绑密切的 VBA
天然无人问津。不过据一些在金融行业工做的朋友说，VBA 可以大大提升
M$Office 的生产率。
GUI 脚本化不是一晚上之功，特别是咱们说要作出统一的脚本接口，能兼
顾各类程序的需求，这就彻底不是一两年的时间可以搞定的，总须要不少年
的技术积累和设计取舍后才能收敛到一个相对稳定成熟的系统，而苹果，居
然很神奇在十几年前就有这方面的经验，苹果再次怎么这么幸运呢？
在 80 年代后期的时候，苹果机上有一个很是超越时代的软件，叫作
Hypercard。这个软件我曾经在上一代苹果上玩过，具体的思想就是你能够存
储一张一张的“卡片”，这些卡片上面能够放置多媒体的声音，图像文字和其
他对象，基本上就和如今网页一回事，惟一的区别就是这些卡片都存在本机。

在没有 Powerpoint 这类软件以前，这个 Hypercard 的软件能够用来作课件，
作幻灯片演示等等，是个极其强大的工具。为了让用户能够定制这个卡片，
这个程序提供了一套很是强大的编程系统，叫作 Hypertalk。由于这种编程
语言是给普通人而不是程序员用的，因此你会感受根本不是编程，而是写英
语。这套东西，虽然本质上也是从 Smalltalk 学来的，可是用英语语法的方
法编程的确是一个全新的思路，苹果把这个给普通人编程的语言发扬光大了，
用更加贴近天然语言的方法重写了语言和文档，模仿 Hypertalk 系统，发布
了一个跨系统的脚本控制语言，叫作 Applescript。这个语言就和天然语言
没什么区别，比方说,
获取窗口的大小再也不是
window.getSize()
而是
get size of window
显示第 22 段的 第一个单词再也不是
print(paragraph[22].getWordByIndex[0])
而是
print the first word of paragraph 22
更狠的是，你还能用法语和日语写。80 年代后期的时候和整个 90 年代
初期，苹果基本上已经被 PC 机逼到墙角了，只剩下出版行业，设计行业等等
专业的行业由于应用软件和图形处理能力的关系，依旧在守着苹果机。两个
行业的用户都须要自动化的 GUI 控制，可是编程都不怎么样，因而，这些应
用软件的开发商也主动掺合加入 Applescript 旗下。在 90 年代乔老师没有加
入前，苹果本身把 Finder 所有脚本化，出版业的 QuarkXPress 和 Filemaker
也都彻底脚本化，等乔老师入主苹果后，基于 Cocoa 的新技术，苹果一口气
在 MacOSX 上推出了 Safari,iTunes,iPhotos 等等软件，一古脑儿的所有脚本
化了。在别的公司均可望而不可求的历史机遇，又是被苹果给抓住了，一股
脑儿所有塞进了 MacOSX。这下，全部的第三方开发的工具，如 Firefox,Adium
这些，其实原本都不是苹果开发的，也没有太强的苹果渊源，可是 Firefox
要读 Safari 书签吧，哈，那就用 Applescript 吧，因此，Firefox 也逼着脚
本化了（这个在其余平台上都不存在的事情）。Adium 也是，这个聊天软件想
要把 iTunes 正在播放的歌曲当成状态信息，好呀,Applescript，因此，也被
带着脚本化了，而在 Linux 上的对应产品 pidgin 就没有这么脚本化。因此，
苹果平台已经成了一个惯性，你不想脚本化，就不带你玩，看你还脚本化不？

结语
咱们都知道，UNIX 时代的主要哲学是提供给开发人员一组小巧精美且可
以任意搭配使用的小工具，也就是所谓的 SoftwareTools,而后任由开发人员
由此出发，本身搭建本身的工具，打造本身的瑞士军刀。而开发人员所用的
操做系统的目的，要不就是提供这样的一组开发工具，要不就是为这样的开
发工具提供一个便利的平台，使得这样的工具变为可能。若是说 UNIX 是命令
行时代的一个易于改形成“本身的操做系统”的操做系统的话，MacOSX 就是
GUI 时代的这样的一个操做系统。即便是从应用软件的层面看，MacOSX 的底
子好，更加容易出精品软件，因此即便仅使用应用软件，开发人员也应当优
先考虑 MacOSX。

附 A:相对正确的 MacOSX 使用习惯
一、 必定要装 Quicksilver 或者用“服务”，不然就是把苹果当 Windows 用。
二、 在苹果计算机上，由于有服务和 Quicksilver 这样的工具，90%的程序间
的拷贝粘帖都是能够避免的。
三、 剩下的 10%的程序内的拷贝粘帖，若是用一个好的编辑器的话，又能够
省略掉 90%。

附 B：为何 Linux 系统在这个方面还不够好
第1、Linux 上的 GUI 子系统，其实不是 Linux 的一部分，而是 X 和上面的 KDE
以及 Gnome 等等。这几年，这些系统终于开始统一管理一个面向对象的
运行环境了。但是这两个系统都是用 C++所写，因此免不了费很大的力
气才有了运行时信息，绕了一个大弯路，若是一开始这两个系统就用
Smalltalk 之类的有运行时的语言编写，至少如今应该有能和 Cocoa 抗
衡的框架。
第2、这几年 X 也认识到了在脚本化控制上面的不足，因此几年前作桌面的
Redhat 提出了 DBus 标准。惋惜的是否是每一个程序都开放了 Dbus 接口，
因此和苹果比起来，还有比较长的路要走。

ANdrew*:

《MAC OS X从入门到精通》