免責(zé)聲明：整篇文章或者是我的推測與愿望，或者是一篇控告。

介紹：批評Objective-C

程序員，旁觀者和學(xué)者已經(jīng)批評Objective-C好長時間了。

關(guān)于語言和API的抱怨包括缺少多元組，子串(slices)，散列表或者在語法級別類似的結(jié)構(gòu);缺少編程模板;缺少命名空間;方法缺少默認(rèn)參數(shù);缺少運算符重載;不成熟的垃圾回收器(iOS上就沒有垃圾回收機制);冗長的命名轉(zhuǎn)換;缺少包管理;對商用API比如REST、SOAP、SQL等待缺少原生的支持。即使是最經(jīng)常被嘲笑的方法的方括號格式也應(yīng)該改變(或者修正)。

這些孤立的批評都不是代替Objective-C的理由。你可能會說如果Objective-C需要改變這么多方面，那么也許最好的方式就是替換掉整個語言。

但是代替主要的開發(fā)語言對于開發(fā)團隊來說是不悅的。蘋果也不會為了美學(xué)或者極小的特色來做這個事情。代替某一語言的理由必須是更實用和更功能化的。

更為中肯的是一個Objective-C不能修改的特性：關(guān)于C本身的抱怨，特別是C中的指針。

如果說與C在代碼層兼容是Objective-C最好的特性，直接內(nèi)存模型就是Objective-C的最不受歡迎的特性。

直接訪問內(nèi)存模式在正在逐漸消亡

直接訪問內(nèi)存模式，特別是使用C語言的項目正在變得越來越不受歡迎。

根據(jù)下面的表單20個最流行的編程語言(不完全是一個科學(xué)資源，但是也具有說服力)，僅僅32%的人仍然使用直接存儲模式的語言(C,C++,Objective-C，Pascal，Delphi)。在10年的時間里，你可能不會在除內(nèi)核、驅(qū)動、游戲和底層嵌入式軟件之外的項目中看到直接訪問內(nèi)存的語言。

這意味著無論蘋果是否反對直接訪問內(nèi)存的APIs(很可能他們不會)，無論他們是否引入一個新的語言，蘋果的官方程序環(huán)境會具有虛擬存儲模式(an abstracted memory model)。

在存儲虛擬化中的程序虛擬機的作用

技術(shù)上看，當(dāng)前Objective-C的垃圾回收器是一個虛擬存儲模式。但是我把它排除在外因為它不是完全的虛擬存儲模式，而且只要Objective-C包含C指針，那么它就永遠(yuǎn)不會是。

僅僅因為你不需要釋放內(nèi)存，并不意味著不會有其他內(nèi)存問題。你仍然有指針，這些指針仍然可能指向某些東西。你仍然可能數(shù)組越界。你仍然可能使緩沖區(qū)溢出。你仍然可能碰巧重寫了某一個內(nèi)存區(qū)域。甚至可能你使垃圾回收器回收了正在使用的資源。

這是相當(dāng)抽象的漏洞。

不用一個真正意義上的虛擬機來創(chuàng)建一個虛擬存儲模型是可能的(可以參見下面一個不同方式)但是虛擬機允許你鎖住虛擬部分因此不會有任何意外的漏洞。你不再需要指針。你不會輕易地覆蓋內(nèi)存。你無法使數(shù)組越界。你無法是緩沖區(qū)溢出。

虛擬機通過移去提供直接獲取內(nèi)存的指令而實現(xiàn)上述功能。相反，虛擬機上的指令只與對象、屬性和值相關(guān)聯(lián)—你不能獲取內(nèi)存的錯誤區(qū)塊，而且垃圾回收機制相對傳統(tǒng)方式也會是更有效的，因為所有存儲的引用是完全確定的。

關(guān)于我提到的“虛擬機”的定義：“虛擬機”描述一臺沒有直接依附于某一特定機器的計算機，而是映射到某一確定的機器。這種映射正常情況可以通過運行解釋(比如腳本語言)，運行仿真(比如計算機模擬器)或者實時編譯為原始機器語言(比如java的JVM)來實現(xiàn)。無論該“虛擬機”的運行方式如何，關(guān)鍵是程序員只需處理虛擬方案而目標(biāo)機器的確切結(jié)構(gòu)和行為不會直接涉及到。

平臺獨立性

第二個關(guān)于虛擬機的討論與語言關(guān)系不大：平臺獨立性。

蘋果在17年中兩次改變CPU架構(gòu)。不久又將發(fā)生一次。雖然向intel CPUs的改變難以置信的順利(我對它的無縫轉(zhuǎn)變感到震驚)，但還需要相當(dāng)長的時間來等待大部分程序的intel版本以及其他的開發(fā)者來完成全部的轉(zhuǎn)換工作。

考慮到蘋果在iOS設(shè)備上的額外努力，設(shè)想一系列不同的CPUs可以在一套設(shè)備上使用是可能的，fat binaries只能為少量CPUs提供便利。如果蘋果打算使用一系列不同的CPUs，那么單獨的字節(jié)碼運行是唯一的方式。

好的編程應(yīng)該避免代碼只能適用于某一特定的硬件設(shè)備。將CPU和平臺從程序中獨立出來是一個符合邏輯的步驟。

在不同CPUs上運行這個主題，一個有趣的點是蘋果最近確實引入了一個新的平臺獨立的語言：OpenCL，該語言在JIT編譯虛擬機上運行。我無法預(yù)見是否有趨勢要利用OpenCL重新實現(xiàn)Cocoa(這個方式比Objective-C更加神秘)但是實現(xiàn)它的技術(shù)當(dāng)然是存在的。

不利用新語言的虛擬機

需要注意的一點就是在新語言之前可以先引入虛擬機。

如果蘋果判斷對交互存儲管理的恐懼使開發(fā)者望而止步，但是又不準(zhǔn)備一步完成到新語言的轉(zhuǎn)變，先轉(zhuǎn)換到虛擬機(獲得虛擬存儲模式的好處)是可能的，而同時使得代碼層的變動相對更小。

雖然這看起來是個奇怪的事物，但確實有兩項好處。

第一個是在虛擬機內(nèi)運行的Objective-C可以更簡單地與虛擬機外的原始Objective-C建立橋接。如果你記得蘋果曾經(jīng)放棄橋接Java和Objective-C，當(dāng)時最大的技術(shù)難點是Java看待一個對象的動態(tài)執(zhí)行性不如Objective-C，而且Java不能跟蹤在Objective-C這一端方法和指針的改變。橋接一個虛擬機中的語言到虛擬機外的語言在這個模型里是相對簡單的。

第二個是當(dāng)前Cocoa是適合Objective-C特點設(shè)置的。僅使用虛擬機可以保持Cocoa本質(zhì)的相似性，使得蘋果的開發(fā)工作更簡單。

更新：Jesper曾經(jīng)指出這一點而且解釋為什么虛擬化Objective-C同時保持與非虛擬化的Objective-C的兼容性可能不是一個好注意。

簡而言之：，一個虛擬化版本的Objective-C(比如它之前的C++.NET)需要移去大量的語言特性或者它需要拋出運行異常如果你的代碼違反了一系列的規(guī)則(相當(dāng)于沒有解決虛擬存儲問題)。

一個不同的方式

當(dāng)然，僅僅因為上面所提到的優(yōu)點，并不意味這虛擬機肯定就是Mac 開發(fā)改善下一個步驟。

確實存在可編譯，垃圾回收，存儲安全的不需要虛擬機的語言，該語言完全滿足虛擬存儲模式的要求，：Google’s Go language就是一個例子。

讓蘋果接受Go是不可能的。不要提Go還在開發(fā)，一個問題就是Go不能與Objective-C橋接。實際上，Go目前還不能輕易地與C或者C++橋接。

確實轉(zhuǎn)移到一個類似Go的語言上來需要一個空白間斷，即會有向前的兼容性的問題。這個間斷是可能的(Carbon引入到Cocoa就是這樣一個間斷)，我認(rèn)為更可能的方式是蘋果會選擇通過使用自定義語言或者某一已存語言中的自定義變量來保持一定的互用性。我這樣懷疑的原因是蘋果曾經(jīng)有機會來代替Cocoa(在iOS上)，但是它選擇保持原有設(shè)計。我懷疑他們已經(jīng)決定在未來Mac上繼續(xù)使用Cocoa，即使語言和環(huán)境已經(jīng)改變了。

虛擬機能夠提供的更好的向前兼容性，橋接性和可移植性在加上現(xiàn)代JIT出色的運行能力，導(dǎo)致我認(rèn)為非虛擬機的選擇不能提供足夠的靈活性而且非虛擬機的方式帶來的優(yōu)點并不足以抵消語言改變而帶來不便。

結(jié)論

顯然，我熱愛Objective-C和Cocoa;我確信從我的博客和關(guān)于它的特點的辯論文章可以明了我的觀點。我并不同意上面所列出的大部分的批評。我認(rèn)為這些批評是淺薄，或者他們太哲學(xué)化了而且技術(shù)上被誤導(dǎo)。

但是Mac開發(fā)者無法對抗一個勢不可擋的完全虛擬化存儲模型的趨勢，這個趨勢已經(jīng)在Mac相關(guān)開發(fā)之外大范圍的展開。

更進(jìn)一步，我不認(rèn)為朝向虛擬機的趨勢是值得去反抗的。當(dāng)前Cocoa和Mac編程的主要特色：關(guān)注細(xì)節(jié)，widget運行方式，方法，類和APIs都不會改變。實際上，大部分Cocoa仍然可以保持原樣。

最終我確信Apple會轉(zhuǎn)向一個新的語言;

現(xiàn)在真得不用著急做這些。當(dāng)然iOS設(shè)備目前不需要這些。甚至是在Mac上，我認(rèn)為在某些事情發(fā)生之前，還會有幾年的警示和準(zhǔn)備，當(dāng)最終發(fā)生時不需要強制的轉(zhuǎn)變。

當(dāng)我說目前不用著急，我意味著：我認(rèn)為在10年之內(nèi)，你仍然可以為Mac發(fā)布新的，非虛擬機的，Cocoa/Objective-C開發(fā)的程序(同時，如果你愿意你仍然可以寫Carbon程序)。我只是不認(rèn)為Carbon會是最普遍的選擇。