對目前主流開發技術的分析和總結 (轉貼大富翁) ---- 獻給困惑中的弟兄們

簡體傳統

現在讓我們開始我的正文吧。首先，我來完成這篇文章的第一個目標：介紹并評價當前主流技術。我指的今天的主流技術是：

　　　*程序設計語言：C++\Delphi（本來應該是ObjectPascal，但為了簡單，我就語言和工具混為一談吧）\Java\C#(雖然他剛剛推出，但因為微軟為之傾注了大量心血，一定會成為一種重要的開發語言)

　　　*桌面應用程序框架:MFC\VCL

　　　*企業應用程序框架:WindowsDNA\J2EE\.Net

　　　*COM技術：我單獨提出這項技術，是因為它無法簡單的被視為語言、桌面應用程序框架或企業應用程序框架，它與這些都有關系。

　　2.1 程序設計語言

　　2.1.1C++語言的演進

　　最初要從二進制代碼和匯編說起，但那太遙遠了。我們就從面向過程的語言說起吧（包括Basic\C\Fortran\Pascal）。這種面向過程的高級語言終于把計算機帶入了尋常的應用領域。其中的C語言因為它的簡單和靈活造就了Unix和Windows這樣的偉大的軟件。

　　面向對象的語言是計算機語言的一個合乎邏輯的進化，因為在沒有過多的影響效率、簡單性的前提下提供了一種更好的組織數據的方法，可使程序更容易理解，更容易管理——這一點可能會引出不同意見，但事實勝于雄辯，C++終于讓C語言的領地越來越小，當今還活著的計算機語言或多或少的都具備面向對象的特征，所以這一點并不會引起太多困惑。C++的成功很大程度要歸因于C，C++成為它今天的樣子是合乎邏輯的產物。因為在面向過程的時代，C幾乎已經統一天下了。今天著名的語言象Java\C#都從C借鑒了很多東西，C#本來的意思就是C++++。其實C++曾經很有理由統一面向對象程序設計語言的天下來著，但可惜的是，C++太復雜了。即使是一個熟練的程序員，要你很清楚的解釋一些問題你也會很頭痛。舉幾個還不是那么復雜的例子來說：

　　對=的重載\成員轉換函數\拷貝構造函數\轉化構造函數之間有什么區別和聯系呢？

　　定義一個類成員函數private:virtualvoidMemFun()=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面對的是同樣的問題，面向應用領域的問題：事務處理、遠程訪問、Webservice、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實現了一個PetStore。所以，.Net與J2EE幾乎是可以完全對等的。但微軟確實是一家值得尊敬的公司——我指從技術上，象Web form這種東西，我相信很多Web應用開發者都夢想過甚至自己實現過，但Sun卻一直無動于衷，而且似乎Borland也沒有為此作過太多努力，好像有過類似的東西，但肯定是不怎么成功——Borland已經很讓人敬佩了，我們也許無法要求太多。

2.4 COM技術

　　COM應當是個更廣泛的詞匯，其實我覺得Axtive X、OLE、Auto mation、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(intop1,intop2)在COM中竟然要變成HRESULT add(intop1,intop2,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、Dreamweaver）這一類的東西。而且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的Web logic一個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也一樣
--------------------------------------------------------------------------------
(看完了該帖，個人心中感慨萬分，眺望未來，“大道至簡”乃王者之道