在許多年前，“語言”就等同于“平臺”，例如C，C++以及最早的Ruby和Python等等。但是隨著技術(shù)發(fā)展，出現(xiàn)了一些通用的平臺，例如.NET和Java，逐漸這些平臺上的語言也越來越多。再后來，某些語言在不同平臺上的實(shí)現(xiàn)也越來越多，事情也變得有些復(fù)雜。技術(shù)在發(fā)展，但是從目前社區(qū)的討論中，我發(fā)現(xiàn)許多朋友的觀念還沒有跟上。簡單地說，如今的觀念，一定要從“語言即平臺”切換成“語言及平臺”，當(dāng)分清“語言”和“平臺”這兩個不同事物之后，許多問題才能討論地清楚。
例如我寫過一個太監(jiān)系列《Why Java Sucks and C# Rocks》，其中談的是C#和Java兩個“語言”而不是兩者的“平臺”。編程“語言”其實(shí)是一種“規(guī)范”，它涉及了程序員在使用這門語言時的文本表現(xiàn)形式（這里暫不考慮其他形式的語言），而“平臺”則包括對這個規(guī)范的“實(shí)現(xiàn)”（廣義的“平臺”還包括整個生態(tài)環(huán)境等等）。C#和Java分別處在各自的平臺上，但許多語言其實(shí)是跨多種平臺的。例如Python，Ruby，Scala，Clojure，JavaScript等等，數(shù)不勝數(shù)。同樣，一個平臺上也會出現(xiàn)多種語言。而且事實(shí)上，由于.NET和Java這樣的平臺越來越成熟，語言的設(shè)計及實(shí)現(xiàn)者也都越來越傾向于讓語言運(yùn)行在“某個平臺”上。這么做可以盡可能地利用前人的成果，而不是什么都要自己從頭做起。
其實(shí)基本的原則就是這么簡單，但是真正在考慮問題的時候，可能就不是那么容易了，我們必須時刻保持清晰地頭腦。
例如有個人說“C#比Java執(zhí)行效率高（或低）”，這個說法是否正確？其實(shí)這種說法有很大問題。因?yàn)槲覀冎�，在這里C#和Java都是“語言”，它們的執(zhí)行環(huán)境CLI及JVM一樣都是“規(guī)范”，但“執(zhí)行效率”是一種表現(xiàn)，這和“實(shí)現(xiàn)”得如何有很大關(guān)系。例如，C#是運(yùn)行在.NET平臺還是Mono上（它們都是CLI規(guī)范的具體實(shí)現(xiàn)），Java是運(yùn)行在JRockit還是Hotspot（前者是Oracle的JVM商業(yè)實(shí)現(xiàn)，后者是Sun的開源實(shí)現(xiàn)——當(dāng)然現(xiàn)在也是Oracle的），亦或是Android的Dalvik上？很顯然，不同實(shí)現(xiàn)之間的表現(xiàn)會有區(qū)別，不可一概而論，否則也不會出現(xiàn) JavaScript引擎的效率之爭了。同理，有些人使用Hotspot上的Java性能來說明Java在Android上運(yùn)行時的表現(xiàn)，這也是不對的 ——要知道Google在和Oracle的Java專利官司中不斷強(qiáng)調(diào)Dalvik不是“Oracle那種Java”。作為結(jié)論，Java在 Android上的表現(xiàn)的確不錯，但論證方式也必須正確才行。
當(dāng)然，有時候“規(guī)范”也會影響到“實(shí)現(xiàn)”，例如一個動態(tài)分發(fā)的語言，其性能基本百分百不如在編譯期綁定的靜態(tài)語言。所以事情原本就是這么復(fù)雜，做一個思路清晰的程序員并不是件容易的事情。順便一提，女人在這方面的頭腦一般都比較清楚，她們一般都知道騎白馬的不一定是王子，也有可能是唐僧。
對于俗稱“.NET程序員”的那一批人來說，分清“語言”和“平臺”更是一件十分重要的事情，因?yàn)镃#語言可以說是目前“平臺”、“實(shí)現(xiàn)”最為廣泛的“語言”之一了。之前我為InfoQ寫過一篇文章，其中提到Mono的創(chuàng)始人Miguel de Icaza給出的目前C#語言可執(zhí)行平臺的“不完全”列表，幾乎覆蓋了各種流行的操作系統(tǒng)及設(shè)備等等，例如：
* Windows
* Mac OS
* Linux / BSD / Solaris
* Windows Phone，Android，iOS
* XBox 360，Wii，PS3
* ……
因此就拿C#這一種語言來說，“實(shí)現(xiàn)”也會各自略有不同，這便是所謂的“配置（Profile）”。目前至少已經(jīng)有這么多配置了：
* .NET 4.0配置
* Silverlight配置
* Windows Phone 7配置
* XBox360配置
* Mono核心配置：與.NET配置相同，可以在Linux，MacOS X，Solaris，Windows和BSD里使用。
* .NET Micro Framework
* Mono的iOS配置
* Mono的Android配置
* Mono的PS3配置
* Mono的Wii配置
* Moonlight配置（與Silverlight兼容）
* Moonlight擴(kuò)展配置（Silverlight和完整的.NET 4 API）
“配置”之間的區(qū)別主要體現(xiàn)在執(zhí)行環(huán)境的能力（例如iOS不支持運(yùn)行時代碼生成，因此支持AOT但不能JIT）以及類庫的覆蓋面上（例如XNA類庫只存在于 Windows Phone及XBox 360等游戲平臺），不過它們終究實(shí)現(xiàn)了一個核心規(guī)范，因此我們可以說在不同平臺上都可以“使用.NET進(jìn)行開發(fā)”。
Mono實(shí)在是一個了不得的作品，它讓我知道了“跨平臺原來可以這么做”。之前我也寫過有關(guān)跨平臺的問題，其中談到在“客戶端的跨平臺一般都很難得到最佳的體驗(yàn)”，這個論點(diǎn)的最佳證明便是Java。但Mono走的卻是另一條跨平臺的道路，它在各平臺上實(shí)現(xiàn)了核心的執(zhí)行引擎和類庫之外，解決“體驗(yàn)”的方式便是在各個平臺上提供原生平臺的綁定。這樣無論是在Mac OS，iOS，Android上都可以得到原生應(yīng)用的體驗(yàn)。
我很奇怪為什么有些搞.NET的人一邊說.NET的適用面太小，一邊卻忽視 Mono的成果，在我看來這完全是“自作孽不可活”，我愈發(fā)覺得是否接受Mono是判斷一個.NET程序員是否優(yōu)秀的重要準(zhǔn)則。其實(shí)Mono實(shí)在很火，因?yàn)樗麨閺V大.NET程序員擴(kuò)展了工作領(lǐng)域，使用現(xiàn)有的知識來開發(fā)iOS等平臺的應(yīng)用程序，還可以共享代碼，何樂而不為？前不久蘋果發(fā)布了Mac上的App Store，于是MonoMac也立即推出了面向AppStore的打包器，F(xiàn)rank Krueger也開始著手移植它的作品iCircuit，成果顯著。因此在我看來，這才是一個現(xiàn)代.NET程序員該有的工作臺：
當(dāng)然，我知道大家都是聰明人，反對的理由總是找得到的，這里先隨便列上幾條。
有人說，用MonoTouch等.NET實(shí)現(xiàn)來做iOS開發(fā)“不正式”，我說，這個說法頗有“血統(tǒng)論”的意味，不過既然在Windows上用C++和 Delphi都很正式，那么為什么在iOS上使用Objective-C才是正途？有人說，MonoTouch性能一定不如Objective-C好，我說，這是猜測，即使性能不如Objective-C，看看各種案例也知道這在實(shí)踐中并不是問題（事實(shí)上MonoTouch的前身便是Unity3D對 Mono的使用，而iOS上實(shí)在有太多游戲在使用Unity3D了）。還有人說，MonoTouch或MonoDroid沒有大公司支持，不靠譜，我說，您之前不是經(jīng)常鄙視類似“開源沒有微軟靠譜”或是“微軟開發(fā)人員只知道微軟技術(shù)”這種說法的嗎？還有人說……
不過，這些說法還是擋不住出現(xiàn)基于MonoDroid的DeltaEngine，這是個跨平臺的游戲引擎，在Mono的支持下可以運(yùn)行在Linux，MacOS X，iOS和Android上，在微軟.NET支持下可以運(yùn)行在XBox 360，Windows Phone 7自然還有普通的Windows系統(tǒng)上。在CES 2011上NVidia演示了一個游戲，Soul Craft，它運(yùn)行在LG Optimus 2X，這個游戲正是使用了DeltaEngine。
對于我們來說，最大的限制其實(shí)還是眼界和思維，突破這一屏障也是我組織nBazaar技術(shù)沙龍的目的之一。本周六將會舉辦第三屆nBazaar技術(shù)交流會，具體信息請訪問http://nbazaar.org/。如果您還沒有報名，也可以直接前來，也歡迎帶上感興趣的朋友或同事。根據(jù)以往的經(jīng)驗(yàn)，場地就像乳溝，擠擠總是有的……
喜歡 
頂
難過
囧
圍觀
無聊
