大約2個月前，在Herb Sutter的網站上看到了一個連結，內容是Channel9網站對他和其他三名微軟架構師就“程式語言發展”進行的採訪，架構師中有Anders Hejlsberg。一看之下，就被這個視訊迷住了。這些大師站在歷史的高度，通觀全域性又不失細節，高屋建瓴，有點有面地談到了多個語言的發展和語言間的相互關係。看完之後，感到視野得到了不小地開拓，對於語言、框架、工具的關係；對於靜態（動態）型別、函式（命令）型程式設計；對於“可組合性”、“併發性”、“抽象層次”都有了更多的認識。

    說開點，隨著網際網路的真正深入生活，隨著“多核”時代的到來，IT技術領域正在經歷一場變革。這場變革和“可組合性”、“併發性”這兩個關鍵詞息息相關。圍繞著這兩個關鍵詞，若干新點子，新技術被提出來，而這些新技術往往與軟體產業生產者所用的工具——程式語言緊密相關。因此，作為一個軟體職業者（或愛好者），聽聽大師的談話，對於把握這場變革的脈搏，跟上變革的潮流都不無裨益。看完視訊，感到由於語言關係，如此好的材料無法為廣大中國程式設計師所知，實在是個遺憾，於是萌發了編譯的念頭。水平所限，錯誤難免，歡迎大家指正！此文在本人部落格上釋出後，drdirac和pongba 兩位朋友對譯文提出了若干補充和修正，在此表示感謝！

    Charles：今天的訪談主要討論兩個相關的論題：可組合性與程式語言。作為程式設計師，當我們構造系統時，總是要面對這兩個問題。你們是創設語法，搭建架構的人。所以，我想討論的一點是，你們是如何協調工作的？三個語言——C#、VB和C++都在演進，同時又服務於不同目的，C++更多服務於系統級，C#和VB更多偏向應用層面這一切是如何形成的？你們一起工作嗎？你們是如何決定語言創新的？你們是一起設計，還是想到什麼後再與他人共享？

    Anders：我想，你說的兩種情況都存在。早在做LINQ之前，Erik就在COmega專案上做了不少工作。LINQ和COmega相互影響，相似之處很多。我和他一直在討論相關問題。實際上，Erik也在C#設計組中，我們總是在交換意見。VB組和C++組的人也在一幢樓裡，大家經常碰到一起。

    Charles：但我的意思是，你們是否也像終端使用者一樣對自己做出區分？比如，有的事情在VB中能做，C#中就做不了。例如，VB以非常簡單的方式實現了完全的晚繫結，而C#中根本沒有晚繫結。為什麼VB和C#如此不同？你們有意這樣設計的嗎？

    Anders：我認為，影響這個問題更多的是歷史原因。VB有其悠久而豐富的歷史。VB剛出現時就是晚繫結語言，沒有任何型別。很顯然，晚繫結對VB來說有某種核心作用。但是，從那時起，VB已逐步演進為一種更“強型別”的語言，到現在，你甚至可以把VB看作一種支援晚繫結的強型別語言。呵呵。實際的過程剛好相反。C#從一開始就是強型別語言，而且，直到現在我們都堅持早繫結。這並非說C#未來也不會支援晚繫結，但是，它很可能以不同於VB的方式來做，而且可能會有所改進。C#是否支援晚繫結其實只是一種選擇。對於老式的弱型別物件模型來說，比如OLE，如果我們從晚繫結角度出發，會比從早繫結角度出發好討論得多，因為這種物件模型無非就是物件若干方法的互動，反射等。

    Herb：在一定程度上，使用者造成了語言之間的差異。對於靠近底層程式設計的C和C++程式設計師來說，效能永遠都是一個主要問題。你可能發現不同語言有不同特性，但是，更經常的，你會發現這些不同特性想要解決的是同一類問題，比如，“併發執行”。現在，沒人能忽視這個問題。在未來5到10年，一種語言如果想留在主流程式語言的隊伍中，這個問題就無法忽視，因為這是硬體的發展方向。我們正處於一個新時代——50年來，我們首次在非單核的機器上工作。任何人都無法忽視這點。因此，就這點來說，大家面臨相似的問題。但是，根據處理方式、語法的不同，具體特性也會不盡相同。我也相信，不同語言推出相似特性的時間先後順序也不相同，因為不同語言服務於不同客戶群體，客戶要求不同。就像Anders所說，各種情況都有一些。

    Erik：我給個具體例子，說明VB和C#的差異。這例子是“無名錶達式（或lambda表示式）”。我們想在VB中加入這種功能。首先就是尋找正確的語法。我們向VB專案組要到了VB的主名稱表，名稱表中的名字往往對VB和C#都適用。但是，這次他們想要更像關鍵字的名字，而不是像C#那樣長長的名字，他們覺得像關鍵字的名字更加“VB化”一些。這裡你看到的就是語法上的區別。但在語義上也有區別。當你檢視一個大函式內部巢狀很深的結構，比如for迴圈時，語言是何時、如何處理變數捕獲、如何進行例項保護就非常不同。在C#中，每次迴圈時例項都被保護，而VB有點像JavaScript，變數被隱性提升到函式頂部。所以，在變數捕獲方面也存在語義上的區別。有時，這些區別極其細微，你必須用非常變態的程式才能觀察到。

    Anders：只要你寫出依賴這樣的特性的程式，我們就能找出成百的Bug。

    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#一些，主要因為它的操作符過載。為什麼我喜歡操作符過載？因為我做奇怪的線代計算，如四元數、八元數，此時用一個小加號就能夠代表一大堆怪異的計算。

    可能聽上去有點像是使用模板，但絕不是這樣，我一用模板就會開始想：模板的前處理器是完備的，也許我可以僅用模板就實現出一個連結串列處理庫來解決。很快，我就會偏離真正的數學思考。在應用程式絕對需要晚繫結的場合，比如，那些小的計算模擬器。此時，我很自然地會選擇VB。至於C++，大多數時候，它被用來實現其他的語言。在用於科學的環境下，我多次實現過Scheme。總之，就是泛談“可組合性”。

    Anders：當我開始程式設計生涯時，進入程式設計這行的學習曲線就是：學習要使用的程式語言本身。各個程式語言幾乎在每個方面都不相同。語法是你要學習的很大一部分。但這是以前的事了，現在你要學習巨大的框架，這個框架正越變越大，語法只是頂上的一顆“小櫻桃”，我認為這方面確實進展很大。但是，實際上起作用的東西是學習所有的API，學習你所基於的，越來越大的平臺或者框架。如今，學習曲線的90%都耗費在這上面。掌握了這些，你就可以在C++、C#或者VB.NET什麼的之間，毫不費力地進行語言轉換，將部分專案使用這種語言，部分專案使用那種，並且找出組合這些語言的解決方案。相對於以前，實際上是不久之前，這是個主要的進步。當然，所有這些得以出現，是由於有了通用的型別系統，以及各種語言中的那些抽象。每種語言之間的差別則是細微的，而且這些差別說不上來有什麼特別的理由。

    Brian：有時，這些語言必須綜合運用。比如，如今的Windows程式設計就是一大苦事：你必須懂PHP、JavaScript、HTML、XML、SQL等等，要把這些東西全寫到名片上，你就只有小小的一塊地方可以寫自己的名字了。當然，能夠同時使用多種語言也有好處，至少你可以選擇自己喜歡的語法。

    Erik：我們的程式語言之所以有差異，還是因為這些語言沒有能夠統一起來，在語言下面還有若干不一致的地方，我們實際上是被強迫使用不同的東西。CLR就不一樣，基於CLR上使用相同的庫，這些語言之間的排他性就要少一些，你可以選擇，而非被迫使用某種特定的語言。

    Brian：目前我們做得很多工作就是減少大家被迫使用某種語言這種情況。我們努力改進平臺，增加更多的功能，提供更多的.NET庫。

    Charles：但是，C++除之外，像VB和C#這樣的語言，確實繫結在某個框架上。這樣的話，在一定意義上是否有侷限性？如函式型程式等將如何融入到我們所談的巨大的框架中呢？比如Haskell，又比如流行的F#，它們的結構與現在的語言完全不同。

    Erik：如果我們用“命令型語言”程式設計，我們的基本成份是“語句”。“語句”使用並且共享“狀態”，從而導致不太好的“可組合性”。你不能拿著兩段語句，然後簡單地把它們粘合到一起，因為它們的全域性狀態不能很好地互動。這就導致“命令型語言”不能很好地組合到一起。如果你看看LINQ，就會發現我們已經更多地採用“函式型語言”的風格，所有的東西都基於表示式。“表示式”從其定義來說就是可組合的。從一定意義上來說，我認為在C#3和VB9中沒有什麼東西是Haskell或F#中沒有的。這裡面有一些深奧的事情，如果你看看Haskell的型別系統，你就會發現這個型別系統跟蹤程式的副作用。這給了你一定形式的可組合性。現在你雖然不能把有某種副作用的語句組合到有其他副作用的語句上，但是，你可以組合副作用相同的東西。F#有一個非常強悍的型別推斷機制，它從設計之初就考慮了型別推斷。我們以前也有型別推斷，這並非什麼新東西，但是現在的型別推斷要考慮很多困難因素，比如，過載，這些東西使型別推斷很困難。如果你從這個角度來看，我認為我們已經在很大程度上採用了濃厚的“函式型”風格，並且以相當“可組合”的方式來使用表示式和lambda表示式。

    Anders：我們對“函式型程式設計”的興趣並非學院式興趣。實際上，當程式語言向前推進時，我們面臨兩類挑戰。一是古老的追求——不斷提高程式設計師的生產率，對此將沿用一直以來的方法：提升抽象的層次，給程式設計師垃圾回收機制、型別安全、異常處理，甚至是全新的“宣告型”程式語言等。在提升抽象層次的過程中，正如Erik指出的，這些“宣告型”語言獲得了更高層次的“可組合型”。“函式型”語言之所以有魅力，因此你可以做出“沒有副作用”，或者其他承諾，這樣一來可組合性就極大地提高了。不僅如此，在如何保證多核處理器、多CPU，比如，32個CPU始終忙碌，我們也會有所收穫。顯然，當我們更多地使用“函式型”或者“宣告型”風格的程式設計時，我們更有可能把執行時框架構建得能更好地發揮多核的優勢，更好地處理併發。如果以“命令型”風格來工作，我們能夠發揮的餘地就很小，因為你無法預見所有動作——這兒拿點東西，那兒放點東西，所有動作必須序列執行，否則不可預料的事情就會發生。

    Charles：作為程式設計師，使用瞭如此巨大的一個處理引擎——比如CLR之後，當然認為這些底層的東西應該被抽象掉。你的意思也是，如果我使用了一個4核的機器，執行時引擎應該有能力負責在CPU上的分配分配程序。

    Anders：你這樣想很正常。但是，CLR以及目前我們工業中絕大多數的執行時，都是“命令型”引擎，其指令集都相當傳統，比如，堆疊增長；它們也擁有易變的狀態，包括易變的全域性狀態等等。在此之上，之所以能進行“函式型”程式設計，是因為“函式型”程式設計從本質上來說，是“命令型”程式設計所具備的能力集的一個子集。現在我們想做的是最大化這種靈活性，但其實不過也就是讓“函式型”能力子集越來越相關，使其越來越主流化而已。

    Herb：我認為有必要將“函式型”程式設計領域劃分成兩個部分。我非常同意Anders和Erik的意見。我不太同意的是這樣的措辭：我們之所以繼續使用“命令型”程式語言，是因為這是大家目前所能理解的；通用程式開發者目前的工作並未取得巨大的成功；市場對於“所有的東西都是表示式，所有的語言都應該是表示式型別的語言”這樣的理念已經非常接受了；“函式型”語言是“序列執行”病的好藥方。我們要想使“函式型”語言運轉良好，關鍵點並不是處理好基本的表示式問題，而是處理好lambda表示式和副作用的問題，是能夠將表示式作為第一級的程式設計要素來使用——LINQ也是最近才在做，關鍵是能夠指出lambda表示式和Closure（譯者注：函式型程式語言中的一個概念，可以方便地組合函式，返回函式）的副作用。實際上，最後這點目前是缺失的。這些東西在“命令型”語言中也是要處理的東西。我為什麼提這些？因為我覺得說“函式型”語言是方向，目前的“命令型”語言不夠好，因此是垃圾，必須要拋在腦後，全面採用“函式型”語言這樣的說法不對。我認為，“函式型”語言到底能夠幫助程式設計師完成哪些工作，目前還不太明瞭。比如，能夠用它寫通用程式碼嗎？能夠用它系統級程式碼嗎？當然，“函式型”語言有不少我們能夠借鑑的好東西，比如lambda表示式，比如Closure，C#借鑑了，C++也在借鑑，這些語言因此增色不少。關於“函式型”語言還有另一個問題，那就是，有兩種型別的“函式型”語言。一種是沒有副作用的，因此就沒有共享、易變的狀態的問題；一種是人人都在使用的。因為你不太可能說，“瞧，我是完全併發安全的，因為每次我都從這個“微型像冊”向量中得到一個拷貝。”或者說，“我操作這些元素的時候，我都是取得一個拷貝”。不錯，這時是沒有共享、易變的狀態，但是否能完全併發安全則不一定。

    Anders：我的意思是，在類似C#或VB這樣“命令型”程式語言中加入“函式型”結構，能給我們提供“以函式型風格”寫程式庫的能力，從而我們就能夠非常明確地說，如果你能保證傳入的lambda表示式是純粹的函式，我們就能保證正確地把它分散到若干個執行緒或者CPU上，最後再把它綜合起來，給出一個正確的結果。我們能保證程式碼執行得更快，同時還不用作任何編碼上的修改。然而，如果你在寫一個大大的For迴圈，我們永遠都不可能保證做到前面所說的，此時，“函式型”程式設計能夠提供給你的是一系列表示式，再加上“把程式碼當作引數傳遞”，“型別推斷和泛型程式設計可以正確地繫結所有的型別”等特性，這樣你就能更方便地編寫“可組合的演算法塊”。

    Charles：這不就削弱了抽象嗎？

    Herb：我想指出的是當前所有語言都刻意不保證 “沒有副作用”。之所以如此的原因是，除非所有的語言都新增一些機制讓程式設計師可以清除副作用，我們這些做語言的人不敢打這個包票。但是，新增這樣的機制涉及到眾多參與者，大家必須一起思考、一起討論什麼是最好的方法，這個過程會很漫長。我們所做的是相信程式設計師，因為我們自己不知道。然而，很多情況下，程式設計師也不知道，因為他寫的函式要呼叫其他的庫。而程式設計師根本不知道他使用的庫的副作用如何。這裡，“可組合性”又浮上水面了。程式設計師可以增加一個間接層來處理這個問題，但是，除非他擁有涉及到的所有程式碼，沒有人能夠清楚地知道副作用會如何，問題依然存在。這就是難題所在。上面這些討論對“鎖”也適用，因為“鎖”也是全域性問題，對“可組合性”是個障礙。

    Brian：在這點上Haskell做得很好，Haskell是“永遠沒有副作用”的範例。

    Erik：是的，但做到這點的過程也很痛苦，因為並非所有情況都一目瞭然。一旦你的庫程式碼有副作用，而且因此使程式設計師的程式碼必須按照某種順序執行，在某種意義上，你是用匯編語言在程式設計，因為程式設計師將不再能用“表示式+表示式”的方式來寫程式碼，他必須先對某個表示式求值，再對另一表達式求值，最後把值相加。因此，我認為我們在這點上幹得還是不夠漂亮。

    Brian：現在，我們在“流庫”上有例子。好訊息是，我們已經有Haskell向你展示如何以“可行性”方面的代價，換取絕對純粹的方式。當然，除Haskell外，我們有各種“雜牌”語言。

    Anders：沒有純粹的好或壞，我認為，雖然進展緩慢，我們仍然快到一個令人滿意的中間點了。我完全同意說：如果我們確實能夠保證函式的純粹性，生活將會非常美好。最終我們得做到這點。

    Erik：但是，副作用也並非全然是壞事，如果函式使用了一個區域性變數，這就是使用了一個狀態，但是，函式本身還可以是純粹的。我覺得很難完全避免副作用，一些東西可以是區域性不純粹而整體純粹的。

    Herb：回過頭，讓我們從整體上看看“可組合性”。讓我吃驚的一件事是，很多時候，人們甚至都沒有意識到“可組合性”是個問題，以及自己實際上經常碰到這個問題。其實，整個軟體工業乃至整個世界已經基於可組合的軟體了。在硬體會議上，我經常對硬體公司提到的是：硬體的併發問題已經被仔細地探索過了，而且，當前消除共享、易變狀態的最好辦法就是“鎖”；但是，鎖是一種全域性資源，不能被組合；“被鎖”是經常發生的事情，而當擁有“鎖”時，我還能呼叫任何其他的未知的程式碼；於是，“可組合性”被破壞了。說到這裡，有的聽者往往一臉茫然：這有什麼問題嗎？我於是會問，你們是否上網下載別人剛剛釋出的，自己喜歡的新軟體，比如，某個瀏覽器然後馬上使用呢？答案是肯定的。我於是會再問，你們是否意識到了，當你們這樣做時，這些軟體很可能都是第一次在終端使用者的機器上被組合，被使用？既然如此，你們怎麼可能對其進行測試？這時，屋子裡有百分之十的人會露出恍然的表情，因為此前他們沒有想過這個問題：這些軟體是第一次在終端使用者的機器上被組合，我們怎麼進行測試？正因如此，“可組合性”是更重要的一個問題。更不用說我們現在有AJAX應用程式，以及眾多的外掛經常被下載，而且被要求在同一個使用者介面中協調工作。

特別感謝周愛民先生推薦此文，與廣大程式設計師共同分享。