.NET語言的選擇

導 讀：每個組織遷移到.NET將選擇采用哪種.NET語言。微軟提供了四種語言：C#, VB.NET, 可管理的C++和 JScript。本文簡要的討論了我們關于這些語言和哪種語言將被使用的看法。
原文出處：http://www.dotnetdan.com/articles/misc/LanguageChoice.htm

　　每個組織遷移到.NET將選擇采用哪種.NET語言。微軟提供了四種語言：C#, VB.NET, 可管理的C++和 JScript。本文簡要的討論了我們關于這些語言和哪種語言將被使用的看法。

　　簡而言之，我們相信C#將占據主要的市場份額；JScript是沒有競爭力的；C++將被忽視，VB.NET顯現出對市場的準備不足。

　　失敗者

　　JScript

　　我們希望JScript在很少用戶的基礎上結束它的使命。現在很少有關于這方面的資料而且在.NET論壇中也不大有關于JScript的內容。它已經不是主流了。不要在把錢投到這項技術上，放棄它才是最明智的。

　　可管理的C++

　　C++，即使它新的可管理的形式也將漸漸的被忽視。當越來越多的開發者趨向于語法清晰的語言，例如JScript, Java, VB.NET和C#, 使用C++ 的圈子越來越小。另一個C++ 面臨的問題是他不能作為一種教學語言。無疑，盡管如此，有經驗的C++開發者將繼續使用它的能力，模板，多重代碼的繼承性和決定性的最終確定。其余的人都能輕松的應付。

　　勝利者們

　　在這里確切的說應該是勝利者。因為我們相信C# 是唯一的真正的勝利者。VB.NET處在尚無人支持的境地。

　　C#具有相當的優勢

　　大多數專業的軟件開發者，即使獨立開發微軟平臺，如今也將采用一些Java語言中的形式。

　　Java相對于C++和VB6較有利。他去處了許多C++ 中的語法特性而沒有絲毫降低它的功能（因此C++的開發者轉向使用Java是非常容易的）。它在支持面向對象的工具方面要優于VB6。

　　Java以其清晰的面向對象的語法結構和巨大的類庫在大多數主流的具有生產性的語言中占據了最高地位。正是由于這個原因，許多擅長面向對象技術的C++ 和 VB 開發者開始向Java轉移。

　　C# 為那些原本不支持微軟的人轉向使用微軟的開發工具提供了依據。實際上它和Java是一致的，只不過在它們的不同之處，C# 更顯示出了它無可厚非的優越性。此外，它是一種ECMA標準的語言，因此它提供了跨越多平臺的潛在能力。

　　嚴肅的講，開發者想要微軟的最有生產能力和主流的.NET語言，C# 是最明智的選擇。

　　VB.NET孤立無助

　　還剩下VB.NET。我們仍舊對微軟為什么僅僅使VB.NET成為一個更復雜的C# 而提出疑問。也許這兩門語言的歷史背景是知道這個轉變的關鍵，但是我們要討論的是技術方面的問題而不是市場的問題。

　　無疑，VB.NET已經成長到一個新的階段。它現在已經成為了面向對象俱樂部中快速成長的一員。但是現在誰關心它呢？也許是一群對其不滿的人和非面向對象的程序員，但他們將立刻得到它。隨著C#的產生，VB.NET看上去更象是個過時的產品，而不是改進。

　　DecHand代碼生成器能在VB.NET或C#中生成代碼。如果你選擇VB.NET選項，你會得到一個文件，它和C#實現同樣功能，但卻要比C#生成的文件大33% 左右。讀某人用VB.NET編寫的的代碼時，冗長的語句會帶來很多麻煩。當我們把這和前面所提到的原因結合起來時，我們只能希望有經驗的面向對象的開發者應該喜歡C# 勝過VB.NET。

　　那么什么樣的市場會丟掉VB.NET呢? 目前的市場卻使軟件公司僅使用VB來作為開發工具,并造就了一大批VB愛好者.不幸的是,說實在話VB.NET并不是為這些人所開發的。

　　從VB6移植

　　只用VB編寫程序的工作間可能正期望從VB6更新到VB.NET，而且能象現有的VB升級一樣容易。不幸的是，他們可能會遭到嚴酷的打擊。盡管已經有一種工具可以自動完成操作過程，但升級到VB.NET仍然會累人的多。

　　正如我們上面提到的，VB.NET是一種面向對象的語言，而VB6不是。問題在于，如果你不按照面向對象的方式思考，而許多機構也正是這樣做的，你就無法體會到VB.NET轉換經歷的樂趣。因為這不僅僅是一個結構，而是一種范例的轉變，而這種轉變是很昂貴的。很多組織可能會覺得如果他們想改變思維方式，他們不如改變語言。如果VB.NET被很快淘汰掉，也沒什么可驚訝的。

　　過去曾經輝煌而如今孤寂的愛好者

　　最終的市場分割造就了愛好者。對他們而言，VB6是一種可選擇的語言。它提供了簡單而功能強大的工具來構建簡單的應用程序包括GUIs。

　　VB.NET不是這么簡單的。正像我們前面說過的那樣，它是一種功能強大的面向對象的語言。但對于一般的愛好者來說，他們不想也不需要了解‘-isms’和面向對象領域中的抽象事務。他們只想把一項任務盡快完成，而忽略我們某些專業人士所要求的精細之處。

　　為此，過不了不久這些VB愛好者可能不會再繼續使用VB6，或者他們對其不再報有太大的希望了。

　　VB.NET的未來

　　上述注解僅僅是公開發布的.NET BETA版信息的一小部分。當我們看到最終的.NET的產品距離現在還有相當一段長時間，微軟會采用它們當中的一些去生產隱藏著VB.NET復雜性的Visual Studio.NET特性的產品。我們只能翹首以待。我們對此不能做什么，只能相信他們能作到，為了發展，讓我們給微軟以傳統的愛護，這樣他們就會更加努力的去做。

　　關于運行時間的執行

　　如果你看到這里與你所想的相差甚遠，你可能會問“性能怎樣？”，當你在決定用哪一種語言來更快的完成一項產品時，這是每一個人所自然而然所要問的。

　 毫無疑問.NET完全排除了那些標準。

　　為了去理解為什么.NET 語言運行會一樣快（或慢），我們需要去看一下編譯程序，或正好是兩個階段的編譯程序。

　　第一階段發生在你用Visual Studio按Ctrl-Shift-B鍵時。在這一點上，執行一個編譯，你的語言編譯器正在創建中間語言（IL）。第二階段發生在你運行了應用程序時。第二階段有時被看作是JIT編譯（我們會覺得奇怪，但是我們不能解釋）。它為特別使用CPU而使用了IL和產生本土代碼。

　　微軟對第一階段編譯的IL而產生的代碼并不樂觀。相反，他們開始擴展他們所有的能力去優選第二階段IL---本土代碼編譯。他們這樣做是為了使語言的不可知的原因。所有的.NET語言在運行時間的執行上是一樣的。

　　關于調試和編譯者的支持

　　Visual Studio.NET提供了同樣復雜的調試和編譯者使用所有語言的工具。當在Managed C++譯碼時你不會看到更細節的東西，例如，與其他的語言相比。你可以達到你所希望達到的深度。同樣，自動完成的方法也適用于其他語言。

　　總結

　　如果你想找到更安全的辦法，那就使用C#。我們肯定現在VB.NET的功能如此強大，而且C#更是如此，選擇它你不會后悔的，因為我們已經向你清晰地描述了它的生產性能。