《开发人员为何应该使用 mac os x 兼 os x 小史——论gui时代程序开发策略》由会员分享，可在线阅读，更多相关《开发人员为何应该使用 mac os x 兼 os x 小史——论gui时代程序开发策略（7页珍藏版）》请在金锄头文库上搜索。
1、开发人员为何应该使用开发人员为何应该使用 MacMac OSOS X X 兼兼 OSOS X X 小史小史论论 GUIGUI 时代程序时代程序开发策略开发策略ugmbbc 发布于 2010-08-17 09:46:26|9878 次阅读一周前我和 Tinyfool 闲聊苹果操作系统，都认为对于开发人员来 说，苹果操作系统（Mac OS）是上佳的选择。 Tinyfool 笔头很快， 当即就写了一篇长文章， 我则笔头很慢，今天才全部码好。 他的 文章的主要切入点在于 Mac 平台作为目标开发平台的优势，而我这篇的切入点 主要是 Mac OS 作为一种开发工具的优势。开发人员的趁手工具开发人员的趁手
2、工具 对于开发人员来说，所有的开发工具的最大的用途，就是最大限度的提高开发 人员的生产率 (productivity) 和创造力(creativity)。在我们这个时代，使 用 GUI (图形界面) 是一个提高生产率的好手段。虽然上一代的那些 UNIX 开 发人员的确不需要 GUI。一个屏幕，一个键盘，一个编辑器，在陋巷，人不堪 其忧，也不改其乐的黑客比比皆是， 但二十多年过去了， 现如今开发环境发 生了巨大的变化。 比如说，相比较于当年程序员使用的基于文本的环境，在 GUI 下格式丰富的文档显得更直观，阅读体验更加好；就算工作中不需要开发 任何 GUI 程序，现代开发人员也会使用 GUI 来
3、完成网页图片和文档阅览等等。因此，即使是最传统的用命令行的开发人员，其实也能沾 GUI 的光。 比如说 现在最好的终端程序，都是 X 下模拟的，因为这些模拟的终端的出现，一些复 杂的可视化功能可以在这些终端中实现了，比如 Unicode 的显示(rxvt- unicode)等等。对于开发人员，拥有一组非常好用的，能够最大程度的提高生产率的开发工具 乃是一大人生梦想。那么，这套开发工具从何而来呢？ 大体来说，这些工具来 自于三个方面： 1. 通过系统和单一的应用软件提供的；2. 通过搭配使用各种 应用软件 3. 通过定制和改变现有的应用软件。 这三点，对于 UNIX 开发人员 是再熟悉不过的了，
4、 无非就是写脚本，走管道而已。 所以，在前 GUI 时代， 这一套哲学非常盛行， 开发人员都知道，需要通过安装脚本解析器，写一些的 脚本，配置一些环境等等，才能把刚出厂的 UNIX 系统，改造成自己使用起来 得心应手的系统。 基本上任何一个使用 UNIX/Linux 系统多年的人，机器里面 都有各种各样的“私藏”的脚本。离开了这些脚本，他的效率会大打折扣。GUIGUI 时代传统的丧失时代传统的丧失上世纪 80 年代的时候，GUI 时代和个人计算机普及的时代降临了。从此，计 算机变成了个人电脑，历史上第一次，计算机不是专为开发人员设计，而是为 了普通用户设计。普通用户的需求就是 完成一个一个的现
5、实问题，软件产业提 供的解决办法就是为用户提供一个一个的应用软件，而不是让用户自己一行一行的编程和写脚本，巨大的软件需求瞬间成就了 一个巨大的软件产业。 这样 的一个间接后果就是，对于普通用户来说，让一台计算机变成能够帮助自己完 成任务的“个人计算机”的唯一手段，就是叠床架屋的不断的装各种应用软件。我们可以用一个简单的例子说明这种使用模式。 我们都知道，安装 Windows 系统的一个经验原则是把操作系统和应用程序分成两个逻辑盘，一个在 C 盘， 一个在 D 盘。这个磁盘分区的经验原则不光网吧老板知道，连我大学里面只会 点鼠标的那些女同学都知道。为什么有这个奇妙现象呢？其实，这是由 Windo
6、ws 系统的用户的典型使用模式决定的。 在 Windows 系统上， 应用程序 和文档是关键，操作系统只是一个随时可以重装的东西而已，所以干脆两者分 开，互不影响。在这样的使用模式引导下，Windows 系统上格盘重装是非常低 成本的，只要文档不丢，应用程序不丢就行。这种使用习惯，浪费了多少 geek 男美好的时光为人重装系统，又促成了多少美妙的姻缘 :)。 总之，在 GUI 时 代，要解决一个问题，就装一个应用程序。至于应用程序之间的通信，和用非 键盘鼠标的方法控制应用程序等等，都不再是要考虑的问题，有这样的需求的 人成了 非主流，非主流到以致于主流的操作系统和应用软件都不让你这么干了。操作
7、系统把所有其他的路都封死，就是明摆着告诉你，要想某样功能，请出门 买软件。SmalltalkSmalltalk 的启示的启示其实 GUI 时代原本不应该是这样的。 我们都知道，GUI 原本是施乐的 Alan Kay 那一帮人做科研做出来的，Bill Gates 和 Steve Jobs 各自到施乐”抄袭”了一部分过来，于是窗口啊按钮啊就到处都是了。 他们都看到了图形界面和 面向对象的形， 看到了图形界面就是把按钮图标等等对象放好，然后鼠标点击 拖动等等这些表面的东西。 因为所有的 GUI 界面都是从文字界面起步的，所 以所有的 GUI 程序，其实就是原来的可执行程序的包装。 C+ 这个语言的出
8、 现也很讨巧，把 C 包装成了一个面向对象的语言，包装对包装， C+ 很讨巧 的适应了把可执行程序 GUI 化的趋势， 成了 GUI 时代的主流开发语言。从表 面上看，只要运行这些可执行的程序，就能够看到图形界面，就能够用鼠标点 击操作他们，可是这些东西的底层，都是一个编译过了的可 执行程序，原先 Smalltalk 中的那些运行时环境啊，对象容器啊，都统统不见了，所有的图形 界面程序，还是直接运行在计算机的 CPU 上，而不是一个虚拟的面向对象的容 器上。而这个面向对象的容器（也叫做“运行时”或者“运行环境”），才是 Smalltalk 的神。 简单的说，Smalltalk 本身具有一个面向
9、对象的运行时，所 以即使到了执行的时候，里面所有的对象还是可以互联互通的。 而 C+ 写出 来的程序，除了编译之前是面向对象外，只要一编译，就全部变成机器码，和 对象就再也没有任何关系了，也就不存在运行时去动态的查看(inspect) 和改 变(modify) 这些程序对象的说法。 总之，因为历史的局限，这些 GUI 的平台， 都是渐进的照猫画虎的演变的，所以没有一个平台像 Smalltalk 那样细致地考 量过对象的互相通信的问题，再加上我们上面说了，反正扩展系统的方法就是 引入新的应用软件而已，本身也没有互联互通的需求，所以这种抛弃运行 时的， 不让对象被外部程序控制的实现方法也无所谓不好
10、。可是开发人员不是普通用户啊，他们依然要改造计算机成为自己的工具的。在 现有的现有工具不能解决问题的时候，要不然自己重新发明轮子，要不然就复 用 现有的一些工具，或者重新按自己的需求重新配置这些工具。 所以，和一 般用户不一样，开发人员需要这些 GUI 的可配置性，也需要这些 GUI 程序之 间的互联互通。 用黑话来说，第一个问题关系到 GUI 应用程序的脚本化， 第 二个问题关系到 GUI 程序之间的进程间通信。 这两个问题，说起来简单，但 都牵扯到 GUI 系统的根本设计问题。 历史在这里开了一个不大不小的玩笑， 把这个唯一的机会给了 Mac OS X。其他操作系统，都因为这样那样的原因，
11、在 这两个问题上没有很好的解决方案。进程间通信，苹果的方案进程间通信，苹果的方案花开两朵，各表一只。我们先说 GUI 程序的进程间通讯的问题。 所谓的进程 间通信 （IPC），就是两个程序之间的信息共享。 我们都知道，*nix 的一个 强大之处就在于管道，管道是最简单，最廉价也是最常用的 *nix 进程间通信 的方法。在 GUI 时代，最常用的 IPC 机制成了剪切板和鼠标拖放操作。这两 个操作虽然都很直观，但都要人操作，离开了人，程序根本无法自动完成进程 间通信。 而要工作效率的提高，就是要让计算机离开了人的干涉，也能完成这 些任务。为了自动化这些任务，操作系统就不能简单的绘制窗口然后万事大
12、吉 了，它必须要知道 哪些程序在运行，哪个运行的程序可以给哪个程序发消息通 信等等，比如说，如果我们想自动的在阅读器里面选择一个词送给字典程序查 释义，计算机就需要知道字 典程序在运行的时候可以接受一个字符串，但是不 可以接受图片。如果我们把字典程序抽象成一个可以提供“查字典”服务的对 象的话，毫无疑问，如果想要向字典 程序发送字符，必须首先知道字典程序能 够接受什么，用什么方式把这个单词发送给字典等等。 所有的这些信息，都必 须由操作系统托管才行（不可能每个应用程序里面都要记着字典这个程序能接 受字符串不能接受图片，这样每个应用程序都要记下所有其他可能的应用程序 的信息，这是一个平方级别的关
13、系，需要开发人员开发一个程序的时候还要兼 顾其他所有程序，这显然是不现实的）。 用行话来说，必须要有一个统一管理 的运行环境，来管理这些程序之间的互相通信问题。 我们上面说了， Smalltalk 的神在于一个统一的面向对象的运行时，使得所有的应用程序能互 联互通。 可是所有平台上的 GUI 程序的演化进程都没有走这条路，而是只把 外表给模仿走了；有的平台即使想做互联互通，也做得不彻底（比如微软的 OLE，COM 等等）。是好东西，总会发光的。 但是要想让这个好东西被新的操作系统全盘采纳，要 想让一个系统能够从底层到上层全部采用统一的运行环境，就要扔掉很多的历 史包袱。甩掉这种历史包袱，对于
14、任何操作系统都是不容易的。如果我们回到 当年，一定会幻想，要是有个神人，能够不管市场也不管现有平台，从头打造 一个没有任何历史包袱的干净整洁的 GUI 系统该多好。 历史就是这么戏剧， 还真就安排了一个人，做成了这件事情，这个人，就是那个斯蒂夫乔布斯。1985 年，乔布斯被苹果扫地出门，成立了 Next 公司， 一心想要做出质量上 乘的 GUI 计算机系统。 历史给了乔布斯一个全部从头做的机会。这一次，乔 老师和 Next 的开发人员意识到，光照搬 Smalltalk 的形是不行的，要连它的神也拿过来，重头设计进程间通信和 GUI 系统。 在内核层面，他们用了 Mach 这个为 BSD 设计的
15、微内核。 这个操作系统内核就是为了替换已经过时的 UNIX 内核而设计的，其中的一个核心设计哲学就是重新设计进程间通信； 虽然现在 基于微内核的操作系统已经不是什么潮流（为此 Linus 和 Tanenbaum 吵了一 场著名的架)，但在相比较于当时 UNIX 系统的内核（此时 Linux 还没出现的， UNIX 内核只有 BSD， Bell, SUN 等几套），Mach 算是一个高的起点。在这个 内核上，Next 公司的工程师开始构建面向对象的基础系统。 这套系统在 Smalltalk 中已经有了蓝图，因此这些工程师以 Smalltalk 为蓝图，先设计了 一套基于 C 的语言，也就是 Ob
16、jective C，照搬了 Smalltalk 的经典的 对 象 消息: 参数 语法。 (我个人不喜欢 Objective C 这个语言，Smalltalk 是一种纯面向对象的动态类型的语言，Next 公司当年完全有机会用 Smalltalk 语言的，如果用了 Smalltalk，现在的 Cocoa 框架还会更加漂亮，代码更加干 净；用 Objective C 这个自创的语言，不知道是不是因为专利的考虑，反正 Objective C 这 20 年的所有创新，就是在慢慢的更像 Smalltalk 而已，Java 和 Ruby 这几年也是不断的从 Smalltalk 拿东西）。 有了内核，有了语言， Next 构建了一个纯的面向对象的运行环境和类库（和 Java 和 .Net 的统一类 库想法类似，只不过超前了十几年)， 这套类库，在当时叫做 NextStep, 所以 所有的类名前面都带有 NS 前缀，无比丑陋。可惜的是，当年这个超越时代的 类库太阳春白雪了，话说 Smalltalk 超越了时代 20 年，所以 90 年代中
