翻譯整理 毛竹 南海
C#介紹
最近微軟宣布了它的最新編程語言C#，這是一種面向對象的編程語言，它將作為Visual Studio中的一部分推出。C#（發音為“C-Sharp”）既保持了C++中熟悉的語法，並且還包含了大量的高效代碼和面向對象特性。據微軟產品經理透露，C#語言將在保持C/C++靈活性的基礎上為程序員帶來更高效的RAD開發方式。它不僅能用於WEB服務程序的開發，並且還能開發強大的系統級程序。
微軟還沒有正式宣布這一新語言技術，該技術將以測試形式出現在微軟打算在7月中旬在專業開發會議上分發的Visual Studio 7中。Visual Studio 7將於明年某個時候正式發售。
Layman介紹說C#包含使XML編程更為輕松的技術。微軟將使它的下一代工具軟件、操作系統和應用支持XML技術。
新的編程語言還將包含虛擬機設備。微軟官員已經公開表示C#技術和該公司去年開發的 Java競爭技術Cool沒有關聯。微軟官員拒絕回答是否計劃在Visual Studio 7中提供微軟設計的視窗版Java Visual J++的某個版本。
C#的特性
現在，微軟仍在一邊繼續反駁其競爭對手Sun控告它改變了Java語言的訴訟，一邊在對美國反壟斷指控頑抗到底，但與此同時，微軟的天才程序員們也在技術上進行著一場補救的措施。那就是他們已經開發出來的C#語言，這是一種非常類似於Java的語言，微軟深知即便是微軟陣營中也有著相當一部分人喜歡Java語言，所以這次干脆就用C#來滿足他們的願望，這是一種非常完美的語言，適用於各種操作系統，並且與Windows緊密地結合在一起。
微軟表示這種新的程序設計語言並不針對Java，但它將是C++的革新。而這正是Java所追求的兩個主要目標之一（另一目標當然就是可移植性）。微軟一直夢想著能開發出能與Java在Windows NT系統上抗衡的語言。C#的自動內存管理以及和Java一樣都使用的C語言語法，似乎讓這個理想成為現實。
微軟稱C#是由C和C++派生而來的一種“簡單、流行、面向對象、類型安全”的程序設計語言，C#意在綜合Visual Basic的高效率和C++的強大功能。但這種說法是否准確呢？由於C#的結構很像Visual Basic的ActiveX，它顯然是沖著RAD開發者來的。但同時，“C#提供了C++的強大功能”這種說法也稍嫌誇張，將來很可能變成空頭支票。
對某一對象接口的更新，微軟稱之為“繼承”，當然“繼承”是就“對象”而言的。但是，雖然“對象”這個詞我們經常碰到，卻很少有人真正理解了它的含義。微軟的用戶，甚至它自己的員工都經常把“對象”和“接口”弄混。所以微軟干脆就用接口來定義各種對象，結果導致了“面向對象編程”（OOP）被微軟弄得亂七八糟。現在，微軟又在大踏步地前進了（雖然它內心還是很小心），它把它建立在接口基礎上的“對象”集成到了開發工具裡。不過它走得實在過了頭，它甚至把對另一對象接口的更新稱之為“繼承”。
這個“繼承”給程序員們帶來的好處就是語言無關——只要接口維持其兼容性，用Visual Basic寫成的對象在C#和C++中也可以良好地運行。但此特性是以真正的OOP技術和平台的可移植性為代價的。每個對象都被編譯和注冊到Windows子系統，只要你能訪問這個子系統，你就能訪問這個對象。來吧！歡迎來到.NET和NGWS的世界！——Windows平台從來沒有完完全全地讓人產生這樣完整的依賴性。他們的動機當然要遭到全世界對微軟有偏見的人的懷疑，當然，完全依靠此技術的C#也不例外。
事實上，C#將是完全依靠Windows的最完美的產物。那些困繞Java SDK, MFC 和SET的數據庫已成為過去。你想放入C#的任何東西（無論何種語言），只要在Windows的.NET子系統下建立和包裝的都可以使用Windows的運行庫。
用MSIL進入.NET
當人們訪問Usenet或一些新聞組時，會有一些諸如新語言和平台有效性之類的問題。什麼時間和努力能解決這些問題呢？當然，如沒有牢固的事實和有說服力的證據，即使是最有幫助的響應者，權威機構也會對他的斷言持保留意見。我沒有參加今年的專業開發者會議（PDC），因此我的發現都是基於那些與會者的反饋。
人們對微軟過去幾周的大肆宣傳，最基本的錯誤理解就是C#只是Visual C++的改進版本。完全不是這麼回事。C#和Java沒有直接聯系。它的特征設定是從Java獲得的靈感。它的語法同Java一樣，源自C和C++，但它的執行是完全新的，只依靠.NET結構。
C#也並非字節碼（bytecode）。微軟一位員工羅伯特.舒密特詳細描述道：“C#編譯程序產生的是‘微軟中間語言’（MSIL）……但虛擬機或其他類似的技術則不能用於解釋這種中間語言（IL）。相反地，每當應用程序載入或JIT編譯程序需要編譯它時，IL就會被轉換成本地代碼。一旦這種轉換完成，可以執行的代碼實際上是本地代碼。”實質上，雖然這種方案有點像Java程序通過一個JIL編譯程序，但這裡最終的JIT編譯是100%的本地代碼，而Java的JIT產生的結果是不同的。
C#的弱點
這個方案也暴露了微軟對C#和.NET介紹中的一些有趣的漏洞。MSIL是.NET提供的一個新特性，允許很流行的程序設計語言編譯到一個單獨的公用語言。（.NET支持的語言種類是相當驚人的）。這些語言都要服從一種叫“通用語言規范（CLS）”的構架。微軟稱之為“CLS兼容語言和類庫之間可互操作的通用語言”。
編譯所有的語言到一個單一的公用語言上，能讓“繼承”通過多重語言真正執行。這輕而易舉的掃除了C#可能遇到的錯誤概念。.NET組件使用COM的IDispatch，它只允許接口執行。它比先前C#被評定為一種OOP語言的看法容易接受得多。它在程序設計上或許像Java一樣是面向對象的。
但不幸的是CLS這種包括MSIL的共享語言基礎，只讓RAD開發者受益，而損害了硬件的核心開發者，有人認為創造一種新程序設計語言的目的就是有能力充分運用它和服務於可微調的執行能力，這一點在CLS世界裡是做不到的。老實說，加速充分利用從來不是許多語言的唯一目標。許多語言的唯一目標（最矚目的是像Visual Basic和Java的RAD語言）是加速和美化開發和展開能力，而不僅僅是運行時刻的速度。
舒密特文章中所提到的確實包含了相關和值得注意的評論：你可以用C++指定.NET，並在你的代碼中運用所有C++特性。同時，因為.NET在運行時刻不能檢驗C++代碼是否安全，此語言並不遵從CLS規范，裡面所書寫的程序也受到限制。作為應對，微軟往Visual C++裡添加非標准管理的擴展。用這些擴展寫的代碼能符合CLS規范。
C#將把微軟領向何方就一目了然了。因為所有項目編寫會只依靠MSIL和CLS JIT編譯程序。這樣C#或任何MSIL前端語言比Java任何時候都快。但很不幸，程序設計和編譯程序級的優化不能在非微軟的平台上充分利用，想在非Windows平台上展開.NET，再充分運用它們也是不現實的。
JAVA是C#的競爭對手
盡管.NET是微軟一手締造的，它並不是只能在Windows上使用。微軟准備盡力為那些COM對象提供傳統幫助（所有的OLE， ActiveX等等在下一代Viual Studio推出後，都將成為一個legacy平台）。但.NET不會圍繞COM建造。新平台無疑將補充COM，並與它幾乎天衣無縫地配合，但一點也不會依靠COM。這表明這種結構本身能夠Macintosh, UNIX. BeOX展開。這樣命名，是因為除了CLS構架是平台獨立的，C#將用到的和所有遵從CLS的數據庫也是平台獨立的。也就是說，它們都是遵從CLS的，如果一個本機MSIL編譯程序在平台上有效，那麼它們能在運行時刻為任何結構進行編譯。微軟也積極爭取被ECMA標准接納，他們先前的Javascript已被接納。 當Visual Studio. NET推出時，開發團體肯定會有不同的反應。"微軟又開發了一個新平台"，這已嚇倒那些本來對微軟平台統治憂心忡忡的人了。然而更重要的是C#或.NET戰略不會對原始C++構成太大威脅，那麼有理由推論C#和.NET將是Java的有力競爭者。考慮相反方面：Java VM靠翻譯字節碼來運行應用程序。CLS在運行時刻本機編譯。Java平台只支持Java語言。.NET只支持MSIL，但一些無限制的高級語言如C#，Visual Basic,甚至Eiffel和COBOL都能啟動MSIL。Java運用執行轉接提供真正的OOP技術。MSIL，C#也是如此。在Java平台，簡單地移動平級文件，項目就可以展開為產品目錄。據說，.NET平台的項目也可輕松展開而不像以registry-happy Com為基礎的項目。或許Java平台真正的優勢只在於政治上的正確性--它不是微軟搞出來的，且目前有成千上萬的執著的宗教追隨者。
作者的看法
具有諷刺意味的是，雖然我很了解Java和C#，我仍被冠以高級Visual Basic程序設計師的稱號。人們會認為我這樣一個VB設計師將是反對微軟的偏執狂。但我也得面對現實。老實說：VB是一個RAD開發工具。別只顧著精美，別記著真正的對象。迅速得到結果才是重中之重。在商業世界裡，純粹的技術和結果不總是能相吻合的，短期結果往往勝過長期生產力。這是不幸的，但在許多公司中，這卻是事實。這些公司就是C#的主要用戶。我會使用C#嗎？當然會用！我現在使用Visual Basic，但轉入C#有何不好？我更欣賞Java和OOP語言的精美，但因為我進行的所有項目中，短期成果一直勝過長期成果，我已沒有時間去考慮替換Windows平台。但如從純技術和信仰角度來說，Java和C++的程序設計師就有足夠理由關注C#，這是微軟維持壟斷的又
