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