對主流技術的分析和總結

一、引言
我為什么要寫這篇文章
首先，我要限定我文章的范圍，我討論的問題局限于桌面應用開發領域和企業應
用開發領域，所以我的結論并不適用于整個軟件開發界，比如我說C語言已經退出
歷史舞臺，這對于寫嵌入式系統的人和編寫操作系統內核的人來說顯然是錯了。
我寫這篇文章的目的主要是：
* 簡單的介紹并評價當前主流技術
* 比較當前的主流技術
* 預計技術的演變

如果你想做程序員或者已經是個程序員，你可能會面對這些困惑：
* 學什么語言呢？Delphi、C++、VB、Java、C#、PHP、Python?
* 選擇什么開發工具呢？Delphi、VC、C++Builder、JBuilder?
當你已經入了門，有了一定的基礎之后（可能已經通曉了幾種語言），你會面臨
進一步的困惑：
* MFC和VCL之間是什么關系？
* J2EE到底是什么？.Net到底是什么？兩者有什么本質的區別，我應該學習哪一個呢？
* COM那么復雜，為什么很多地方都用到它？我必須學習它嗎？


如果是作為一個軟件公司，如果不是那么大，如果你的公司還沒有一個真正的技
術上的靈魂人物，那么你也會面臨同樣的困惑。技術問題紛繁復雜，讓你不知所
從，而且真正的精通每一項技術都需要巨大的時間和人力的投入，你怎么辦？選擇
哪種技術作為公司的主流技術呢？選擇的方向是否正確是個關乎你的公司的生死存
亡的問題。

你面臨著這些困惑嗎？如果是，那么請讓我試著為你撥云見日。


我的故事

在我上大學之前，我從沒見過計算機。大學的時候，正是Dos和FoxBASE的年代，
也正是計算機軟件開發世界幾件偉大的事情發上的時候：(Windows3.1、Borland
C++ 3.1、Visual Basic 1.0 的推出也是偉大的事情，但那時候我還不知道計算機
為何物)Widnows95推出，并開始應用；Visual Basic 5.0推出，開發工具中第一次
出現了成熟的、被廣泛應用的Auto Code Completion技術；Java推出；ASP技術開
始盛行,Windows DNA技術被理解和接受；標準C++誕生;Visual C++6.0 推出；J2EE
規范推出。
成為一個程序員對我而言并不順利，因為我不是科班出身。我入門的程序語言是
FoxBASE，這讓我一直對FoxBASE有種特殊的感情，我也正是通過Visual FoxPro3.0
轉寫Windows程序的，如果沒有它，我也許就不會成為一個程序員了。后來，在大
學期間接觸到了InterDEV，那是個寫ASP程序的開發工具，還有Java，也是那時候
接觸的，當時有點盲目崇拜的意思（我想我喜歡Java的一個原因可能是剛開始學C
的時候很受挫折）。畢業之后，我就是憑借著自己寫的一個ASP網站找到了自己的
第一份工作——說來慚愧，我從來也沒有成為一個C程序員。我真正的熟悉Java是在
我翻譯了一本Java數據結構的書和寫了一套完整的GIS系統之后（說起此事，我要
感謝一下我的公司，但因為這些故事與本文的主題無關，所以這里就不多說了）。
再后來，我自己學習了標準C++和COM技術。
有點像履歷表了是嗎？提到這些，我只是希望作為讀者的你能夠了解一下我的知
識體系，從而能夠知道我大概要講些什么；同時也希望你能夠原諒我可能犯的錯誤
——我在這里說的話，并不一定就是最后的結論，雖然“共同探討”這個詞幾乎是粗制
濫造的書的作者專用語了，但我在這里引用它是真誠的，我愿意看到你的反饋。


要涉及的話題
在開始文章的正題之前，我先大概地介紹這篇文章將會涉及到哪些知識。如果你
是初學者，希望你不要被嚇倒，這雖然是一篇技術文章，但我不會過多的討論技術
細節，如果你不懂我說的這些東西，也沒關系，我本來就希望通過我的文章幫助你
做出一個選擇，不再走很多人已經走過的彎路，你這要記住結論就可以了，隨著你
知識的增長，以后你會漸漸明白；如果你已經通曉了這些技術或其中的大部分，那
么我相信讀了這篇文章你會有一些另外的收獲。
主流的程序設計語言： C++、Delphi(Object Pascal)、Java、C#
桌面應用程序框架：MFC、VCL、QT、Java AWT\SWING、.Net
企業應用程序框架：Windows DNA（ASP、COM、COM+）、J2EE、.Net Framework
開發工具：Visual Basic、Delphi、Visual C++、C++ Builder 、Visual C#

二、正文
好了，現在讓我們開始我的正文吧。
首先，我來完成這篇文章的第一個目標：介紹并評價當前主流技術。我指的今天
的主流技術是：
* 程序設計語言：C++\Delphi（本來應該是Object Pascal，但為了簡單，我就語
言和工具混為一談吧）\Java\C#(雖然他剛剛推出，但因為微軟為之傾注了大量心
血，一定會成為一種重要的開發語言)
* 桌面應用程序框架:MFC\VCL
* 企業應用程序框架:Windows DNA\J2EE\.Net
* COM技術：我單獨提出這項技術，是因為它無法簡單的被視為語言、桌面應用程
序框架或企業應用程序框架，它與這些都有關系。
2.1 程序設計語言
2.1.1 C++
語言的演進最初要從二進制代碼和匯編說起，但那太遙遠了。我們就從面向過程的
語言說起吧（包括Basic\C\Fortran\Pascal）。這種面向過程的高級語言終于把計
算機帶入了尋常的應用領域。其中的C語言因為它的簡單和靈活造就了Unix和
Windows這樣的偉大的軟件。面向對象的語言是計算機語言的一個合乎邏輯的進
化，因為在沒有過多的影響效率、簡單性的前提下提供了一種更好的組織數據的方
法，可以程序更容易理解，更容易管理——這一點可能會引出不同意見，但事實勝于
雄辯，C++終于讓C語言的領地越來越小，當今還活著的計算機語言或多或少的都具
備面向對象的特征，所以這一點并不會引起太多困惑。C++的成功很大程度要歸因
于C，C++成為它今天的樣子是合乎邏輯的產物。因為在面向過程的時代，C幾乎已
經統一天下了。今天著名的語言象Java\C#都從C借鑒了很多東西，C#本來的意思就
是C++++。
其實C++曾經很有理由統一面向對象程序設計語言的天下來著，但可惜的是，C++
太復雜了。即使是一個熟練的程序員，要你很清楚的解釋一些問題你也會很頭痛。
舉幾個還不是那么復雜的例子來說：
對=的重載\成員轉換函數\拷貝構造函數\轉化構造函數之間有什么區別和聯系呢？
這樣定義一個類成員函數private: virtual void MemFun() = 0; 是什么意義呢？
int (*(*x(int))[4])(double); 是什么意思？
還有其他的特征，比如說可以用來制造一種新語言的typedef和宏（雖然宏不是C+
+的一部分，但它與C++的關系實在太密切了），讓你一不小心就摔跤的內存問題
（只要new 和delete就可以了嗎？有沒有考慮一個對象存放在容器中的情況？）……
諸如此類，C++是如此的復雜以至于要學會它就需要很長的時間，而且你會發現即
使你用C++已經好幾年了，你還會發現經常有新東西可學。你想解決一個應用領域
的問題——比如說從數據庫里面查詢數據、更改數據那樣的問題，可是你卻需要首先
為C++頭痛一陣子才可以，是的，你精通C++，你可以很容易的回答我的問題，可是
你有沒有想過你付出了多大的代價呢？我不是想過分的譴責C++，我本人喜歡C++，
我甚至建議一個認真的開發普通的應用系統的程序員也去學習一下C++，C++中的一
些特性，比如說指針運算\模板\STL幾乎讓人愛不釋手，宏可以用幾個字符代替很
多代碼，對系統級的程序員來說，C++的地位是不可替代的，Java的虛擬機就是C++
寫的。C++還將繼續存在而且有旺盛的生命力。


2.1.2 Java和C#
Java和C#相對于C++的不同最大的有兩點：第一點是他們運行在一個虛擬環境之
中，第二點是語法簡單。對于開發人員而言，在語法和語言機制的角度可以把Java
和C#視為同一種語言。C#更多的是個政治的產物而不是技術產物。如果不是Sun為
難微軟的話，我想微軟不會費盡心力推出一個和Java差不多的C++++，記得Visual
J++嗎，記得WFC嗎？看看那些東西就會知道微軟為Java曾經傾注了多少心血。而且
從更廣泛的角度來說，兩者也是非常相似的——C#和Java面對的是同樣的問題，面向
應用領域的問題：事務處理、遠程訪問、Web service、Web頁面發布、圖形界面。
那么在這一段中，我暫且用Java這個名字指代Java和C#兩種語言——盡管兩者在細節
上確實有區別。
Java是適合解決應用領域的問題的語言。最大的原因Java對于使用者來說非常簡
單。想想你學會并且能夠使用Java需要多長時間，學會并且能夠使用C++要多長時
間。由于Java很大程度上屏蔽了內存管理問題，而且沒有那么多為了微小的性能提
升定義的特殊的內容（比如說，在Java里面沒有virtual 這個關鍵字,Java也不允
許你直接在棧上創建對象，Java明確的區分bool和整型變量），他讓你盡量一致的
方式操作所有的東西，除了基本數據類型，所有的東西都是對象，你必須通過引用
來操作他們；除了這些之外，Java還提供了豐富的類庫幫助你解決應用問題——因為
它是面向應用的語言，它為你提供了多線程標準、JDBC標準、GUI標準，而這些標
準在C++中是不存在的，因為C++并不是直接面向解決應用問題的用戶，有人試圖在
C++中加入這些內容，但并不成功，因為C++本身太復雜了，用這種復雜的語言來實
現這種復雜的應用程序框架本人就是一件艱難的事情，稍后我們會提到這種嘗試——
COM技術。漸漸的，人們不會再用C++開發應用領域的軟件，象MFC\QT\COM這一類的
東西最終也將退出歷史舞臺。

2.1.3 Delphi
Delphi是從用C++開發應用系統轉向用Java開發應用系統的一個中間產物。它比C++
簡單，簡單的幾乎象Java一樣，因為它的簡單，定義和使用豐富的類庫成為可能，
而且Delphi也這么做了，結果就是VCL和其他的組件庫。而另一方面，它又比運行
于虛擬環境的java效率要高一些，這樣在簡單性和效率的平衡之中，Delphi找到了
自己的生存空間。而且預計在未來的一段時間之內，這個生存空間將仍然是存在
的。可以明顯的看出，微軟放棄了這個領域，他專注于兩方面：系統語言C++和未
來的Java(其實是.Net)。也許這對于Borland來說，是一件很幸運的事情。如果我
能夠給Borland提一些建議的話，那就是不要把Delphi弄得越來越復雜，如果那
樣，就是把自己的用戶趕到了C++或Java的領地。在虛擬機沒有最終占領所有的應
用程序開發領域之前，Delphi和Delphi的用戶仍然會生存得很好。


2.2 桌面應用程序框架
目前真正成功的桌面應用程序框架只有兩個，一個是MFC，一個是VCL，還有一些
其他的，但事實上并未進入應用領域。遺憾的是我對兩個桌面應用程序框架都不精
通。但這部不妨礙我對他做出正確的評價。
2.2.1 MFC
MFC（還有曾經的OWL）是SDK編程的正常演化的結果，就象是C++是C的演化結果一
樣。MFC本身是一件了不起但不那么成功的作品，而且它過時了。這就是我的結論。
MFC凝聚了很多天才的智慧——當然，OWL和VCL也一樣，侯捷的《深入淺出MFC》把這些
智慧擺在了我們的面前。但是這件東西用起來估計不會有人覺得很舒服，如果你一
直在用Java、VB或者Delphi，再回過頭來用MFC，不舒服的感覺會更加強烈。我不
能夠解釋MFC為什么沒有能夠最終發展成和VCL一樣簡單好用的桌面程序框架，也許
是微軟沒精力或者沒動力，總之MFC就是那個樣子了，而且也不會再有發展，它已
經被拋棄了。我有時候想，也許基于C++這種復雜的語言開發MFC這樣的東西本身就
是錯誤的——可以開發這樣的一個框架，但不應當要求使用它的人熟悉了整個框架之
后才能夠使用這個系統，但很顯然，如果你不了解MFC的內部機制，是不太可能把
它用好的，我不能解釋清楚為什么會出現這種現象。
2.2.2 VCL
相比之下VCL要成功的得多。我相信很多使用VCL的人可能沒有像MFC的用戶研究MFC
那樣費勁的研究過VCL的內部機制。但這不妨礙他們開發出好用好看的應用程序，
這就足夠了，還有什么好說的呢？VCL給你提供了一種簡單一致的機制，讓你可以
寫出復雜的應用程序。在李維的Borland故事那篇文章中曾經說過，在Borland
C++3.1推出之后Borland就有人提出開發類似C++ Builder一類的軟件，后來竟未成
行。是啊，如果C++Builder是在那個時候出現的，今天的軟件開發領域將會是怎么
樣的世界呢？真的不能想象。
也許再過一段時間，這些都將不再重要。因為新生的語言如Java和C#都提供了類
似于VCL的桌面應用程序框架。那個時候，加上Java和C#本身的簡單性，如果他們
的速度有足夠塊，連Delphi這種語言也要消失了，還有什么好爭論的呢？只是對于
今天的桌面程序開發人員來說，VCL確實是最好的選擇。
2.3企業應用程序框架
2.3.1 Windows DNA
Windows DNA的起源無從探究了。隨著.Net的推出，事實上Windows DNA將成為歷
史的陳跡。Windows DNA雖然是幾乎所有的企業應用程序開發人員都知道的一個名
詞，但我相信Windows DNA事實上應用的最廣泛的是ASP而不是COM+。真正的COM開
發有多少人真正的掌握了呢，更不要提COM+(我有必要解釋一下：COM+是COM的執行
環境，它提供了一系列如事務處理、安全等基礎服務，讓應用程序開發人員盡量少
在基礎架構設計上花精力)——當然我這里指的COM開發不是指VB下的COM開發，所以
要這么說，是因為我覺得如果不能理解用C++進行COM開發，也就不能真正的理解
COM技術。如果以一種技術沒有被廣泛理解和應用作為失敗的標志，那么Windows
DNA實際上是失敗了，但這不是它本身的錯，而是基于C++的COM技術的失敗造成
的。多層應用、系統開發角色分離的概念依然沒有過時。
2.3.2 J2EE
J2EE是第一套成功的企業應用程序開發框架。因為它把事務處理、遠程訪問、安全
這些概念帶入了尋常百姓家。這種成功我認為要歸因于Java的簡單性。Java的簡
單，對于J2EE容器供應商來說一樣重要。開發一個基于Java的應用服務器要比基于
C++的更容易。而且由于Java的簡單性，應用系統開發者出錯的機會也會少一些，
不會像C++的開發者那樣受到那么多挫折。開發基于Java的企業應用系統的周期會
更短，這恐怕是不容爭辯的事實。不論如何，是J2EE讓事務處理、遠程訪問、安全
這些原來幾乎都是用在金融系統中的概念也被一般的企業用戶使用并從中獲得利益。
2.3.3 .NET
.Net有什么好說的呢？其實，它不過是微軟的J2EE。事務處理、安全、遠程訪
問，這些概念在.Net中都找得到。更有力的說明是，微軟也利用了.Net實現了一個
Pet Store。所以，.Net與J2EE幾乎是可以完全對等的。但微軟確實是一家值得尊
敬的公司——我指從技術上，象Web form這種東西，我相信很多Web應用開發者都夢
想過甚至自己實現過，但Sun卻一直無動于衷，而且似乎Borland也沒有為此作過太
多努力，好像有過類似的東西，但肯定是不怎么成功——Borland已經很讓人敬佩
了，我們也許無法要求太多。
2.4 COM技術
COM應當是個更廣泛的詞匯，其實我覺得AxtiveX、OLE、Automation、COM+都應當
提及，因為如果你不理解COM，上面的東西你是無法理解的。而且，我只是想說明
COM是一種即將消亡的技術，僅僅說說COM的復雜性和他的問題就夠了，所以不會提
及那些東西。
為什么會出現COM技術？COM的根本目標是實現代碼的對象化的二進制重用，進而實
現軟件的組件化、軟件開發工作的分工。這要求他做到兩點：第一，能夠跨越不同
的語言，第二，要跨越同一種語言的不同編譯器。COM技術為這個目標付出了沉重
的代價，尤其是為了跨越不同的編譯器，以至于無論對于使用者而言還是開發者而
言，他都是一個痛苦的技術。但幸運的事，這一切終歸要結束了。
讓我們從這個目的出發看看COM為什么會成為它現在的樣子。
其實COM不是什么新玩意，最初的DLL就是重用二進制代碼的技術。DLL在C的年代可
能還不錯，但到了C++的年代就不行了。原因在于如果你在.h文件中改變了類定義
（增加或者減少了成員變量），代碼庫用戶的代碼必須重新編譯才可以，否則用戶
的代碼會按你的舊類的結構為你的新類分配內存，這將產生什么后果可想而知。這
就是為什么通過接口繼承和通過接口操作對象成為COM的強制規范的原因，能夠通
過對象的方式組織代碼是COM的重要努力。
那么著名的IUnknown 接口又是怎么回事呢？這是為了讓使用不同編譯器的C++開發
人員能夠共享勞動成果。首先看QueryInterface，因為COM是基于接口的，那么一
個類可能實現了幾個接口，而對于用戶來說，你又只能通過操作接口來操作類，這
樣你必須把類造型成某個特定的接口，使用Dynamic_cast嗎？不行，因為這是編譯
器相關的，那么，就只好把它放在類的實現代碼中了，這就是QueryInterface的由
來。至于AddRef和Release，他們產生的第一個原因是delete這個操作要求一個類
具有虛析構函數（否則的話，他的父類的析構函數將不會被調用），但不幸的是不
同的編譯器中虛析構函數在vtbl中的位置并不相同，這就是說你不能讓用戶直接調
用delete，那么你的COM對象必須提供自己刪除自己的方法；另外的原因在于一個
COM對象可能作為幾個接口在被用戶同時使用，如果用戶粗暴的刪掉了某個接口，
那么其他的接口也就不能用了，這樣，只好要求用戶在想用一個接口的時候通過
AddRef通知COM對象“我要使用你了，你多了一個用戶”，而在不用之后要調用
Release告訴COM對象“我不用你了，你少了一個用戶”，如果COM對象發現自己沒有
用戶了，它就把自己刪掉。
再看看詭異的HRESULT，這是跨語言和跨編譯器的代價。其實，異常處理是物競天
擇的結果——連一直用效率作標榜的C++都肯犧牲效率來實現這個try-catch，可見它
的意義，但COM為了照顧那些低級的語言居然拋棄了這個特征——產生的結果就是
HRESULT。我們可以看看他是多么愚蠢的東西。首先，我們要通過一個整數來傳遞
錯誤信息，通過IErrorInfo來查找真正的錯誤描述，本來在現代語言中一個try-
catch可以解決的問題，現在我們卻需要讓用戶和開發者都走很多路才能解決，你
怎么評價這個結果？其次，由于這個返回計算結果的位置被占用了，我們不得不用
怪異的out參數來返回結果。想想一個簡單的 int add(int op1,int op2)在COM中
竟然要變成HRESULT add(int op1,int op2,int *result)，我不知道你對此作何感
想。而且由于COM的方法無法返回一個對象而只能返回一個指針，為了完成一個簡
單的std::string GetName()這一類的操作，你要費多少周折——你需要先分配一塊
內存空間，然后在COM實現中把一個字符串拷貝到這個空間，用完了你要刪掉這個
空間，不知道你是否覺得這種工作很幸福，反正我覺得很痛苦。
還有COM為了照顧那些解釋性的語言，又加入了Automation技術，你有沒有為此覺
得痛苦？本來一個簡單的方法調用，現在卻需要傳給你一個標志變量，然后讓你根
據這個標志變量去執行相應的操作。（這一點我現在仍然不明白，為什么解釋性的
語言需要通過這個方式來執行一個方法）。
“我受夠了，我覺得頭痛”，你會說，是啊，我想所有的人都受夠了，所有這些因素
實際上是把COM技術變成了一頭讓人無法駕馭的怪獸。人對復雜事物的掌控能力終
究是有限的，C++本身已經夠復雜了， COM的復雜性已經超出了我們大部分人的控
制能力，你需要忍受種種痛苦得到的東西與你付出的代價相比是不是太不值得了？
我們學習是為了解決問題，而現在我們卻需要為了學習這件事情本身耗費太多的精
力。這些痛苦的東西太多了，我在這里說到的，其實只是一小部分而已。計算機技
術是為人類服務的，而不是少數人的游戲（我想COM技術可能是他的設計者和一部
分技術作者的游戲），難道我們愿意成為計算機的奴隸嗎？通過一種過于復雜的技
術拋棄所有的人其實等于被所有的人拋棄，這么多年中選擇J2EE的人我相信不乏高
手，你是不是因為COM的過于復雜才選擇J2EE的？因為它可以用簡單的途徑實現差
不多的目標——軟件的“二進制”重用、組件化、專業分工（容器開發商和應用開發商
的分工）。事實上，你是被微軟所拋棄的，同時，你也拋棄了微軟。
現在讓我們回來吧，我把你帶進了COM的迷宮，現在讓我把你領回來。再讓我們看
看COM到底想實現什么目標，其實很簡單，不過是代碼的二進制重用，也就是說你
不必給別人源代碼，而且你的組件可以象計算機硬件那樣“即插即用”。我們回過頭
來看看Java，其實，這種二進制重用的困難是C++所帶來的（這不是C++本身的錯，
而是靜態編譯的錯），當Java出現的時候，很多問題已經不存在了。你不需要一個
頭文件，因為Java的字節碼是自解釋的，它說明了自己是什么樣子的，可以做什么
事情，不像C++那樣需要一個頭文件來解釋這些事情；也不需要事先了解對象的內
存結構，因為內存是在運行的時候才分配的。
如果我們現在再回過頭來解決COM要解決的問題，你會怎么做呢？首先你會不再選
擇C++這種語言來實現代碼的“二進制”重用，其次，你會把所有的語言編譯成同樣
的“二進制” 代碼（實際上，應當說是字節碼），這顯然是更聰明的做法，從前COM
試圖在源代碼的級別抹平二進制層次的差異，這實際上是讓人在做本來應當由機器
做的事情，很愚蠢是嗎？但他們一直做了那么多年，而且把這個痛苦帶給了整個計
算機世界——因為他們掌握著事實的標準，為了用戶，為了利潤，為了能夠在
Windows上運行，盡管你知道你在做著一個很不聰明的事情，但你還是做了。
COM技術為了照顧VB這個小兄弟和實現統一二進制世界的野心，實在浪費了太多的
精力。首先，落后的東西的消亡是必然的，就象C、Pascal在應用領域的消亡一
樣，Basic一點一點的改良運動是不符合歷史潮流的做法，先進的東西和落后的東
西在一起，要么先進的東西被落后的東西拖住后腿，要么是同化落后的東西，顯然
我們更愿意看見后者，現在Basic終于被現代的計算機語言同化了。其次，統一二
進制世界好像不是那么簡單的事情，而且也沒什么必要，微軟的COM技術奮戰了10
年，現在也只有他自己和Borland支持，.Net終于放棄了這個野心。這一切終于要
結束了。過去J2EE高歌猛進地占領著應用開發的領地，COM在這種進攻面前多少顯
得蒼白無力。現在微軟終于也有了可以和J2EE一較長短的.NET，對于開發人員來
講，基于字節碼的組件的二進制重用現在是天經地義的事情；你不用再為了能夠以
類方式發布組件做那么多亂七八糟的事情，因為現在所有的東西本來就是類了；實
現軟件開發的分工也很自然，你是專業人員，就用C#吧，你是應用開發人員，你喜
歡用VB.Net，你就用吧，反正你們寫的東西最終都被翻譯成了一樣的語言（其實我
覺得這一點意義不大，因為一些不那么好用的語言被淘汰是正常的事情，C風格成
為程序設計語言的主流風格，肯定是有它的原因的，語言的統一其實是大勢所趨，
就象中國人民都要說普通話一樣，所以我覺得Java不支持多語言算不上缺點——本來
就是一種很好看很好用的語言了，為什么要把簡單問題復雜化呢？）。
COM不會在短期內死去，因為我估計微軟還不會馬上用C#開發Office和Windows的圖
形界面部分，但我相信COM技術退出歷史舞臺的日子已經不遠了，作為一般的開發
人員，忘了這段不愉快的歷史吧——你將不會在你的世界里直接和COM打交道。
若干年以后，我想COM也許會成為一場笑話，用來諷刺那種野心過大、鉆牛角尖的
愚蠢的聰明人。

結論

說了很多，應該是有個結論的時候了。我似乎做了一件冒天下之大不韙的事情，
因為我評價了主流技術，還要試圖進行比較，好像某個名人說過：“C++Builder也
好，Visual C++也好，能在市場上立足，肯定都是有自己的過人之處的，而且一個
人精通數種開發語言、數種開發工具是不可能的事情”，言下之意就是說你不要對
這些東西妄加評論，但怎么可以不評論？好像高手都不屑于說哪種語言好、哪種語
言壞，我不知道什么時候形成了這種風氣。簡單地說C++比Java好或者Java比C++好
顯然是愚蠢的行為，但如果讓你用Java寫驅動程序，用C++開發一個MIS系統是不是
愚蠢的行為呢？顯然更愚蠢。我想，作為一個獨立的能思考的人，外界的東西對你
而言總是有好有壞，而且你的生命有限，你還要享受你的生活，所以你必須做出選
擇。所以，起碼評價這些東西對我自己而言是正確的——只要我有能力評價，那我就
說出我的評價吧。

對于計算機語言來說，未來真正重要的語言只有三種C++、Java和C#。
C++將更適合于專業的計算機公司編寫圖形界面系統（比如KDE）、虛擬機（比如
Java虛擬機或者.Net運行環境）、殺毒軟件或者其他的盒裝軟件（比如說
Photoshop、Dream weaver）這一類的東西。而且C++適合程序員做學習之用，能對
C++有一定理解的程序員往往也應該能更深刻的理解Java、C#，這有助于編寫更好
的軟件。
如果是開發為客戶定制的應用系統Java、C#是更好的選擇。包括桌面應用和Web應
用。至于其他的語言比如VB.Net其實并沒有太大的意義。
Delphi在未來一段時間將繼續存在，而且活得不錯。最重要的原因在于，第一它有
一套豐富的組件庫，第二它效率相對算高的，第三它簡單。如果虛擬機的執行效率
趕不上Delphi，它就有存在的理由，但從過去的Visual J++來看，微軟的虛擬機做
得確實可以很好，加上.Net的組件庫和C#的簡單性并不差，所以從長遠來看Delphi
可能不那么樂觀。
其實上面的比較也包含了桌面應用程序框架的比較。在現在來說VCL無疑最好的，
MFC已經退出歷史舞臺。.Net中所帶的桌面應用程序框架將最終統一桌面應用領域
（但不包括微軟和Borland這樣的專業公司，因為他們要作出最好用而且效率最高
的軟件）。至于Java中所帶的桌面應用程序框架，實在讓人哭笑不得。這個結論的
變數是.Net運行環境的執行效率。如果.Net中的虛擬機象Java的一樣，那微軟就倒
霉了，它等于放棄了桌面應用開發工具領域，但根據微軟在Visual J++上的成就和
他推廣.Net的背水一戰的駕式，.Net在桌面領域失敗的可能性不大（但不是沒有，
起碼基于COM的技術在企業應用領域幾乎可以說是全軍覆沒）。
在企業應用程序框架領域，最終只有J2EE和.Net可以決一雌雄。我沒有提到
CORBA，它也可以算是企業應用程序框架，但他的聲勢和J2EE或者.NET實在不能同
日而語，而且最重要的是只有Borland一家大公司支持它（SUN、IBM、BEA、
Borland支持J2EE，微軟就不用說了），所以就不詳細說他了。
那么最終誰會贏呢？我想微軟贏的可能性大一些。這樣說可能讓很多人不快，而且
IBM的厲害也是有目共睹的。但這并不是純技術問題，就象Windows NT蠶食Unix的
領土那樣，那時候微軟也是孤軍作戰。J2EE的問題在于第一：混亂，第二，價高。
我相信很多人都對這兩點有過不快的經歷。你知道寫給Weblogic的應用程序不是很
順利地就可以移植到Websphere上的，反過來也一樣。但.Net就不一樣了，那是微
軟一個人的作品，根本不存在移植的問題。如果J2EE陣營不想敗在這一點上，有三
個辦法，第一種就是通過制定統一的標準徹底消滅移植問題，第二種是開發一種好
用的部署工具（不能象JBuilder那么大、那么慢：），屏蔽不同的應用程序容器之
間的區別，第三種，也是最不可能的，就是J2EE陣營有人能夠一統天下。顯然，這
三種解決辦法都不太現實。
第二點價高，這是SUN、IBM、BEA、ORACLE傳統，也是它們一直讓微軟的進攻屢屢
得手的軟肋。我一直不太能明白他們的西就為什么那么貴。這樣想一想：微軟的
.Net SDK白送給你，BEA的Weblogic一個CPU的License兩萬，如果你兩種技術都
會，如果你給客戶的系統報價一樣，你選哪種開發技術？這一點實在讓人覺得無可
奈何。J2EE有的東西，.Net也有（除了不能跨平臺），技術上的細微差別在巨大的
價格差異面前還有什么意義呢？
當然，SUM、IBM這些大公司也不是等閑之輩。就象Windows NT沒有消滅Unix一樣，
J2EE應當會像Windows NT和Unix的共存一樣和.Net共存，只是我想.Net恐怕會占上
風。
閑話
說完了該說的技術問題，說說閑話吧。有的話放在心里覺得不說出來不舒服，且讓
我一吐為快:)
給入門程序員的建議
不知道我在學計算機的時候是不是走了彎路。但我想如果讓我重新開始學寫程序
的話，我會采用一些不同的辦法。如果你也正在想成為一個程序員，這些也許會對
你有幫助。
我覺得可能大概要分幾個階段，第一個階段應該是找一門簡單的語言入門，比如
Java或者C#都應該比較合適，選一本簡單的帶例子的書（最好不要太厚），按部就
班的把書學完。這時候可能還有些懵懵懂懂，但沒關系，可以開始做個小小的軟件
了，重要的事你要自己用那種語言的方式想思考，如果有項目做，當然更好。之
后，你會覺得有點感覺了。如果你象我一樣不是科班出身的，接下來應當補習一下
計算機專業的課程，我覺得最重要的是數據結構——那些東西你可能永遠都不會自己
做，C++中有漂亮的STL，Java中也為你實現了大部分東西，但我覺得真的有必要學
習那些內容，這會加強你用計算機語言思考問題的能力。在進一步，如果你的入門
語言不是C++，那你可以補習一下C++，盡管你可能永遠都不會用C++開發程序。C++
在現在的計算機世界就象是普通話一樣，而且它能讓你很容易的理解其他語言中難
以理解的問題。
學完了C++，那你應當就已經不是一個初級程序員了，歡迎你進入計算機軟件開發
的世界。

印度的軟件業
我記得好像在CSDN上看見過一篇文章，極力的鼓吹印度的軟件業。而且我記得他
好像說過一句很刻薄的話“我們公司那些B大的和T大的，一個一個特別牛，牛得看
不見人……做起界面極盡奇跡淫巧之能事……”，諸如此類，總之認為程序員只有象印
度的高中生那樣乖乖的、懂得UML、會看Function Specification才算是真正的程
序員。我當時覺得很不舒服。我想這個人應該不是B或T大的——哦，別誤會，我也不
是——但我覺得好像B大的T大的人沒象他說的那樣。而且我不明白為什么中國的軟件
業為什么一定要向印度看齊？作為一家公司，你想獲取商業利潤，學習印度無可厚
非，你大可以找一大堆高中生培訓成編程藍領（我沒有輕視高中生的意思，我相信
有很多“高中生”在技術領域取得的成就是讓我望塵莫及的），但你不應該因此就把
有血有肉有個性的程序員扁得一錢不值。說實話，所謂的編程藍領不過是工廠里面
的裝配工，如果有一天工廠里面換了自動化的設備，這些人就全成了廢人！而你要
知道并不是這些裝配工發明了自動化機器。我想這種話用不著多說，子曰“過猶不
及”，你可以喜歡變成藍領，但不要把問題推向極端，把問題推向極端往往就會犯
錯誤。我們中國可以在某種程度上學習印度，但好像我們更應該學習美國——只是我
們現在沒那么富裕——可是微軟也不是從一開始就是這樣一個偉大的帝國的，IBM也
一樣。



附錄
參考書目
閱讀如下圖書有助于理解本文內容。而且這些書都是好書，值得一讀。
* 《標準C++寶典》
* 《C++編程思想》
* 《深入淺出MFC2e》
* 《COM技術內幕》
* 《COM本質論》
* 《Java編程思想》
* 《精通EJB》第二版
* 《J2EE編程指南》
* 《Delphi 6開發人員指南》
* 《C#寶典》
* 《微軟 .Net戰略》