譯者：程化
視頻在Channel 9，鏈接http://channel9.msdn.com/Showpost.aspx?postid=273697。
名字為Anders Hejlsberg, Herb Sutter, Erik Meijer, Brian Beckman: Software Composability and the Future of Languages
大家可以找來看看。
個人感覺這些大牛高屋建瓴，有點有面地談到了多個語言的發展和語言的相互關系，對于我們開拓視野非常有幫助。由于只能靠聽來翻譯，篇幅又長，只能分段慢慢來。而且，水平所限，難免錯誤，請大家指正。
Charles：好的。今天我們請到了微軟設計編程語言的大師們。請你們介紹一下自己。
（譯者注：Channel 9的主持人，從其對話來看，應該是編程出身，對于程序有很好的理解）
Herb：我是Herb Sutter，我是VC++小組的架構師。
（譯者注：C++標準委員會主席，Exceptional C++系列的作者，C++領域的大牛人）
Erik：Erik Meijer，我在VB以及C#小組工作。
（譯者注：先是SQL Server組的架構師，現為VB、C#組的架構師，從事把CLR、關系數據庫、XML數據合為一體的偉大事業）
Brian：我是Brian Beckman，和Erik Meijer一起工作。呵呵
（譯者注：物理學家，天體物理為主，業余時間寫程序，包括編譯器，自稱來自從事影視娛樂業的家族，家里以其從事科學研究為奇）
Anders：我是Anders Hejlsberg，我的技術領域是C#。
（譯者注：微軟的“技術小子”，公認的牛人，C#的主要設計者，.NET框架的重要參與者。微軟之前，Anders是Borland的工程師，Turbo PASCAL的主要開發人員，Delphi的首席架構師）
Charles：我們今天訪談主要討論兩個相關的論題：可組合性（Composability）與編程語言。作為程序員，當我們構造系統時，總是要面對這兩個問題。你們是創設語法，搭建架構的人。所以，我想討論的一點是，你們是如何協調工作的？三個語言——C#、VB和C++，都在演進，同時又服務于不同的目的，C++更多服務于系統級，C#和VB更多偏向應用層面。而且，語言在不斷創新。這一切是如何形成的？你們一起工作嗎？你們是如何決定語言的創新的？你們是一起設計，還是想到什么后再與他人共享？很抱歉提這樣的怪問題，請試著回答。
Anders：我想，你說的兩種情況都存在吧。事實上，早在我們做LINQ之前，Erik就在Comega項目做了很多工作了。在LINQ和 Omega之間有很多相似之處，有很多互相影響的部分。我們一直在討論相關的問題。而且，Erik實際也在C#設計組中，所以，我們總是就當前的工作及時交換意見。VB組和C++組的人也在一幢樓里工作，大家經常碰到一起。所以，我認為這一切是相互滲透，以及不斷聊天的結果。
Charles：但是我的意思是，你們是否也象最終用戶一樣對自己做出區分？比如，有的事情在VB中能做，C#中就做不了。比如，對于VB來說，完全的晚綁定以非常簡單的方式實現了，而C#中就沒有晚綁定。為什么VB和C#有這樣的不同？你們有意如此的嗎？
Anders：我認為這個問題更多的是歷史原因。我想說的是，我們必須考慮歷史因素，尤其當你討論VB時更是如此。VB有其悠久而豐富的歷史，從一開始，VB就作為晚綁定的語言出現。（開始時）VB沒有任何類型。很顯然，晚綁定對于VB來說有某種核心作用。但是，從那時開始，VB已經逐步演進為一種更為“強類型”的語言，到現在，甚至你可以把VB看作一種支持晚綁定的強類型語言。呵呵。但實際上，這個過程是相反的。C#從一開始就是強類型語言，而且直到現在，我們都堅持早綁定。這并不是說我們在未來也不會支持晚綁定，但是，我們很可能以不同于VB的方式支持，而且可能對晚綁定的方式做些改進。C#是否支持晚綁定其實只是一種選擇。對于老式的弱類型對象模型來說，比如OLE，如果我們從晚綁定角度出發，會比從早綁定角度出發好討論得多，因為這種對象模型無非就是對象的若干方法的交互，反射，等等。
Charles：這些東西完全可以靠底層幫你完成……
Anders：是的，對，非常正確！
Herb：語言之間的差異在一定程度上是由用戶引起的。對于靠近底層編程的C和C++程序員來說，性能永遠都是一個核心和主要的問題。你可能發現不同語言有不同的特性，但是，更經常的是，你會發現這些不同特性想要解決的都是同一類的問題，比如，“并行執行”。現在，沒有誰能夠忽視這個問題，并且，一種語言如果想在未來5到10年保留在主流編程語言的隊伍中，這個問題就是無法忽視的，因為這是硬件的發展方向。我們正處于一個新的時代，50年以來，我們首次在非單核的機器上工作。任何人都無法忽視這個現象。因此，就這個問題來說，大家都要處理一些相似的東西，但是，處理方式、語法可能不同，具體的特性也可能不盡相同。我也相信，不同語言推出同一特性的時間先后順序也不相同，因為不同語言針對不同的客戶群體服務，客戶要求的東西不一樣，因此，對于特性處理的時間先后順序并不一致。就像Anders說的，各種情況都有一些。
Erik：是這樣的。對VB和C#有怎樣的差異，我可以給出一個具體的例子。該例子是“無名函數（或‘lambda表達式’）”。我們想在VB中也加入這種功能。首先就是尋找正確的語法。我們向VB項目組要到了VB的名稱表，名稱表中的名字支持兩種語法的都有（VB和C#）。但是，這次他們想要更像關鍵字的名字，而不是C#那樣長長的名字，因為他們覺得像關鍵字的名字更加“VB化”一些。這里你看到的就是語法上的區別。但是，在語義上也是有區別的。當你查看一個大函數內部的，嵌套很深的結構，比如“for” 循環的時候，語言是何時、如何處理變量捕獲，如何進行實例保護的就非常不同。在C#中，每次循環時實例都被保護，而在VB中，象JavaScript那樣，變量是被隱性提升到函數頂部的。所以，在變量捕獲方面，語義上的區別也存在。有時這些區別是極其細微的，你必須寫非常變態的程序才能看到這些區別。
Anders：每次你寫出依賴這樣的特性的程序時，我們就能找出成百的Bug。呵呵
Erik：是啊是啊。
Brian：你逃不出作戰室的
（譯者注：微軟的“作戰室”，是產品、程序、測試人員一起對需求、找Bug之所在。）
Charles：這樣看來，大家都同意不同語言在相互影響，不斷演進。對于VB和C#來說，你們有相同的核心——處理引擎，你們必須在CLR的基礎上出發，隨著CLR的演進而演進。很顯然，C++屬于另一個世界。但是，各種語言要互相影響，你們必須在C#中加點什么來吸引用戶，讓他們用C#而不是VB.NET，是吧？應該不止是語法的區別，語言中必須還有一些核心的東西來吸引用戶。
Herb：我認為你說的是對的。但是，我不同意你提出的理由，說我們必須在各自的語言中加點什么特性吸引用戶，從而使他們不去使用其他的微軟的語言。為什么呢？比如我吧，我更加關心使用C++或者C#的用戶到底需要什么，我怎樣才能幫助他們把工作完成得更好。也許某處有某種很牛的特性的語言，但我的工作是——怎樣才能使客戶的工作更成功？我必須要考慮客戶會如何集成，我怎樣做才能使客戶工作得更好，這也是CLR的核心所在，因為目前已經不是靠一種語言就能做完整個項目的時代了。我懷疑在稍有點規模的實際項目中，是否還有人僅僅依靠一種開發語言。一般說來，你用腳本語言寫點東西，其他語言寫工具和組件，系統語言寫核心的東西。你不停地在做集成。這就帶來了我們所討論的“可組合性”的問題。因為“可組合性”本質上就是跨語言產生的問題。當你寫Web瀏覽器時，你不知道某個插件是用C#，C++，某種CLR擴展，還是其他什么寫的。不管如何，這些東西必須一起工作，這就是主要挑戰之所在。因為，要想使這種“可組合性”成為現實，我們必須時時將CLR和CLR以外的東西當作白盒來考慮。但是，我們這樣做的時候又會碰到“鎖”的問題。“并行執行”已經越來越重要了，但是， “鎖”是完全不具備組合性的。因此，這是“可組合性”面對的主要障礙。我實際上已經轉移到另一個話題上了。總之，對我而言，這更多的是一個語言交互的問題，而非語言競爭的問題。
Brian：我插句嘴。我在一定程度上代表了用戶。我是個物理學家，同時，我也經常寫點小程序，進行模擬和仿真，解決一些數學問題。要想成功，“可組合性”對我的來說是絕對地重要。我可以不在乎編程語言，但是我很在乎該語言是否有我所需要的組件。我有點夸張了，因為我其實還是在乎編程語言的，呵呵。基本上，我十分愿意使用任何能使我的工作更簡單的編程語言。
這里，我先戴上頂“老人”帽，談談這個世界的歷史上，非常少的成功軟件之一——數值計算庫。這些東西是N年以前用FORTRAN寫的。幾十年以來，人們用這些庫解決了許多非常重要的科學問題。任何頭腦正常的人都不會想坐下來從頭寫一個“線性代數包”或者類似的東西。有許多數學家終其一生在完善這些軟件包。我們需要的是“互操作性”。不簡單的是互操作性，我們需要的是“可組合性”。所有人都知道，FORTRAN不支持遞歸，因為所有的變量都是引用傳遞。這就帶來了包之間接口問題。如果你想要集成某種自身內部不支持集成的東西，你就不能再需要集成的兩邊使用這樣同一個包用于集成，這行不通。呃，我已經忘了最開始我在說啥了，哈哈，我盡講些物理小故事了。讓我回到C++、C#和VB上。這些語言我都要使用，我更喜歡C#一些，因為我喜歡它的操作符重載。為什么我喜歡操作符重載？因為我做數學計算，類似于四元數和八元數的奇怪線代運算，用一個小加號就能夠代表那些要進行的一大堆計算。
Erik：伙計，也許你想用的是模板？哈哈。
Brian：（譯者注：看樣子生怕別人認為自己不知道模板）不，我才不想用模板呢。只要我一用模板，我就會開始想：喔，模板的預處理器是圖靈完備的，也許我可以僅用（模板）就實現出一個鏈表處理庫來……很快，我就會偏離真正的數學思考。在應用程序絕對需要晚綁定的場合（比如，那些小的計算模擬器什么的，晚綁定是成功的關鍵），此時，很自然地，我會選擇VB。至于C++，天哪，大多數時候，C ++用來實現其他的語言，做這類事C++很拿手。在用于科學的環境下，我多次實現過Scheme。
總而言之，我就是泛泛談談“可組合性”。
Anders：如果你回過頭去看看十年之前，會發覺潮流已經逐漸變化了。當我開始編程生涯時，進入編程這行的學習曲線就是：學習要使用的編程語言本身。各個編程語言幾乎在每個方面都不相同。語法是你要學習的很大一部分。這是以前的事了。現在，你要學習巨大的框架，這個框架正越變越大，語法只是頂上的一小顆櫻桃。我認為我們在這方面確實前進了很多。很有趣的是，編程語言就像你的眼鏡一樣，所有的東西根據編程語言的不同，要么看著是玫瑰色的，要么是紫色的，如此等等。但是，實際上起作用的東西是學習所有的API，學習你所基于的，越來越大的平臺或者框架。如今，學習曲線的90%都耗費在這上面。掌握了這些，你就可以在C+ +、C#或者VB.NET什么的之間，毫不費力地進行語言轉換，將部分項目使用這種語言，部分項目使用那種，并且找出組合這些語言的解決方案。相對于以前，實際上是不久之前，這是個主要的進步。當然，這些能出現，是由于有了通用的類型系統，以及各種語言中的那些抽象。每種語言之間的差別則是細微的，而且這些差別說不上來有什么特別的理由。
Brian：是的，在有的情況下，多種語言互相關聯。比如，如今的Windows編程就是一項大苦差：你必須懂 PHP、JavaScript、HTML、XML、SQL等等，要把這些東西全寫到名片上，你就只有小小的一塊地方可以寫自己的名字了。哈哈哈。當然，能夠同時使用多種語言也是有好處的，至少你可以選擇自己喜歡的語法……
Erik：我們的編程語言之所以有差異，還是因為這些語言沒有能夠統一起來，在語言下面還有若干不一致的地方，我們實際上是被強迫使用不同的東西。CLR就不一樣，基于CLR上面的東西使用相同的庫，這些語言之間的排他性就要少一些，你可以選擇，而非被迫使用某種特定的語言。
Brian：目前我們做得很多工作就是：減少大家被迫使用某種語言這種情況。我們努力改進平臺，增加更多的功能，提供更多的.NET庫。值得大家期待喔！
Charles：但是，像VB和C#這樣的語言，C++除外啊，就如你們所說，它們確實綁定在某個框架上。這樣的話，在一定意義上是否有其局限性？我的意思是，讓我們談談函數型程序，這種程序如何能夠融入到我們所談的巨大的框架中呢？比如Haskell，有比如流行的F#，它們的結構（與現在的語言）完全不同。
Erik：很有趣的是，傳統上，如果我們用“命令型語言”編程，我們的基本成份是“語句”。“語句”使用并且共享“狀態”，從而導致不太好的“可組合性”。你不能拿著兩段語句，然后簡單地把它們粘合到一起，因為它們的全局狀態不能很好地交互。這就導致“命令型語言”不能很好地組合到一起。如果你看看LINQ，就會發現我們已經更多地采用“函數型語言”的風格，所有的東西都基于表達式。“表達式”從其定義來說就是可組合的。你如何創建一個新的表達式？你用小的表達式組合出一個大的表達式，你使用lambda表達式，如此等等。從一定意義上來說，我認為在C#3和VB9中沒有什么東西是Haskell或F#中沒有的。這里面有一些深奧的事情，如果你看看Haskell的類型系統，你會發現這個類型系統跟蹤程序的副作用。這就給了你一定形式的可組合性。現在你雖然不能把有某種副作用的語句組合到有其他副作用的語句上，但是，你可以組合副作用相同的東西。F#有一個非常強悍的類型推論機制，F#從設計之初就考慮了類型推論。我們以前也有類型推論，這并非什么新東西，但是現在的類型推論要考慮很多困難因素，比如，重載，這些東西使類型推論很困難。如果你從這個角度來看，我認為我們已經在很大程度上采用了濃厚的“函數型”風格，并且以相當“可組合”的方式來使用表達式和lambda表達式。
Anders：我想插進來說幾句。我們對“函數型編程”的興趣并非學院式興趣。我們面臨的一個挑戰，嗯，實際上，當編程語言向前推進時，我們面臨兩類挑戰。挑戰之一是古老的追求——不斷提高程序員的生產率，對吧？將采用和一直以來在采用的方法是——提升抽象的層次，對吧？給程序員垃圾回收機制、類型安全、異常處理，甚至是全新的“聲明型”編程語言，如此等等。在提升抽象層次的過程中，正如Erik指出的，這些“聲明型”語言獲得了更高層次的“可組合型”。“函數型”語言之所以有魅力，正是因為你可以做出“沒有副作用”，或者其他別的什么承諾，這樣一來可組合性就極大地提高了。不光如此，在我們將如何讓多核處理器、多 CPU（比如，32個CPU）保持忙碌上，我們也會有所收獲。顯然，當我們更多地使用“函數型”或者“聲明型”風格的編程時，我們更有可能把運行時框架構建得能更好地發揮多核的優勢，更有可能更好地并行化。如果以“命令型”風格來工作，我們能夠發揮的余地就很小，因為你無法預見所有動作——這拿點東西，那放點東西——背后可能帶來的影響，所有這些必須串行執行，否則不可預料的事情就會發生。
Charles：這很有趣。我的意思是，作為程序員，使用了如此巨大的一個處理引擎——比如CLR之后，當然認為這些底層的東西應該被抽象掉。（譯者注：Charles顯然比較吃驚。）你的意思也是，如果我使用了一個4核的機器，運行時的引擎應該有能力負責分配進程（在CPU上的分配）。
Anders：嗯，你這樣想很正常。但是，CLR以及我們的工業中目前絕大多數的運行時，都是“命令型”引擎，其指令集都是相當傳統的，比如，堆棧增長啥的，以及擁有易變的狀態，包括易變的全局狀態等等。在此之上能夠進行“函數型”編程，因為“函數型”編程從本質上來說，是“命令型”編程所具備的能力集的一個子集。現在我們想做的是最大化這種靈活性，但其實不過也就是讓“函數型”能力子集越來越相關，使其越來越主流化而已。