重磅級科技文章大多出自有軟件開發背景的作者，須滲入底層才知道事情的始末，計算機世界絕對是這樣的。平臺技術橫向比較的文章我所見不多，也許開發者都清楚，但少有人寫出來吧。

2005 年 John Siracusa 連發三文，預測蘋果將會遭遇平臺危機。未想 iPhone 的興起延遲了危機的發生，5 年后，他發文檢討，但仍認為，不跨越內存管理的障礙，危機仍將隱現。

　　預測科技業的未來是件棘手的事情 — 不妨看看比爾·蓋茨十五年前的預測結果 — 雖如此，預言的誘惑總是強烈的。我亦因此聞名。有時候我猜的挺準，2008 年時我說「蘋果和 Adobe 之間只有戰爭。」含糊、幽默式夸張、不明確的時間表是成功預測的基本要素。

　　其他時候，我就沒有這么幸運了。五年前，我寫了題為《別在2010年重蹈Copland的覆轍》的系列文章，分三篇發出。但這一次，預測的內容既嚴肅又具體，而且標題中還有年份。換言之，想不失敗都難了。好吧，2010 年已經來到 —曾經的那個未來！ — 所以，是時候挨批了…或者，這可以算烏鴉嘴的勝利么？但重要的是，「Copland 2010」究竟說的是什么呢？

　　背景

　　蘋果曾數次嘗試開發新一代操作系統，Copland 是幾個項目中最聲名狼藉的一個。Copland 始于上世紀 90年代，「新一代」是指支持內存保護和搶先式多任務，當時的 Mac OS 不支持這兩項功能。從那時起，Copland見證了蘋果從近乎崩潰，到承認并及時解決其軟件平臺重大的技術差距。通過這次不可思議的收購 — 一款獨立發展的現代操作系統、一個被驅逐的公司創始人— 蘋果得以留存下來。

　　《別…》的第一部分，我提出了我的論點：Objective-C 語言和 Cocoa API 是Mac OS X中最危險的部分，因為它們落后于競爭，而到 2010 年，蘋果會發現自己面臨著另一個 Copland 式的危機，因為它缺少內存托管語言和 API。在第二部分，我詳述了我的假設。分別是：

• 桌面操作系統的開發環境終將提供全自動內存管理功能。
• 到 2010 年，其他對手將會采用支持全自動內存管理的語言和 API。
• 而現有的技術（2005）與可能的演進，無法充分滿足蘋果對內存托管語言和 API 的需要。

　　這些假設受到了強烈的質疑。

　　在第三部分，我評述了那些有可能超越 Objective-C 和 Cocoa 的語言及 API。我也試著鼓勵質疑「2010 年」的人們，觀其大局。

畢竟，人人同意 Cocoa 和 Objective-C 總會過時。好吧，也許有人認為，這一天得等到 2050 年，但總有一天，對不對？用什么替代 Cocoa？有什么可以替代 Cocoa？蘋果在編程語言和 API 之戰中的新動向是什么？

　　在文章中，我認為支持垃圾收集機制的 Objective-C，Java/JVM，C#/.NET/Mono，抑或之前蘋果鮮為人知的嘗試（例如Dylan）皆因種種實際的、技術的或派系的原因，無法承此重任。那么，我認為，蘋果便只能盡快并獨辟蹊徑的尋求或開創 Cocoa/Objective 的繼任者了。

　　未來已至

　　那么，結果如何？若逐字對照，結論很明確：蘋果并未經歷 Copland 式的平臺危機。雖然它或許處在另一類非常特殊的危機之中，不過，這是另一回事了。就華爾街的態度（以及蘋果的資產負債表）而言，未來仍舊是光明的。

　　是我大錯特錯了嗎？還是沒有？不妨再看看我的假設。自動內存管理已經普及了嗎？大多數 Mac OS X 開發者并不這么認為。Objective-C 確實加入了垃圾收集機制，蘋果也很努力的推廣。但是，五年前我提到的「二等公民問題」并未消散。大多數Cocoa 開發者，包括蘋果自己，在多數程序中，仍舊采用手控維持與釋放式的內存管理。對時下的麥金塔開發者而言，垃圾收集并非上選，并可能危及性能。

　　微軟在 .NET 框架和 C# 語言上使用默認的內存管理代碼，其他的內存管理代碼則視為存在風險，并以「unsafe」為關鍵字標注在源代碼中。

　　盡管如此，開發者和用戶并沒有像 Copland 時代那樣的恐慌。如果危機正待，那絕不是現在。這就是所謂「2010」。但僅此而已么？

　　未來未來

　　微軟從十年前開始著手 .NET 的通用語言運行庫。期間發布了四個主要的版本，顯著拓展了 C# 的功能，亦提供了對動態語言，如 Python 和 Ruby 的支持。如果這是開發平臺間的競爭，那么從技術上講，蘋果處下風。

　　盡管如此，開發者仍無動于衷。原因可概括為三個詞：移動，移動，移動。iOS（原 iPhoneOS）的崛起令人頭暈目眩。在臺式機上多年不見得配置重新出現：128 至 256MB 內存，1GHz定序處理器，無虛擬內存。十幾年來，蘋果從沒在臺式機和筆記本電腦上用過這么小的內存，不支持虛擬內存？那是多遙遠的事情啊（編者：1991 年System 7 開始支持虛擬內存，作者意指，初代麥金塔不支持虛擬內存也就罷了，現在已經過去 26 年了還……）。哦，對了，iOS 不支持 Objective-C 的垃圾回收。

　　硬件受限，習慣了高級語言的蘋果開發者必感不便，而 Objective-C 乃 C 的超集，趁此終可大顯身手。當你的程序持續不斷的收到系統發送的低內存警告；當你不得不與低級語言、字節級精度的指針與 C 結構打交道的時候，你怎么嗨的起來？

　　蘋果夸大了移動設備用戶界面響應能力的重要性。為維持直觀流暢的用戶界面，蘋果無所不用其極，這招讓 iPhone 脫穎而出。即使在今天，那滾動列表或劃過屏幕的短暫延遲，雖然難以捉摸，卻能顯而易見的將 iPhone 與其他手機區分開來。內存受限，開發者雖無能為力，但似乎暗喻了暢快的界面與 iOS 原生 API 的底層特性之間的某種聯系。（編者：蘋果：趕快學習低級語言啦。）

　　實際的檢驗

　　還有一個問題。就像它在桌面端最大的競爭對手（編者：微軟），蘋果在移動市場中最強力的挑戰者也提供了內存托管語言和 API。毫無疑問，Android 最新版的 Dalvik 虛擬機速度很快。（我曾預言寄存器型虛擬機將成主流，現在是不是能討點賞了？）

　　更糟糕是，谷歌甚至利用了蘋果開發多年的底層庫，增強自家設備的性能，還在 Google IO 上用 Android 手機修理了一把看似無比強大的 iPad。是的，WebKit 是用 C++ 寫的。這正是要點：提供高級 API 并不能阻礙高性能底層庫的應用。

　　不僅是谷歌。微軟也不出所料，推出移動 .NET 平臺，并為 Windows Phone 7 增加了更高層級的語言和 API。即便不幸如 Palm，亦為開發者提供了更為抽象以及安全的開發環境。 這正是蘋果所面臨的競爭圖景。

　　顯然，在衡量成敗方面，技術細節并非如此重要。即便 Mojo SDK 閃耀一時，也難以避免 Palm 的慘淡結局。但是，最能挑戰蘋果一枝獨秀的用戶界面的，仍然是 WebOS。谷歌仍然健在，當然，它不會好到哪去。而微軟…嘿，你永遠不會了解的，對不對？

　　個別競爭者的命運暫且不論。事實上，這些最危險的對手手中，都有領先蘋果一世代的語言和 API，這才是最危險的信號。而且，這還是發生在內存食緊、處理器受限的移動世界。在桌面平臺，蘋果落后更多。

　　2010 終于來了。不管「未來」到達與否，開發者為了一個損壞的指針不斷的遍歷內存，多少是有些愚蠢的事情了。世界已經改變，蘋果亦應順勢而為。

　　比以往更緊迫

　　哦，我知道你在想什么。你們這些 Cocoa 開發者定會認為我失去了理智。你們說：Cocoa 和 Objective-C是蘋果最叼的東西，才不是定時炸彈！而且，盡管源于 C 語言，但 Objective-C 提供了 Java 都還不支持的動態性能和語言特性，因此，說它「低級」是不公平的。還有啊，不要忘了垃圾回收機制，iOS 總有一天會支持。

　　無論如何，你認為，這一切都不重要。何況空談不如實踐：誰的程序更好？誰的用戶體驗最棒？誰賺的錢更多？而且蘋果的桌面或移動平臺的種種缺陷沒有影響到什么嘛，看起來一切正常！

　　開發界有句老生常談，在程序員中奉作經典，不妨援引：你習慣何種抽象層級的編程語言，那么這種語言就是最合適你的語言。視低級語言過于原始，高級語言臃腫耗能。在全行業抽象度愈加高聳的今日，仍是如此。

　　首先，如今寫 C 的同學大概沒人會用匯編了，但 C++ 虛表調度的速度還是太慢，難于采納。接著，C++黨也許會懊惱的追憶起當年是如何將他們半殘的對象系統嵌入 C 中的，但他們卻很鄙視 Java。再后來，Java 黨開始嘲笑指針和手動內存管理，但 JavaScript 卻被諷刺為玩具級的腳本語言，干一些驗證網頁表單的粗活。諸如此類…

　　在短期內，在當下，他們大多是正確的。但，這是條不歸之路，而且，正指向愈加抽象的層次。下一次跨越何時到來，不妨觀察業界的前緣。蘋果通過 iPhone 的成功為自己爭取到了一些時間，但以目前競爭之慘烈，這也許僅僅是一廂情愿。

　　轉換之難

　　盡管「2010」危機沒有到來，蘋果最終仍需面對該問題。我關注這個問題的原因，無論在5年前，還是現在，都是一樣的，即：開發平臺很難改變。首先，選擇或開發一門新語言，并為其打造一套新的 API 存在技術難題。優秀的 API 需要多年的發展和累積。Cocoa 就是個好例子。

　　不幸的是，寄望將現有的 API 導入新的高級語言和運行環境，并能正常工作，幾無可能。轉用高級語言能減少原 API 復雜度。例如：

NSInteger myCount = [[myDict objectForKey:@"count"] integerValue];
NSArray *myArray = [myString componentsSeparatedByString:@","];
myItem = [myArray objectAtIndex:i];

　　不可能在這樣的語言環境（假設）中運行：

myCount = myDict["count"];
myArray = myString.split(",");
myItem = myArray[i];

　　只有新的 API 才能更好的匹配新的語言。但與下一個問題作比，這還算簡單的，即：勸導開發者轉向新的語言和 API 而不影響現有平臺的勢頭。即便技術選擇完全正確，開發者也愿意隨你前行，平臺的轉換仍需花費時間與精力，無論是平臺供應方，還是開發方。與此同時，競爭對手的現有平臺正值壯年，它們無需為平臺轉移而苦惱。而且，當你正辛苦的切換平臺之時，它們還能借此獲得增長。

　　如果你只是一個普通的用戶，恐怕難以理解我對此的恐慌。如果你是開發人員，就像本文開篇談到的那樣，你也許對我嗤之以鼻。沒有關系。我也同意，我的諸多擔憂是一種過激反應，但這恰是因為我真實的經歷過 1990 年代那場傷筋通骨的 Copland 危機，并且，眼睜睜的看著蘋果因此近乎覆滅。

　　無疑，蘋果今非昔比。但是這類技術問題，無論多么艱巨，一旦無法解決或被完全忽視，那就只會引發危機。過去的十多年間，一旦蘋果開始解決某個問題，它就會做的非常非常好。因此，我們有理由樂觀。但并非完全如此。

　　了解而又熱愛 Objective-C 和 Cocoa 的最大群體在蘋果公司里。而這些人亦可能不那么熱衷于推動新的語言和API。再加上蘋果的脾性 — 例如其對軟件商店的態度 — 不管外界爭議如何，只要認定是最佳做法，便會一意孤行。而且，有許多因素妨礙著蘋果深入思考這個問題。

　　雖然微軟近年來的產品線不夠協調，但它有所預見并愿意解決其最深層的技術問題，值得嘉許。微軟早在蘋果意識到這個問題數年前就開始研究現代操作系統，因而避免了 Copland 式的危機。微軟開發了 Windows NT，并通過數次更新，細細雕琢，才將 NT推向消費級操作系統。（編者：即 Windows XP。）

　　即便如此，微軟還是來遲了。當時 Java 已嶄露頭角，而微軟還牢牢的固守在 C++ 陣營，但微軟應變極快，投入了可觀的人力與資源，推廣其.NET 虛擬機和 C# 語言以彌補差距。技術上不夠自信的公司也許會選擇另一條道路。它們會爭辯：我的語言和 API 有其優勢，沒什么要改進的啦。換言之，「忽略問題，問題便會消失。」

　　你有多了解蘋果對 Objective-C 和 Cocoa 的態度？以上這些情景會讓你想起什么嗎？

　　實際的檢驗，之二

　　再一次的，讓我猜猜你的反應吧。「別用你對技術的擔憂嚇唬我們。」微軟不是很用功嗎？開發了一整套多語言運行環境，也沒能幫助他獲得多少移動市場的份額嘛，而且除 Windows/Office 之外，這套體系也沒能助其開疆擴土嘛。說的沒錯。像微軟這樣成功解決了技術問題，并不能保證其他方面也成功，也不能保證從此穩坐泰山。

　　讓我們回顧上一節末尾的問題：對于我們這些身在蘋果之外的人，有誰真正了解蘋果對 Objective-C 和 Cocoa 的態度，有誰知道他們對未來的規劃？在我發表 Copland 一文不久之后，有關蘋果參與 LLVM 計劃的細節開始浮出水面。那么LLVM，抑或，目前的Clang，是蘋果平臺演進的長期策略嗎？雖然，蘋果的狀況尚可，但是，為達到目標，要做的改進遠比這些多得多。也許他們已經動手了，我們只是不知道罷了。

　　我曾經千思萬想，希望蘋果早日動手。如果我有具體的解決辦法，相信我，定當竭力推進。但是，目前我所了解的，蘋果用于保護其老舊平臺技術的辦法是…

　　你尋到 Web，他會給你自由

　　采用其他平臺供應方的 API，就等于將命數交于他人之手，蘋果不會這么做。蘋果大概不能忍受自家平臺構建在，由競爭對手主導開發或完全控制的程序語言之上。那么只剩兩種選擇：要么自己從頭做起，要么尋找一個無供應方的解決方案 — 即不受任何單方的控制。

　　現觀之，蘋果似乎選擇了后者，它開始大力投資 Web 技術。啊！是的，Web，無可爭議的自由平臺！蘋果得到了Webkit，成功打入瀏覽器引擎之戰（至少在移動市場是這樣。）并借此宣揚，這才是先進的網頁標準。（盡管有時候做錯了）此外，蘋果在其新近的網頁程序中使用了 SproutCore HTML5 程序框架，還有 PastryKit，這是蘋果研發的數款網頁框架之一，現已開始部署。

　　采用 Web 技術巧妙解決了蘋果的許多潛在問題。無須推出震驚世界的程序語言和API，蘋果已將整個行業引入它的軌道中來。Web 不由任何一方控制，但蘋果似乎比任何一家公司都更盡心竭力。

　　不幸是，這意味著，蘋果仍無法掌控一切。此外，Web 技術離目前 GUI 程序的水準還有很長的距離。大多數有經驗的 Cocoa 開發者非常清楚二者差距，但他們多少會覺得有些不安。

　　這便是，為何我認為 Web 技術只是蘋果的防御手段 — 它的第二選擇。但倘若我知道它的首選是什么，必定會寬慰許多。

　　自作自受

　　盡管苦悶揮之不去，Copland 2010 終究沒有到來。雖如此，我仍覺得這個問題并未消失，而且隨時間流逝愈加嚴重。當然，作為一個在 5 年前已經因此嚇破膽的人，我對「緊迫」的定義很可能與你的不同。

　　寫這些不是用來離間 Cocoa 開發者的，更遑論 Mac OS X 和 iOS 用戶。我亦無心冷嘲熱諷，好比說，這個平臺要完蛋啦，或者這個平臺就是低人一等，未來已經注定之類的。我寫蘋果已有多年，好處是，可以時而回顧多年前的預測，我也愿意擔負責任。我最痛恨是，技術專家無掛無礙的將多年前他們的可怖禁言棄之腦后。

　　我也試著幫助蘋果，不管是公司決策者能讀到我寫的文章也好，或間接鼓勵開發者，讓他們至少想想這個問題也罷 — 即便他們的理念與我不同。我想善意的提示所有當事人，包括蘋果。即這個問題依然存在，只是潛藏而已。

　　最后，我得承認，我亦喜歡身處迷局。五年前，我不知蘋果的未來語言和API，今天仍是。在這樣的一個世界里，我們多年的期盼一個個成為現實 — 新的操作系統、我們的蘋果手機、我們神話般的平板 — 但語言和API繼任者的問題仍頑固的存續著。這一回，我不再加入年份，但請放心，我仍將觀守并等待。我只是希望我不是唯一的一個。

　　英文原文：Copland 2010 revisited: Apple's language and API future