C#首席設計師Anders Hejlsberg專訪（1）轉
2024-07-21 02:22:21
供稿：網友
注冊會員，創建你的web開發資料庫，作者：john osborn
譯者：榮 耀
[譯序：精彩技術，不容錯過！限于時間和能力，譯文倘有訛誤，當以英文原版為準。]
7月，o’reilly 編輯john osborn參加了微軟職業開發者會議。在此，他對著名的工程師、微軟.net框架設計師、c#程序語言首席設計師anders hejlsberg進行了采訪。anders hejlsberg因設計pc上最早的語言之一—turbo pascal而出名。他把turbo pascal授權給borland公司，后又率隊開發了delphi—一個極為成功的可視化的客戶/服務應用設計工具[譯注：此處不必拿midas之類較真j]。訪問時在座的還有微軟c#產品經理tony goodhew和o'reilly的windows編輯ron petrusha。
osborn:
我已經看到一些關于c#[發音為"see sharp"]的新聞故事，我注意到有很多似乎傾向于這樣的觀點—或理論上說—c#不是java的克隆就是java的微軟替代物。如果你來寫這個標題，你希望人們怎么評論這門語言？
hejlsberg:
首先，c#不是java的克隆。在設計c#期間，我們考察了很多種語言，如c++、java、modula 2、c、smalltalk等。很多語言都有我們感興趣的相同的核心思想，比如深度面向對象、簡化對象等等。
c#和這些別的語言尤其是java的關鍵不同點是它非常接近c++。在我們的設計中努力使然。c#從c++直接借用了大多數的操作符、關鍵字和聲明。我們還保留了許多被java拋棄的語言特性。為什么java中沒有枚舉，道理何在？我的意思是，拋棄它們是基于何種理論基礎？在c++中，枚舉顯然是一個很有意義的概念。在c#中，我們保留了枚舉并同樣使其類型安全。并且，枚舉不只是整型，它們實際上是從.net基類庫里的system.enum派生下來的強類型的值類型。如果沒有造型轉換，枚舉類型“foo”和枚舉類型“bar”不可互換。我認為這是個重要的差異。我們還保留了操作符重載和類型轉換。c#名字空間的整體結構也非常接近c++。
但是，超越這些傳統的語言論題，我們設計語言的一個關鍵的目標是使c#面向組件。我們向語言自身加入了你在編寫組件時所需要的所有概念。例如屬性[譯注：即property，翻譯為“屬性”，由來已久。我懷疑如果先有attribute的話，property會不會被翻譯為“性質”、“特性”，而attribute才是“屬性”:jl]、方法、事件、特性[譯注：即attribute，截至目前，此名詞譯法仍較混亂。有的翻譯和property不區分，也譯為“屬性”；有的譯為“特性”；有的譯為“屬性信息”。在該名詞譯法尚未統一之前，本著精簡原則，筆者先把它翻譯成“特性”。但注意，xml中的attribute的譯法一般比較統一，即為“屬性”（因為xml中沒有一個類似于property的東西會與之混淆）。因此，本文最后交叉描述c#和xml的部分，請留心“特性”、“屬性”各有所指。]和文檔等，它們都是一流的語言結構。我們對特性所做的工作是全新的和創新的。利用特性可為任何對象加入有類型的、可擴展的元數據。這在目前任何其它程序語言里都看不到的。c#也是第一個合并xml注釋標記的語言，編譯器可以用其直接從源碼中生成可讀的文檔。
另外一個重要的概念是我所說的“一站購物式軟件”[one-stop-shopping software]。一旦你用c#寫代碼，你就在這一個地方寫了一切。不再需要頭文件、idl（接口定義語言）文件、guid和復雜的接口。因為它是自包容的單元。一旦用這種方式寫自描述的代碼，你就可以把你的軟件嵌入到asp頁面或植入各種不同的環境，這在以前是不可能的。
但是讓我們再回到組件這個重要的概念。語言是否應該支持屬性或事件，業界有很多爭論。沒錯，我們是可以用方法表達這種概念。我們可以用諸如“get”或“set”之類的程序塊的命名模式模擬屬性的行為。我們可以用接口和實現接口的適配器并轉發到對象。這都是可能實現的，就象可能在c語言里進行面向對象編程一樣。只是它太困難了，需要太多的手工勞動，為了表達你真正的思想，你最終不得不去做所有的工作。我們認為是時候了，應該有個語言使得創建組件變得容易些。今天程序員在創建軟件組件。他們并不是創建整個應用或整個類庫。每個人都是在創建從宿主環境提供的基組件繼承下來的組件。這些組件重載一些方法和屬性，它們處理一些事件，并把組件安裝回系統。樹立這些概念是關鍵的第一課。
osborn:
你最近在介紹c#時，第一張幻燈片上面寫著：“c/c++家族里第一個面向組件的語言”。
hejlsberg:
是的。這是我的首要目標之一。我們談論一切如何都是對象，這也非常關鍵。以前象smalltalk和lisp語言都可以這么做，但代價昂貴。我認為c#包含一些優美有趣的創新使得組件開發容易些。例如裝箱和拆箱的概念。裝箱可以使一個值類型的值轉換為一個對象，拆箱可以使一個對象轉換為一個簡單類型的值。這在以前或許也有，但我們把它應用于語言的方式是一種優美的創新。
我們努力避免用“象牙塔“的方式設計c#和.net框架。我們承受不起重寫我們所有的軟件的負擔。業界也負擔不起，特別是今天我們正轉移到internet時代。你要善于利用你已經擁有的。所以，我認為互操作性也是關鍵的。我們致力于為程序員提供所有符合internet標準的可互操作的正確的解決方案，例如http、html、xml以及微軟已經存在的技術。所以你不會有如墜深淵的那一刻—發現新的.net框架下沒有提供你用的一些東西，或者你意識到你想利用一些已經存在的api或組件的時候。你已經看到我們已把所有com的互操作能力內建入語言和公共運行時；你已經看到可以使用dllimport特性導入已存在的dll[動態連接庫]；你已經看到即使那些都不能遂你愿，我們也有不安全代碼的概念。不安全代碼允許你寫使用指針的內聯c代碼，可以做不安全的造型轉換，可以抑制內存從而使其不會被意外地垃圾收集[譯注：此處用作動詞j]。
關于不安去代碼有很多爭論，人們似乎認為我們在吸毒或是在干什么別的壞事。我認為這是個誤會。代碼不會僅僅因為標記了“不安全”就表示它不受管制。當然，我們不會扔出不安全的指針使人們容易受到從internet下載的不安全代碼的攻擊。不安全代碼被深深地約束在安全的環境里。我們提供這樣的彈性：1.呆在受管制的代碼箱里完成工作而不會墜入深淵；2.轉入一個不同的語言使用一個不同的編程模型寫本地代碼。如果你停留在這個箱子里，我們會使代碼更加安全，因為系統知道它要干什么。事實上，即使你寫不安全代碼也不意味著你離開了受管制的空間。你的不安全代碼會變得更有效率。
osborn:
請給我多講一些在受管制的環境里處理不安全代碼的機制。
hejlsberg:
好的。描述受管制的執行環境比如smalltalk、java和.net公共語言運行時一個重要特征是它們提供垃圾收集機制。為了提供垃圾收集機制，至少要提供一個現代的垃圾收集器，一個“標記和清掃”垃圾收集器。比起傳統不受管制代碼來說，你必須更多地了解正在執行的代碼。為了找出要排除的死對象，你必須能遍歷堆棧，找到所有活動的根，并指出哪些對象是活動的哪些是不再被訪問的。然而，為了能夠達到這個目標，你必須和你執行的代碼緊密協作。代碼必須具有更好的描述性。它要告訴你它是怎么分布在堆棧里的，它的局部變量存放在何處等等。
當我們在c#中編寫不安全代碼時，你可以做不是類型安全的事，比如指針操作。標記為不安全的代碼并非絕對執行在不可信任的環境里。為了使之執行，你必須授予信任，否則，代碼將不會執行。從這一點來看，和其它本地代碼并無區別—真正的區別是它們仍然運行在受管制的空間里。你寫的方法有一個描述表，它告訴你哪些對象是活動的，因此，不管什么時候你進入這些代碼，你都不必穿越列集邊界。否則，當你進入非描述性的、不受管制的代碼（比如通過java本地接口），你不得不在堆棧上設置一個水印或設置一個屏障。你必須重新列集所有箱子外的參數。一旦開始使用對象，你必須對你觸及的東西小心翼翼，因為gc[垃圾收集器]仍然在另一個不同線程里運行。如果你不使用一些隱晦的方法鎖定對象從而正確地抑制垃圾收集器，它可能會移去對象。如果你忘記那么做，那你將會不走運。
我們采用了一個不同的方式。我們說過，“讓我們集成這個到語言中去。讓我們提供聲明，例如fixed聲明，它可以讓你抑制對象以和gc協作并集成之。”用這種方法，我們提供最佳方式，帶領所有已經存在的代碼一起向前，而不是僅僅將它們拋棄。這是一個不一樣的設計方式。
osborn:
因此，你們對不安全代碼的處理方式是—不安全代碼的內存實際上是在垃圾收集器的監視之下？
hejlsberg:
是的。但是，就象所謂的“購者自慎，不包退換”一樣，它并不安全。你可以獲取指針并做錯事—當然，你在本地代碼里也能干同樣的錯事。
osborn:
我認為另一個易混淆的地方，是理解c#在哪兒停止和公共運行時從哪兒開始。與它從公共運行時庫得到的相比，c#語言自身的創新是什么？
hejlsberg:
好的，我想這個混淆來源于這樣一個事實—當人們談論java時，他們并不真的知道哪個是語言哪個是運行時。當人們談論java時，混淆就發生了。哪個語言哪個是運行時？當他們談論java時，他們到底指的是什么？java，語言？java，語法？還是java，平臺？人們把這些不同的方面混成一團。我們的方式表明我們想成為一個跨語言的平臺。我們將創建一個平臺，它允許你進行多語言編程，并且共享一套公共的api（應用編程接口）。讓我們承認這一點，一些人喜歡用cobol編程，一些人喜歡用basic編程，一些人喜歡用c++，還有一些人將會喜歡用c#—我希望。但是，我們不會試圖告訴你，忘記你曾經做過的所有的事情吧，我們不會說，“現在只有一種語言，在這個競爭中不會再有創新了”。我們說業界因為彈性而友好。java是怎么來的？它的出現是因為在它前已經存在一些編程語言，而在它后也還將會出現一些編程語言。我們想打造一個平臺，在此你可以偏愛某種語言但不會否定整個價值取向；我們想打造一個平臺，它將是創新的。今天誰在幫助cobol程序員？誰把他們帶入web？只有在.net平臺上你才可以把富士通cobol嵌入asp頁面。我的意思是，它真正是革命性的！
osborn:
假定.net平臺上支持多語言，那為什么選擇c#而不是visual basic、c++甚至cobol？是什么使c#如此引人注目？
hejlsberg:
首先，c#可以使我們從一張白紙開始。也就是說，我們沒有任何向后兼容性的負擔。這顯然會使事情簡化，無論從是從實現的立場還是從使用的立場都是這樣。例如，在c#中，我們只有一類類型，并且總是被垃圾收集。而另一方面，受管制的c++有兩套。因為它要保留非垃圾收集風格的編程。因此，在c#中，只需要你理解一些簡單的概念。
語言是一個有趣的東西，它是一種口味；語言又是一件嚴肅的事情，它是程序員選擇的一種生活方式。我是指，我們意識到我們不能走出來說，“這兒有個平臺，你只可以使用一個基礎語言。”即使在那個平臺上用一種語言可以做所有的事情，人們還是可能不喜歡它的語法。他們可能喜歡大括號或者一些其它的程序塊分界符。那是他們熟悉的。那是使他們感覺舒服并且富有生產力和能力的。我們對待c#的方式僅僅是為認為語言太復雜的c++程序員和認為丟失了一些c和c++語言特性的java程序員提供一個可選物。我們尋求一個簡化c++的方式并投入到一個多語言的平臺中，它提供更大的互操作性，并且它提供完備的組件概念等等。
goodhew:
一件有趣的事情來自于我們對開發者跟蹤調查，60%以上的職業開發人員使用兩種或更多的語言去創建他們的應用。特別是當我們問他們都用哪些開發工具的時候，我們得到的答案是：沒有哪一種開發語言將會是終結者并且所有程序員都會使用它。正如anders早先所說，人們期望某種能夠滿足他們所做或他們所感的語法。這是一個個人選擇。這也是整個.net平臺所關心的—提供給開發者一個語言實現選擇。我想我們做了件漂亮的工作。你基本上可以在visual basic.net和c#中做同樣的事情。visual basic對大多數程序員來說仍然是易接受的。c#則具有更多的活動空間并且比vb更富威力。
osborn:
這意味著在c#中可用更少的聲明實現更多？
hejlsberg:
是的。意味著通過不安全代碼，你可以得到更多的能力。
osborn:
也就是說，不能在vb中寫不安全代碼？
hejlsberg:
是的。不可以。
goodhew:
但是，基本上，兩種語言都可以做同樣的事。和visual studio 6相比，這是一個根本性的改變。在visual studio 6.0中，如果你想創建多線程的mts對象，并且你是一個vb程序員，你就沒招。你不得不用c++。現在，有了.net框架，你可以使用任何一種你喜歡的語言。
hejlsberg:
這就是我在一般會議談話里說過的，.net框架提供一致的編程模型。在語言和框架的進化過程中，我們一貫似乎都是把一種程序語言綁死在特定的api和特定的編程方式上。vb是快速應用開發工具；mfc（微軟基礎類）是子類化的方式；asp則是把東西塞到web頁面中。在每一種情況下，你對編程模型的選擇決定了你對程序語言和可使用的api的選擇。每次當你變換框架時，它都增加了你學習新語言和api負擔的工作量。我們真正努力統一這一切，我們提供一套api，一套支持可視化設計的工具，我們還提供一個可以任選一種適合你的語言的彈性。
osborn:
我不知道這對那些使用象vbscript和jscript腳本語言的有什么作用？
hejlsberg:
.net框架下奇妙的事情之一是使腳本語言能夠編譯。看看asp+，現在，實際上，在你的頁面里運行的是真正編譯的代碼。它不是后綁定的、調度查找的—如果用戶沒有點擊頁面，你不會看到運行時錯誤。asp+開發者可以使用visual basic.net完整的威力而不是vbscript。并且第一次，他們可以使用perl、python和其它流行語言，如果他們這么選擇的話。
petrusha:
服務端的javascript現在也能被編譯？
hejlsberg:
沒錯。
goodhew:
.net框架使得使用腳本語言就象用具有完全特性的語言一樣，因為它們現在訪問的是一個真正的編程框架并且訪問的是同一基類api。你應該看看搞jscript實現的伙計們都已經實現了什么。[編注：jscript是微軟對ecma 262語言規范(ecmascript 版本 3)的實現，只有一些很小的例外（為了保持向后的兼容性），jscript是對ecma標準的完整實現]。所以.net平臺提供了一個公共語言框架，對腳本寫作者來說，具有極大的好處。
osborn:
我們已經討論關于java、c++和腳本。在pdc[譯注：（微軟）職業開發者會議]，我聽很多人爭論.net il（il是微軟中間語言，所有編譯器都必須產生它以運行在.net框架上）和運行于java虛擬機中的java字節碼并沒有什么不同。從你的談話中，顯然你并不同意這一點。你介意進一步評論它們之間的區別嗎？
hejlsberg:
好的。首先，il的思想是一個很老的思想了。你可以追溯這個概念到ucsd pascal p-machine（一個早期的個人計算機pascal實現）或者smalltalk。p-code曾被basic和visual basic使用，word的一個組成部件，內部使用p-code引擎，因為它更精簡。所以，p-code并不是什么新東西。
我認為，我認為我們使用的il的方式對此感興趣：我們給你一個選擇—如果你愿意—你可以控制把il編譯或翻譯為本地代碼的時機。實際上，使用受管制的 c++，你可以直接從源程序生成本地代碼。受管制的 c++還可以生成il，就象c#和vb那樣。當你安裝你的代碼時，我們給你一個編譯選項，可把il編譯成本地代碼。因此，當你運行它們時，就不會有即時編譯負擔。我們還給你提供了一個動態運行和編譯代碼的選項—即時編譯。有了il，就給你帶來了很多便利，比如它提供了這些能力：移植到不同的cpu結構并引入真正的類型安全并在此之上創建安全的系統。
我認為我們il的設計和java字節碼關鍵的不同在于，我們做出了超前的決定—不用解釋器。我們的代碼永遠本地運行。因此，即使產生il，你也不會運行解釋器。我們還有不同風格的jit。對于精簡框架，我們有econnojit，就象我們稱呼它的一樣，它是一個非常簡單的jit[編注：精簡.net是.net框架的一個子集，是為移植到其它設備和平臺設計的]。對于桌面版，我們有完全功能的jit。我們甚至有可和我們的c++編譯器共用一個后端的jit。不過，這都會比較耗時，因此你只應該在安裝時使用它們。
一旦你做出偏向于執行本地代碼而不是解釋碼的決定，它就會深深地影響il設計。它改變了應該包括那些指令，應該包括哪些類型信息，以及它應該如何傳輸。如果你仔細看看兩個il[譯注：即.net il和java字節碼]，你就會發現它們非常不同。從某種意義上講，我們的il是類型中立的。指令里沒有指定參數類型的信息。進一步說，它是靠已經壓棧的東西推斷出來的。這種方式使il更為精簡。無論如何，一個jit編譯器需要知道哪些信息，因此沒有理由在指令里攜帶它們。所以，最終我們做出了不同的設計決定，而這使得容易把il翻譯成本地代碼。
osborn:
解釋方式和你描述的方式有何不同？
hejlsberg:
解釋器的核心是一個循環—從p-code流取得一些字節，然后進入一個大大的switch[譯注：類似于程序語言里的switch...case]聲明：“哦，這是add指令，因此它到這兒來，但是這不是…”等等。
解釋器模擬cpu。我們反其道而行之，我們只走一條道，我們一直都走一條道，我們把指令翻譯為機器碼。現在，在econojit的情況下，機器碼實際上非常簡單，它只創建一個調用和壓棧指令的列表，并且調用運行時幫助器，然后運行時幫助器替換這個列表。當然，這個代碼比解釋器代碼執行得快。
osborn:
讓我用一句話來總結一下：你們完全編譯代碼。因此當你編譯完時，字節已經完全準備好運行了，盡管從il翻譯成機器碼的時機可能不同。
hejlsberg:
是的。但是，如果它是在一個內存受限的小設備的環境里，有可能當運行完就被扔掉了。
