開發人員為何應該使用 Mac OS X 兼 OS X 小史—強烈轉帖，寫的實在太贊

轉自：http://blog.youxu.info/2010/02/28/why-mac-os-x-for-programmers/

一周前我和 Tinyfool 閑聊蘋果作業系統，都認為對於開發人員來說，蘋果作業系統（Mac OS）是上佳的選擇。 Tinyfool 筆頭很快，當即就寫了一篇長文章， 我則筆頭很慢，今天才全部碼好。 他的文章的主要切入點在於 Mac 平台作為目標開發平台的優勢，而我這篇的切入點主要是 Mac OS 作為一種開發工具的優勢。

開發人員的趁手工具
對於開發人員來說，所有的開發工具的最大的用途，就是最大限度的提高開發人員的生產率 (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 機製成了剪下板和滑鼠拖放操作。這兩個操作雖然都很直觀，但都要人操作，離開了人，程式根本無法自動完成處理序間通訊。 而要工作效率的提高，就是要讓電腦離開了人的幹涉，也能完成這些任務。為了自動化這些任務，作業系統就不能簡單的繪製視窗然後萬事大吉了，它必須要知道哪些程式在運行，哪個啟動並執行程式可以給哪個程式發訊息通訊等等，比如說，如果我們想自動的在閱讀器裡面選擇一個詞送給字典程式查釋義，電腦就需要知道字典程式在啟動並執行時候可以接受一個字串，但是不可以接受圖片。如果我們把字典程式抽象成一個可以提供“查字典”服務的對象的話，毫無疑問，如果想要向字典程式發送字元，必須首Crowdsourced Security Testing道字典程式能夠接受什麼，用什麼方式把這個單詞發送給字典等等。
所有的這些資訊，都必須由作業系統託管才行（不可能每個應用程式裡面都要記著字典這個程式能接受字串不能接受圖片，這樣每個應用程式都要記下所有其他可能的應用程式的資訊，這是一個平方層級的關係，需要開發人員開發一個程式的時候還要兼顧其他所有程式，這顯然是不現實的）。用行話來說，必須要有一個統一管理的運行環境，來管理這些程式之間的互相通訊問題。 我們上面說了，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 社區更加成熟的。

應用程式指令碼化

光有處理序間通訊的系統還不能算是一個完全成熟的 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 的新技術，蘋果一口氣在 Mac OS X 上推出了 Safari, iTunes, iPhotos 等等軟體，一股腦兒的全部指令碼化了。 在別的公司都可望而不可求的曆史機遇，又是被蘋果給抓住了，一股腦兒全部塞進了 Mac OS X。這下，所有的第三方開發的工具，如 Firefox, Adium 這些，其實本來都不是蘋果開發的，也沒有太強的蘋果淵源，但是 Firefox 要讀 Safari 書籤吧，哈，那就用 Applescript 吧，所以， Firefox 也逼著指令碼化了（這個在其他平台上都不存在的事情）。
Adium 也是，這個聊天軟體想要把 iTunes 現正播放的歌曲當成狀態資訊，好呀, Applescript，所以，也被帶著指令碼化了，而在 Linux 上的對應產品 pidgin 就沒有這麼指令碼化。 所以，蘋果平台已經成了一個慣性，你不想指令碼化，就不帶你玩，看你還指令碼化不？

結語

我們都知道， UNIX 時代的主要哲學是提供給開發人員一組小巧精美且可以任意搭配使用的小工具，也就是所謂的 Software Tools, 然後任由開發人員由此出發，自己搭建自己的工具，打造自己的瑞士軍刀。而開發人員所用的作業系統的目的，要不就是提供這樣的一組開發工具，要不就是為這樣的開發工具提供一個便利的平台，使得這樣的工具變為可能。如果說 UNIX 是命令列時代的一個易於改造成 “自己的作業系統” 的作業系統的話， Mac OS X 就是 GUI 時代的這樣的一個作業系統。 即使是從應用軟體的層面看，
Mac OS X 的底子好，更加容易出精品軟體，所以即使僅使用應用軟體，開發人員也應當優先考慮 Mac OS X。

附A: 相對正確的 Mac OS X 使用習慣

0. 一定要裝 Quicksilver 或者用“服務”，否則就是把蘋果當 Windows 用。
1. 在蘋果電腦上，因為有服務和 Quicksilver 這樣的工具，90% 的程式間的拷貝粘帖都是可以避免的。
2. 剩下的 10% 的程式內的拷貝粘帖，如果用一個好的編輯器的話，又可以省略掉 90%。

附B： 為什麼 Linux 系統在這個方面還不夠好

第一， Linux 上的 GUI 子系統，其實不是 Linux 的一部分，而是 X 和上面的 KDE 以及 Gnome
等等。 這幾年，這些系統終於開始統一管理一個物件導向的運行環境了。可是這兩個系統都是用C++ 所寫，所以免不了費很大的力氣才有了運行時資訊，繞了一個大彎路，如果一開始這兩個系統就用 Smalltalk 之類的有運行時的語言編寫，至少現在應該有能和 Cocoa 抗衡的架構。

第二， 這幾年 X 也認識到了在指令碼化控制上面的不足，所以幾年前做案頭的 Redhat 提出了 DBus 標準。 可惜的是不是每個程式都開放了 Dbus 介面，所以和蘋果比起來，還有比較長的路要走。