Tinyfool 筆頭很快，當即就寫了壹篇長文章《為什麽我認為每個程序員都應該用Mac OS X？》， 我則筆頭很慢，今天才全部碼好。 他的文章的主要切入點在於 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 機制成了剪切板和鼠標拖放操作。這兩個操作雖然都很直觀，但都要人操作，離開了人，程序根本無法自動完成進程間通信。 而要工作效率的提高，就是要讓計算機離開了人的幹涉，也能完成這些任務。為了自動化這些任務，操作系統就不能簡單的繪制窗口然後萬事大吉了，它必須要知道哪些程序在運行，哪個運行的程序可以給哪個程序發消息通信等等，比如說，如果我們想自動的在閱讀器裏面選擇壹個詞送給字典程序查釋義，計算機就需要知道字典程序在運行的時候可以接受壹個字符串，但是不可以接受圖片。如果我們把字典程序抽象成壹個可以提供“查字典”服務的對象的話，毫無疑問，如果想要向字典程序發送字符，必須首先知道字典程序能夠接受什麽，用什麽方式把這個單詞發送給字典等等。 所有的這些信息，都必須由操作系統托管才行（不可能每個應用程序裏面都要記著字典這個程序能接受字符串不能接受圖片，這樣每個應用程序都要記下所有其他可能的應用程序的信息，這是壹個平方級別的關系，需要開發人員開發壹個程序的時候還要兼顧其他所有程序，這顯然是不現實的）。用行話來說，必須要有壹個統壹管理的運行環境，來管理這些程序之間的互相通信問題。 我們上面說了，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% 的程序間的拷貝粘帖都是可以避免的。等等。 這幾年，這些系統終於開始統壹管理壹個面向對象的運行環境了。可是這兩個系統都是用C++ 所寫，所以免不了費很大的力氣才有了運行時信息，繞了壹個大彎路，如果壹開始這兩個系統就用 Smalltalk 之類的有運行時的語言編寫，至少現在應該有能和 Cocoa 抗衡的框架。第二， 這幾年 X 也認識到了在腳本化控制上面的不足，所以幾年前做桌面的 Redhat 提出了 DBus 標準。 可惜的是不是每個程序都開放了 Dbus 接口，所以和蘋果比起來，還有比較長的路要走。
上一篇:cointegration下一篇:什麽是郵箱