開發人員的趁手工具
對於開發人員來說，所有的開發工具的最大的用途，就是最大限度的提高開發人員的生產率 (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 原本是施樂的 Alan Kay 那一幫人做科研做出來的，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 系統的根本設計問題。 歷史在這裡開了一個不大不小的玩笑，把這個唯一的機會給了 Mac OS X。其他作業系統，都因為這樣那樣的原因，在這兩個問題上沒有很好的解決方案。

程序間通訊，蘋果的方案

花開兩朵，各表一隻。我們先說 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 的語言，也就是 Objective 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 年代中期的時候， 程式設計師才想起來當年 Smalltalk 的好，出現了 Java Ruby 等等受  Smalltalk 啟發的語言。 喬老師雖然落後了 Smalltalk 5 年，卻領先也業界 5-10 年，所以在 1995 年的時候， Windows 95 賣瘋了， 喬老師的 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 年釋出的 Mac OS X, 是蘋果作業系統的第十代，完全基於了喬老師在 Next 開發出來的那套類庫，所以自然的，具有了一個統一的面向物件的執行時。 這個執行時和類庫系統，Mac OS X 把它叫做 Cocoa。其實 Mac OS X 剛出來的時候也不怎麼好，不過依賴於這套設計精良的底層系統，Mac OS X 的迭代開發週期要比其他作業系統短多了 （僅慢於Linux, 不過 Linux 只有核心部分). 在短短的 8 年裡，Mac OS X 就搞出了 7 次大的版本釋出。 雖然我們看 Mac OS 好像從 10.0 到 10.6 只是次版本號在進步， 其實每次都是一個 major release, 大致相當於從 Window 95 到 Windows 98 或者 Windows 2000 到 Windows XP 這樣級別的升級。 這樣的釋出卻不改主版本號，一方面是從市場上考慮，另一方面也的確說明 OS X 的底層已經處於一個相對穩定的狀態。 有很多 Windows 程式設計師非常推崇 .Net。 是的，.Net 的確是一個非常好的框架，可是想像一下，蘋果在1995年的時候就有了一個統一的執行時，加上這麼多年所有的程式都在這個統一的框架上開發，如果論在 Mac OS X 這個平臺上的經驗積累，應該說 Cocoa 社群是比 .Net 社群更加成熟的。