Charles：好的。今天我們請到了微軟設(shè)計編程語言的大師們。請你們介紹一下自己。
    （譯者注：Channel 9的主持人，從其對話來看，應(yīng)該是編程出身，對于程序有很好的理解）
    Herb：我是Herb Sutter，我是VC++小組的架構(gòu)師。
    （譯者注：C++標(biāo)準(zhǔn)委員會主席，Exceptional C++系列的作者，C++領(lǐng)域的大牛人）
    Erik：Erik Meijer，我在VB以及C#小組工作。
    （譯者注：先是SQL Server組的架構(gòu)師，現(xiàn)為VB、C#組的架構(gòu)師，從事把CLR、關(guān)系數(shù)據(jù)庫、XML數(shù)據(jù)合為一體的偉大事業(yè)）
    Brian：我是Brian Beckman，和Erik Meijer一起工作。呵呵
    （譯者注：物理學(xué)家，天體物理為主，業(yè)余時間寫程序，包括編譯器，自稱來自從事影視娛樂業(yè)的家族，家里以其從事科學(xué)研究為奇）
    Anders：我是Anders Hejlsberg，我的技術(shù)領(lǐng)域是C#。
    （譯者注：微軟的“技術(shù)小子”，公認(rèn)的牛人，C#的主要設(shè)計者，.NET框架的重要參與者。微軟之前，Anders是Borland的工程師，Turbo PASCAL的主要開發(fā)人員，Delphi的首席架構(gòu)師）
    Charles：我們今天訪談主要討論兩個相關(guān)的論題：可組合性（Composability）與編程語言。作為程序員，當(dāng)我們構(gòu)造系統(tǒng)時，總是要面對這兩個問題。你們是創(chuàng)設(shè)語法，搭建架構(gòu)的人。所以，我想討論的一點是，你們是如何協(xié)調(diào)工作的？三個語言——C#、VB和C++，都在演進，同時又服務(wù)于不同的目的，C++更多服務(wù)于系統(tǒng)級，C#和VB更多偏向應(yīng)用層面。而且，語言在不斷創(chuàng)新（譯者注：謝謝ponda的修正）。這一切是如何形成的？你們一起工作嗎？你們是如何決定語言的創(chuàng)新的（譯者注：謝謝ponda的修正）？你們是一起設(shè)計，還是想到什么后再與他人共享？很抱歉提這樣的怪問題，請試著回答。
    Anders：我想，你說的兩種情況都存在吧。事實上，早在我們做LINQ之前，Erik就在Comega項目做了很多工作了。在LINQ和Omega之間有很多相似之處，有很多互相影響的部分。我們一直在討論相關(guān)的問題。而且，Erik實際也在C#設(shè)計組中，所以，我們總是就當(dāng)前的工作及時交換意見。VB組和C++組的人也在一幢樓里工作，大家經(jīng)常碰到一起。所以，我認(rèn)為這一切是相互滲透，以及不斷聊天的結(jié)果。
    Charles：但是我的意思是，你們是否也象最終用戶一樣對自己做出區(qū)分？比如，有的事情在VB中能做，C#中就做不了。比如，對于VB來說，完全的晚綁定以非常簡單的方式實現(xiàn)了，而C#中就沒有晚綁定。為什么VB和C#有這樣的不同？你們有意如此的嗎？
    Anders：我認(rèn)為這個問題更多的是歷史原因。我想說的是，我們必須考慮歷史因素，尤其當(dāng)你討論VB時更是如此。VB有其悠久而豐富的歷史，從一開始，VB就作為晚綁定的語言出現(xiàn)。（開始時）VB沒有任何類型。很顯然，晚綁定對于VB來說有某種核心作用。但是，從那時開始，VB已經(jīng)逐步演進為一種更為“強類型”的語言，到現(xiàn)在，甚至你可以把VB看作一種支持晚綁定的強類型語言。呵呵。但實際上，這個過程是相反的。C#從一開始就是強類型語言，而且直到現(xiàn)在，我們都堅持早綁定。這并不是說我們在未來也不會支持晚綁定，但是，我們很可能以不同于VB的方式支持，而且可能對晚綁定的方式做些改進。C#是否支持晚綁定其實只是一種選擇。對于老式的弱類型對象模型來說，比如OLE，如果我們從晚綁定角度出發(fā)，會比從早綁定角度出發(fā)好討論得多，因為這種對象模型無非就是對象的若干方法的交互，反射，等等。
    Charles：這些東西完全可以靠底層幫你完成……
    Anders：是的，對，非常正確！
    Herb：語言之間的差異在一定程度上是由用戶引起的。對于靠近底層編程的C和C++程序員來說，性能永遠都是一個核心和主要的問題。你可能發(fā)現(xiàn)不同語言有不同的特性，但是，更經(jīng)常的是，你會發(fā)現(xiàn)這些不同特性想要解決的都是同一類的問題，比如，“并行執(zhí)行”?，F(xiàn)在，沒有誰能夠忽視這個問題，并且，一種語言如果想在未來5到10年保留在主流編程語言的隊伍中，這個問題就是無法忽視的，因為這是硬件的發(fā)展方向。我們正處于一個新的時代，50年以來，我們首次在非單核的機器上工作。任何人都無法忽視這個現(xiàn)象。
     　　因此，就這個問題來說，大家都要處理一些相似的東西，但是，處理方式、語法可能不同，具體的特性也可能不盡相同。我也相信，不同語言推出同一特性的時間先后順序也不相同，因為不同語言針對不同的客戶群體服務(wù)，客戶要求的東西不一樣，因此，對于特性處理的時間先后順序并不一致。就像Anders說的，各種情況都有一些。
    Erik：是這樣的。對VB和C#有怎樣的差異，我可以給出一個具體的例子。該例子是“無名函數(shù)（或‘lambda表達式’）”。我們想在VB中也加入這種功能。首先就是尋找正確的語法。我們向VB項目組要到了VB的名稱表，名稱表中的名字支持兩種語法的都有（VB和C#）。但是，這次他們想要更像關(guān)鍵字的名字，而不是C#那樣長長的名字，因為他們覺得像關(guān)鍵字的名字更加“VB化”一些。這里你看到的就是語法上的區(qū)別。但是，在語義上也是有區(qū)別的。當(dāng)你查看一個大函數(shù)內(nèi)部的，嵌套很深的結(jié)構(gòu)，比如“for”循環(huán)的時候，語言是何時、如何處理變量捕獲，如何進行實例保護的就非常不同。在C#中，每次循環(huán)時實例都被保護，而在VB中，象JavaScript那樣，變量是被隱性提升到函數(shù)頂部的。所以，在變量捕獲方面，語義上的區(qū)別也存在。有時這些區(qū)別是極其細(xì)微的，你必須寫非常變態(tài)的程序才能看到這些區(qū)別。