C#：昨天，今天和明天：和 Anders Hejlsberg 座談，第二部分

C# ： 昨天 ， 今天和明天 ： 和 Anders Hejlsberg 座談，第二部分

源貼地址：

C#: Yesterday, today, and tomorrow

作者：John Osborn
10/17/2005
翻譯：我要去桂林

Osborn：

回到和語言相關的問題，我現在還是想說說LINQ。微軟 Visual Stuido .NET 的產品經理 Tony Goodhew 在一次訪談中說過，微軟的研究表明越來越多的人傾向於在編程中使用2種或者更多的語言來工作。好像現在有一種感覺，這就是語言只是 syntactic sugar 文法糖塊。你選擇某種語言是因為你對他最滿意。

你認為現在有這種變化嗎？我們以前沒有過多談過這方面的。

Hejlsberg:

好吧，的確沒有談過，但是文法是不是走到了盡頭？我的意思是我們只是用 XML 文檔來描述抽象文法樹來表現你想做的，這也是一種文法，但是很顯然，這對程式員來說並不怎麼有用。因此，我認為程式設計語言在人們的腦海中佔據這一個特別的位置，如果人們用語言說話是表達自己的一種方式，程式語言也和自然語言一樣用來表達你自己的。

實際上，文法是程式設計語言的組成和表現形式，在很多方面，文法影響你如何思考你的程式，等等。因此，我認為文法很重要，非常重要。

Osborn：

那麼從文法的角度來看，C#有什麼特別的呢？你能給我們描述一下嗎？

Hejlsberg:

好，我認為我們現在所說的面向組件類的特點是極為重要的。我們努力的做到沒有其他的方法可以做這件事情。我們嘗試發現文法間的協同，我的意思是：這很難用語言來精確的形容。那我們來看看語言層級整合的LINQ查詢吧。這個可擴充的模型是：我們採用方法調用的方式來實現這一點。當你使用 where , orderby  和  select 語句來寫查詢語句的時候，我們把這個轉換成對等的方法調用：Where, OrderBy 和 Select 集合。我們把你寫的查詢作為 Lambda 運算式語句傳遞給相關的方法。

這樣，查詢就變成連在一起的方法調用，從而查選也變得可讀性更好，這就像一個語言膠水一樣。上面的轉換是立即執行的，如同 foreach 迴圈轉換成：從while 迴圈中獲得一個數字一樣。這個小小的改進非常有利於你在更高的層次上思考問題。你明白我的意思嗎？

Osborn：明白。

Hejlsberg:從這方面來講，文法在很大程度上影響了你如何思考問題的，儘管這些文法上的東西根本和事情本身毫無關係。

Osborn:

是的。從書籍出版商的角度來看，我們公司自己的曆史資料上顯示，古老的C++語言有自己的地盤，在書籍出版量上只有很少的增長；去年VB的銷量下降了百分之20到百分之25。C# 書籍銷量還算平穩。但是很平淡。

Hejlsberg:哦，這樣呀。

Osborn：

情況很清楚，從我們的銷量來看，似乎有股從VB轉向到C#的動向，或者其他的。可是C++卻自始至終佔領者一部分市場。

Hejlsberg:

沒錯。VB 和 C# 在同一個程式員的群體裡是相互競爭的。C++ 扮演這一個特別的角色，可是C++的核心是寫非託管的代碼，是相對底層的編程。我知道我剛才是泛化的說明，你也可以使用 STL 來作基於模板的編程。標準模板庫有他偉大的地方。我只是說，從更廣泛的背景上看C++寫出的應用程式和用 VB 和 C# 寫出的程式是應用於不同的目的的。

Hejlsberg:對於C++應用領域的跌落，我感到並不驚訝。

Osborn：

我知道一個人不能用C++來寫Managed 程式碼。

Hejlsberg:

從個人出發點來看，我也不會用它來寫Managed 程式碼。但是，你要是讓我來寫一個編譯器，這可不能是Managed 程式碼，那我還是會用C++的。經過這麼多年的發展，我認為作為一條通用的規則，寫Managed 程式碼的理由會越來越多。原因很簡單啦，硬體變得更加強大，犧牲點 CPU 和記憶體來換取更高的生產效率來說就變得更重要了。我覺得這時一個非常有價值的命題。並且，我堅信這會逐漸的成為共識。另外，託管世界的也變得更加精彩啦。也就是，越是有創新的地方就越有更多的程式被企業所應用。

泛型和C#

Osborn：

侃了這麼多，我們來說點關於 C# 2.0 的事情吧。很明顯，C# 語言朝著泛型的方向發展有很長一段時間了。

Hejlsberg:沒錯。

Osborn：

那麼，相對於其他的語言而言C#的泛型有什麼不同呢？

Hejlsberg:

哈哈，靠，很明顯我更想讓你說：就在C#和Java之間比較吧。

Osborn：沒錯，我也是這個意思。

Hejlsberg:

首先，我非常高興的我們在2.0裡面加入了泛型程式設計。你現在看我們做的C# 3.0 裡面的很多東西都是泛型在起作用。這的確是意義深遠的，引入泛型後為類型系統開闢了一個新的空間，也開啟了實現更多可能性的大門。比如：沒有泛型的協助，我們不可能做到語言層級整合的查詢LINQ。從這個意義上講，這是更多有趣功能後面的發動機。泛型也是現實編程世界裡的解決方案的好幫手。

對，有更多的類型是很好的，這意味著你可以更快的發現錯誤，因為只有很少的運行時動態檢查程式的類型，因此你可以寫出很好的代碼來。

現在，看看 java 和 C# 這對冤家吧，從文法學上面看兩者實現泛型的形式是很相似的。他們都像 C++ 的模板，這是繼承下來的。

現在我們拋開表面看本質，Java 和 C# 的泛型實現機制是截然不同的。我認為最大的不同在於：.NET平台下的泛型不只是一個語言特色。泛型根植於 CLR 和 .NET 的類型系統。這也就是為什麼泛型可以在啟動並執行時候表現出來。

而 Java 則選擇了另一個不同的方式實現泛型，一言以蔽之，他們是在編譯時間實現的。而且 Java 編譯器把泛型化從代碼中移除了，並注入了對象，有效對象替代了型別參數資訊。也就是說呀，Java 在運行時根本沒有泛型這一說。這就有意思啦，一方面可以讓泛型跑在一個未經修改的 VM 虛擬機器上，另一方面強加給你很多讓然吃驚的限制和規則。相對於我們的泛型實現來說，java 的泛型並不能帶來效能的收益，很顯然嗎，不管外表 List<T> 看起來多麼泛型，Java 在運行時壓根沒泛型這馬事兒，你不得不自己做運行時的動態檢查和類型轉換。

更微妙的是，因為 Java 沒有在運行時的泛型資訊，你從你的編譯後的代碼丟失了泛型資訊。。如果在運氣期間，有人給你一組自訂的對象，他們傳遞給你的僅僅是對象，如過你想從對象中推測是這些對象的更多資訊是辦不到的，因為額外的資訊已經被移除了。

在現實世界裡，我們越來越多的依賴運行中代碼和動態行為的動態產生和檢查，而Java 的泛型實現對我來說，是很大問題，他缺少程式運行時候的真實表現。

Osborn：

牛呀，這麼說 .NET 實現的泛型允許我們……

Hejlsberg:

太對了。如果我定義一個 List<T> 作為一個 object , 我可以問 “這是什麼“？系統可以告訴我，這是一個列表。他還可以告訴我們，這是一個 List<T> ，T 代表 Customers 類。我還可以說：為什麼不給我一個 System.Type 的 List<T>也可以是，你為什麼沒有把 T 綁定到 Order ？也就是說我們可以把類型轉換為 List<Order> ，並建立他的一個執行個體。說了這麼多，總之，我可以通過反射在編譯的時候，在啟動並執行時候來實現上述功能，這是一個巨牛的功能呀。