［薦］［轉］爲什麼應該使用 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從入門到精通》