微軟架構師談程式語言發展(轉貼)
阿新 • • 發佈：2019-02-19
轉自:http://blog.csdn.net/hellothere/archive/2007/07/29/1715993.aspx
本文是對微軟Channel 9中採訪幾個語言大牛的視訊的翻譯。
視訊在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
大家可以找來看看。
個人感覺這些大牛高屋建瓴，有點有面地談到了多個語言的發展和語言的相互關係，對於我們開拓視野非常有幫助。由於只能靠聽來翻譯，篇幅又長，只能分段（估計有4-5段）慢慢來。而且，水平所限，難免錯誤，請大家指正。
微軟架構師談程式語言發展（一）
譯者：程化
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更多偏向應用層面。而且，語言在不斷創新（譯者注：謝謝ponda的修正）。這一切是如何形成的？你們一起工 作嗎？你們是如何決定語言的創新的（譯者注：謝謝ponda的修正）？你們是一起設計，還是想到什麼後再與他人共享？很抱歉提這樣的怪問題，請試著回答。
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：我插句嘴。我在一定程度上代表了使用者。我是個物理學家，同時，我也經常寫點小程式，進行模擬和模擬，解決一些數學問題。要想成功，“可組合性 ”對我的來說是絕對地重要。我可以不在乎程式語言，但是我很在乎該語言是否有我所需要的元件。我有點誇張了，因為我其實還是在乎程式語言的，呵呵。基本 上，我十分願意使用任何能使我的工作更簡單的程式語言。
這裡，我先戴上頂“老人”帽，談談這個世界的歷史上，非常少的成功軟體之一——數值計算庫（譯者注：謝謝drdirac的修正）。這些東西是N年以前用 FORTRAN寫的。幾十年以來，人們用這些庫解決了許多非常重要的科學問題。任何頭腦正常的人都不會想坐下來從頭寫一個“線性代數包”（譯者注：謝謝 drdirac的修正）或者類似的東西。有許多數學家終其一生在完善這些軟體包。我們需要的是“互操作性”。不簡單的是互操作性，我們需要的是“可組合性 ”。所有人都知道，FORTRAN不支援遞迴，因為所有的變數都是引用傳遞。這就帶來了包之間介面問題。如果你想要整合某種自身內部不支援整合的東西，你 就不能再需要整合的兩邊使用這樣同一個包用於整合，這行不通。呃，我已經忘了最開始我在說啥了，哈哈，我盡講些物理小故事了。讓我回到C++、C#和VB 上。這些語言我都要使用，我更喜歡C#一些，因為我喜歡它的操作符過載。為什麼我喜歡操作符過載？因為我做數學計算，類似於四元數和八元數（譯者注：謝謝 pongba的修正）的奇怪線代運算，用一個小加號就能夠代表那些要進行的一大堆計算。
Erik：夥計，也許你想用的是模板？哈哈。
Brian：（譯者注：看樣子生怕別人認為自己不知道模板）不，我才不想用模板呢。只要我一用模板，我就會開始想：喔，模板的前處理器是圖靈完備的（譯者 注：謝謝drdirac的修正），也許我可以僅用（模板）就實現出一個連結串列處理庫來（譯者注：謝謝pongba的修正）……很快，我就會偏離真正的數學思 考。在應用程式絕對需要晚繫結的場合（比如，那些小的計算模擬器什麼的，晚繫結是成功的關鍵），此時，很自然地，我會選擇VB。至於C++，天哪，大多數 時候，C++用來實現其他的語言，做這類事C++很拿手。在用於科學的環境下，我多次實現過Scheme（譯者注：謝謝drdirac的修正）。
總而言之，我就是泛泛談談“可組合性”。
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以及我們的工業中目前絕大多數的執行時，都是“命令型”引擎，其指令集都是相當傳統的，比如，堆疊增長啥 的，以及擁有易變的狀態，包括易變的全域性狀態等等。在此之上能夠進行“函式型”程式設計，因為“函式型”程式設計從本質上來說，是“命令型”程式設計所具備的能力集的 一個子集。現在我們想做的是最大化這種靈活性，但其實不過也就是讓“函式型”能力子集越來越相關，使其越來越主流化而已。
Herb：我想，我們有必要在“函式型”程式設計領域做一個進一步區分，將其劃分成兩個部分。我非常同意Anders和Erik的意見。我不太同意的是這樣的 措辭：我們之所以繼續使用“命令型”程式語言，是因為這是大家目前所能理解的；通用程式設計師目前的工作並未取得巨大的成功；市場對於“所有的東西都是表達 式，所有的語言都應該是表示式型別的語言”這樣的理念已經非常接受了；“函式型”語言是“序列執行”的好藥方。我們要想使“函式型”語言運轉良好，關鍵的 並不是處理好基本的表示式問題，而是處理好lambda表示式和副作用的問題，關鍵是能夠將表示式作為第一級的程式設計要素來使用——LINQ也是最近才在 做，關鍵是能夠指出lambda表示式和Closure（譯者注：函式型程式語言中的一個概念，可以方便地組合函式，返回函式）的副作用。實際上，最後這 點目前是缺失的（Anders也附和著：對，對）。這些東西在“命令型”語言中也是要處理的東西。我為什麼提這些？因為我覺得說“函式型”語言是方向，目 前的“命令型”語言不夠好，因此是垃圾，必須要拋在腦後，全面採用“函式型”語言這樣的說法不對（譯者注：呵呵，對Anders的說法有點急了，畢竟是泡 在C++上，對C++有感情的人）。我認為，對於“函式型”語言能夠幫助程式設計師完成哪些工作，目前還不太明瞭。比如，能夠用它寫通用程式碼嗎？能夠用它系統 級程式碼嗎？當然，“函式型”語言有不少我們能夠應用的好東西，比如lambda表示式，比如Closure，C#借鑑了，C++也在借鑑，這些語言因此增 色不少。關於“函式型”語言還有另一個問題，那就是有兩種型別的“函式型”語言，一種是沒有副作用的，因此就沒有共享的易變的狀態的問題；一種是人人都在 使用的，對吧（譯者注：顯然Herb認為“沒有副作用”的理想情況是不太可能的）？因為你不太可能說，“瞧，我是完全併發安全的，因為每次我從XX（譯者 注：聽不清）向量中得到一個拷貝，或者我使用XX（譯者注：聽不清）元素的時候，我都是取得一個拷貝”。確實不錯，這裡是沒有共享的易變的狀態，但是是否 能夠完全併發安全則不一定。
Anders：是的。我的意思是，在類似C#或VB這樣的“命令型”程式語言中加入“函式型”結構，能給我們提供“以函式型風格”寫庫的能力，從而我們就 能夠非常明確地說，如果你能保證傳入的lambda表示式是純粹的函式，我們就能保證正確地把它分散到若干個執行緒或者CPU上，最後把它綜合起來，給你一 個正確的結果，我們能夠保證程式碼執行得更快，同時你還不用作任何編碼上的修改。如果你在寫一個大大的For迴圈，我們永遠都不可能保證做到前面所說的，此 時，“函式型”程式設計能夠提供給你的是一系列表示式，再加上“把程式碼當作引數傳遞”，“型別推論和泛型程式設計可以正確地繫結所有的型別”這些特性，這樣你就能 更方便地編寫“可組合的演算法塊”。
Charles：這樣一來不就削弱了抽象嗎（譯者注：Charles可能想的是程式設計師不需要再關心“可組合性”，語言和執行庫應該保證這件事，而現在聽起來並非如此）？
Herb：呃，我很同意Anders的意見，我想指出的是，當前所有的語言都有意不保證 “沒有副作用”。之所以如此的原因是，除非所有的語言都新增一些機制讓程式設計師可以清除副作用，我們這些做語言的人不敢打這個包票。但是，新增這樣的機制涉 及到眾多參加者，大家一起思考、討論什麼是最好的方法的過程會很漫長。我們所做的是相信程式設計師，因為我們自己不知道。然而，程式設計師在很多情況下也不知道， 因為他寫的函式要呼叫其他的庫。這裡“可組合性”又浮上水面了，程式設計師根本不知道他用的庫有怎樣的副作用。一般說來程式設計師會再增加一層間接性，但是問題依 然存在，沒有人能夠清楚地知道副作用，除非他擁有涉及到的所有的程式碼，這就是難題所在。上面這些討論對“鎖”也適用，因為“鎖”也是個全域性問題，對於“可 操作性”是個障礙。
Brian：（譯者注：在Herb說話的時候已經很著急地想說了幾次）在這點上Haskell做得很好，Haskell是“永遠沒有副作用”的範例。
Erik：是的，但做到這點的過程也是痛苦的，因為並非所有的情況都一目瞭然。一旦你的（庫）程式碼有副作用，而且因此使程式設計師的程式碼必須按照某種順序執行 （因為副作用的關係，該程式必須先幹某事，再幹某事），某種意義上你在用匯編語言編寫東西，因為程式設計師將不再能用“表示式+表示式”的方式來寫程式碼，他必 須決定先對某個表示式求值，再對另一表達式求值，再把值加起來。因此我認為我們在這點上幹得還是不夠漂亮。
Brian：現在，我們在“流庫”上有例子。好訊息是，我們已經有Haskell向你展示如何以“可行性”方面的代價，換來用絕對純粹的方式來做事。當然，除Haskell外我們有各種“雜牌”語言。呵呵！
（眾人均樂）
Charles：這是個供研究的語言嗎？
Brian：是的，我們將它設計為供研究用。
Anders：沒有純粹的好或壞，我認為，雖然進展緩慢，我們仍然快到一個令人滿意的中間點了。我完全同意說，如果我們確實能夠保證函式的純粹性，生活將會非常美好。最終我們必須要做到。
Brian：在研究領域，大概有20多項工作與此有關——契約語言，契約和限制，等等。
Erik：但是，不少的副作用也並非壞事，如果我的函式使用了一個區域性變數，這就是使用了一個狀態，但是，函式本身還是純粹的。如果你想要完全避免副作用，我覺得會非常困難，一些東西可以是區域性不純粹而整體純粹的。
Herb：回過頭，讓我們從整體上看看“可組合性”。讓我吃驚的一件事是，很多時候，人們甚至都沒有意識到這是個問題。他們並沒有意識到自己實際上經常碰 到這個問題。整個軟體工業，整個世界其實已經基於可組合的軟體了。在硬體會議上，我經常對硬體公司提到的是（呵呵，通常此時我都是在轟擊硬體工業，但是軟 件業也有同樣的問題）：硬體的併發問題被仔細地探索過了，而且，當前消除共享易變狀態的最好辦法就是“鎖”；但是，鎖是全域性的，是一種全域性資源，不能被組 合；“被鎖”是經常發生的事情，而擁有一個鎖時，我還能呼叫任何其他的未知的程式碼，這就破壞了“可組合性”。說到這裡，有的聽者往往一臉茫然：這有什麼問 題嗎？我於是指出，好的，你們是否上網下載
Charles：你這麼一說，關於“函式型”程式設計，我馬上想到一個問題是：在現有基礎上再加一層必須考慮的抽象，實際上能不能增加程式設計師的生產率，是否真 的有幫助？作為程式設計師，現在還要考慮“副作用”的問題。反正我現在用C#還是其他語言程式設計的時候，是不會像一個“函式型”程式設計師那樣考慮副作用的。
Herb：往一個語言上增加更多的特性無法使其變簡單，這是個我們面臨的基本難題。
Anders：作為一個語言設計師，對於程式語言，我們所能做的是——減緩新特性不斷累積的速度，從而避免最終的倒塌。我想說的是，你永遠不能收回某個特性。理論上，你可以收回某個特性，實際中，你不能這樣做，因為後果是若干程式碼的崩潰，這行不通。
Brian：是的，在從VB6到VB.NET的過程中，很多人已經感到飽受折磨了。是的，（微軟的）解決方案是說那（VB.NET）是個完全不同的語言。 但是，我認為，“函式型”程式設計的概念已經出現了不短的時間，新畢業的程式設計師至少聽說過這個概念。他們在Python、JavaScript或者其他什麼地 方見過lambda表示式，或者他們學過Scheme，總之這不是個沒聽說過的東西，因此，當他們在C#或其他的更傳統的程式語言，如VB或C++中看到 這些概念的時候，他們並不會感到畏懼，因為他們瞭解這些概念的優點，他們知道這些東西如果用得正確，可以增加程式碼的可組合性。你知道，傳統語言的可組合性 靠的是程式設計師的自覺。在某些方面，Haskell程式設計比“命令型”程式設計要痛苦得多，然而反過來說，它也比“命令型”程式設計要簡單些，因為你不會把事情弄得一 團糟。呵呵呵。
Anders：這裡我想插一句。我認為，在很大程度上，我希望我們在C#或VB上做的工作至少是——在很大程度上對“函式型”程式設計進行“去神祕化”。學院 式的人總是傾向於讓事情聽起來比實際的要複雜，因為這樣一來就顯得他們自己比較聰明。“呃，我並不是針對任何人，但是，這裡有不少符號代數和其他東西呢！ （譯者注：音訊提高了，似乎在學某些人的語氣）”。當我向人們解釋lambda表示式時，大家是另一種感覺：“你的意思是他們就是函式？這有什麼新鮮的？ 我們早就有函數了，lambda表示式只是些語法糖衣外殼吧？”是的，lambda表示式確實只是語法糖衣外殼，但這是種強有力的語法糖衣外殼，它使你能 按照一種新的方式去思考問題，以前總是存在的一些語法噪音——必須宣告函式，進行委託，等等——就會逐漸減少，最終，一個全新層次的表示式列表會產生出 來。這才是關鍵所在！圍繞著“函式型”程式設計還有非常多神祕，我希望我們能夠（在打破神祕上）有所突破……
Herb：關於（Brian）說的教育問題，就是關於人們能夠在學校中學到的東西的說法，我不太同意。我真的希望情況確實如此，但是我認為缺乏證據，或者 說除了 “Pascal熟悉者”之外，我們無法獲得更多。不管是在學校還是在今後的職業生涯中，人們都認為自己接觸了多種語言，因為他們用過C、C#、C++、 VB以及Pascal。但是，這些語言本質上是一樣的，是同一族的語言。人們並沒有接觸過APL——程式設計就象在直譯器外殼（譯者注：可以想象DOS的命令 行）上敲東西；不熟悉Prolog——任何東西都是規則；不知道Lisp——所有的都是連結串列。只有當你深入了2到3種這些東西后，你才知道，並不是所有的 東西都是命令。也許在你今後的職業生涯中用的都是命令型語言，正如我們大多數人一樣，但是，你不會對其他看待世界的觀點一無所知。某人從小到大，如果沒有 離開過成長的城市，如紐約，超過一英里的話，會錯過不少有趣的地方，不管你是否想在其他地方住下來，你應該知道它們，體驗它們。
Brian：呃，我覺得這是個漸變的過程，當然，我確實觀察到年輕一代程式設計師對於“函式型”程式設計有更好的認識了。你知道，10年，15年之前，如果你和人 們談起Scheme時，人們會感到不解地看著你，“什麼？你在說什麼？”。現在，人們聽說過了，他們見過“函式型”程式設計的關鍵字。而且，通過 JavaScript和Python，人們嘗試了“函式型”程式設計，也使得這些東西更加流行。我並不是說已經出現了巨大的變化，我是說逐漸的變化和更多的認 知，人們不再象以前那樣看到這些東西就害怕了。
Erik：也許JavaScript是這個世界上最……（譯者注：Brian一陣激動的插嘴，搞得Erik的話聽不清了）。我不確定當人們使用JavaScript時，他們是否意識到了這是一種把“函式”當作第一要素的語言。
Brian：你可以在執行的時候創造它們（函式）……
Charles：所有的東西都是一種型別，所有的東西都是物件，是吧？這是個有趣的語言。隨著整個網際網路的發展，你認為這種語言也應該有所進化……？
Brian：這裡的“所有的東西都是物件”，不是面向物件的意義。這裡是從“任何東西都是關聯連結串列”的角度來說。現在我聽起來像一個老Lisp程式設計者（譯 者注：Lisp基於連結串列），是吧？一個JavaScript的物件不像一個C#物件那樣——所有的記憶體排列都決定了，什麼東西都靜態地決定了。這意味著所 有的東西都可以新增、拿走，可以違反規則，它確實只意味著一個關聯連結串列。
Anders：屬性包（我得意地笑）……
Brian：是的，屬性包的說法更好！
Erik：是的，值可以是函式、其他物件，或者是其他屬性包。
Brian：JavaScript其實就是源自Lisp的Scheme。我又在說Scheme，因為我也許是這個屋子中唯一老到聽說過這個詞的人，呵呵！ 但是，Scheme有點類似於“上帝的Lisp”（譯者注：不知道是God’s Lisp, Guard’s Lisp還是什麼別的，懂得有限，暫時按God’s Lisp處理，達人請指教），所有的噪音都被消除了，只剩下最基本的、最少的東西。JavaScript就是把這些東西帶到了前臺，披上件不那麼可怕的外 衣的結果。因為JavaScript看起來有點“C”的味道，你可以使用花括號！呵呵！
（一陣亂哄哄）
Charles：但是，JavaScript只是一種解釋性語言，而且，對開發者來說，用它程式設計也不是很有效率。JavaScript不像C#或VB，它沒有一種真正的面嚮物件語言所應該具備的IDE，以及你可以工作於其上的框架。
Anders：呃，JavaScript是一種弱型別語言，或者說動態程式語言。人們經常把“編譯時”與語言的“型別強弱”相提並論。但是，這兩個概念其 實是相互獨立的，是吧？你可以有一種“強型別”，然而在執行期編譯的語言，如果你真想要這樣的東西的話。但是，對我來說，我以前也講過，我非常樂於向那些 喜歡“動態語言”、“指令碼語言”的人指出，正是他們所醉心的那些地方會有問題。經常地，人們都理所當然地認為，如果沒有型別礙事，就不用宣告什麼東西了， 可以隨手就用，諸如此類。這樣乾的時候你確實能夠更快地寫程式，然而，這裡有一個陷阱：因為沒有型別，我們（編譯器）給你提供的幫助就少得多。當你寫 “X.”時，對不起，“.”之後是什麼我們沒法告訴你，我們沒有足夠的智慧顯示給你，因為我們沒有任何辦法知道將發生什麼。有時我們可以猜，但我們有可能 猜錯，有時我們根本就一無所知，對吧？X或者其他引數，我們不知道將發生什麼。我發現，有趣的是，我們在C#中進行的型別推論的工作，在許多方面都使得 C#程式設計看起來更像動態語言，因為不會隨時看到型別，甚至壓根看不到。但是，型別在那裡，靜態地在那裡，這也意味著，我們仍然可以給你提供“語句完成”這 樣的智慧幫助。
Charles：你是在說“var”關鍵字囉？
Anders：“var”關鍵字只是個例子。光看這個關鍵字，似乎這是動態型別，然而，這是靜態型別。當你定義“var Blar”時，我們知道“Blar”是什麼型別；當你寫“Blar.”時，“.”之後我們可以為你顯示出東西。
Herb：我們（C++）中也在做一樣的事情。我有一個“int”型別的vector，我從該vector的頭部取出一個元素，我有什麼必要再用 vector<int> 來宣告一個遍歷器？編譯器知道它是這個型別，編譯器能夠將型別正確加到變數上。這就是“var”型別乾的事，你不必到處都寫出型別資訊。這帶來了很大的好 處，你可以書寫更好的“範型”程式碼，以前那些東西是寫“範型”程式碼的障礙。
Anders：我想說的是，（如果有型別），我們就能在你寫程式碼的時候給你許多的幫助，尤其在“智慧感知”上我說是大實話。當今世界，如果你想把“智慧感 知”去掉，人們絕對會大叫“不！不！”，呵呵，這工具太有用了。但是，這裡還有效能的問題。我是說，當編譯器知道型別時，它能夠為你生成更好的程式碼。就是 說，你會得到更好的執行效率。
Erik：這裡有件趣事。幾個月前我們有次編譯器XX（譯者注：沒聽清），參加者都反映說，“喔，你知道，F#是最好的動態語言！”要我來說的話，F#是 擁有最先進的靜態型別系統的語言。當然，你不用寫任何的型別，因為編譯器幫你推斷了所有的型別。很有趣的是，人們經常混淆“不用寫型別”與“動態型別”。
Brian：這些人可都是寫編譯器的職業程式設計師！這是在課程結束時，做調查時出的趣事：“你最喜歡的動態語言？”“F#！”
Charles：但是（結巴了一陣，可能是震驚了），從開發人員的角度來看，動態型別是設計期的事吧？就我自己而言，如果我不必對任何東西進行強型別處理，我就會假設是動態型別。這是不是錯了？我是說，編譯器是怎麼弄的？
Anders：“動態型別”和“隱式型別”是有區別的。一種情況是，靠編譯器推斷出型別，但編譯器在編譯期就推斷出來了。另一種情況是，編譯器在編譯時一 無所知，它假設這東西可以是任何型別，然後在執行時的適當時機，檢查到底是什麼型別。後一種情況下，當你分發一個虛擬函式呼叫時，也許會使用一個查詢表，或 是別的什麼東西，因為你壓根還不知道那是什麼東西。前一種情況，根據到底是C#或是C++，你可以預先構造好虛表，準確地知道使用這個虛表的哪個記憶體地址 來找到實際的東西，因為我已經計算好了。這就是預先有效地計算好了所有的東西。但是，人們往往錯誤理解（靜態型別）為，“我，我這個人本身，必須在任何時 候親自手動寫出型別”實際上這並不必要，因為型別可以被推斷出來，如果你在一個地方知道了型別，你可以跟蹤程式邏輯，根據這裡發生了什麼，型別是如何變化 的，從而知道在另一個地方型別是什麼。如果你是個足夠聰明的編譯器，你應該可以做到這些，是吧？我們正開始把這種“聰明”加入到程式語言中。
Brian：F#可能是這方面最好的例子。F#甚至欺騙了職業編譯器程式設計師！我認為人們真正喜歡的是快速的反饋。人們喜歡快速看到結果。在他們的意識中， 他們把這種喜好和“動態”相混淆了。下面我具體講講：你輸入了一個函式，然後馬上敲入一行程式碼來測試剛寫的函式，如果能夠正常工作，你就可以放心地忘掉它 們（譯者注：指可以投入下面的其他工作），這是人使自己的“大腦堆疊”保持滿負荷運作的方式，是人的力量。歷史上，“動態語言”在使人以這種方式工作上卓 有成效。你開啟一個Lisp，你實際上得到的是一個Lisp的監聽器，你鍵入程式碼，然後在相同的環境中立即測試程式碼。但是，這實際上是個工具問題，與編譯 器什麼的完全沒有關係。你能夠使動態語言有一個好的IDE和互動的開發環境，你也能使靜態語言，如F#，擁有這樣的IDE和互動的開發環境。這就是Sam 在F#演示上乾的事情。他開啟好長一段程式碼，用滑鼠選擇它們，用“GO”按鈕來執行；然後他開啟另外一段程式碼，再用滑鼠選擇，再按“GO”來執行。所有的 人都以為這是動態解釋執行的。實際上，這是靜態的，完全編譯的。這就是欺騙行家的方法。呵呵（我得意地笑……）。但這確實是人們喜歡的東西。大家都喜歡能 提供“不斷反饋”的好工具，或者是“互動式開發環境”，無論你管這叫什麼。只要你能夠隨時寫程式碼並且測試，你就不必寫一大堆程式碼後再測試。你會這樣想，“ 嘿，我寫了個叫‘RandomDouble’的函式，讓我把它敲進去看看是否能工作”。如果能正常工作，你就可以在進一步的Debugging前把它忘掉 （去做別的工作）。
（譯者注：訪談到現在，眾人已經很放鬆，談話隨意，插嘴較多，因此我加了比較多的句子補充和註解，利於理解。當然，這些是我自己的理解，可能是錯誤的，歡迎指正！）
Charles：但是在C#中做不到這樣，你不能選擇一些函式，然後就執行它們。
Anders：講錯臺詞了（譯者注：Anders開玩笑，因為C#是微軟的招牌，Anders暗指Charles這樣講不合適），實際上，這個東西我們也可以考慮一下（把它加到C#中），是的，這僅僅也只是工具方面的事情。
Herb：這是工具而已，從內部來說，實現它並沒有什麼障礙。這僅僅是工具的問題。你想要這東西嗎？有投資嗎？這東西對程式設計師重要嗎？符合這種語言的側重點嗎？要考慮的是這些問題。
Anders：當然，動態語言已經顯示出這是個重要的工具了。
Brian：之所以動態語言往往和這些互動的東西相聯絡，這完全是個歷史偶然事件。APL可以說是所有這些東西的母親。鍵入“/”、“←”、“(”、然後直接執行！哈哈哈！你知道，這些東西也是可以靜態編譯的。
Charles：讓我們稍微談談。對我而言，語言革命的發展方向似乎是“命令型”和“函式型”的結合，對嗎？
Anders：動態和靜態的結合，說實在的，我認為主流是融合各個領域的特點。經典的、面向物件的、函式型的、動態的，你知道，我們從所有這些吸收可取之處，比起以前，生硬地嵌入（另一種語言的東西）將越來越不可取了。
Charles：你認為，這些東西綜合起來對程式設計師生產率產生的影響，是否為正值？或者，對於那些如Herb所說，沒有能夠在20種語言上進行實驗的程式 員來說，這些將發生在C#和VB.NET上的事情將是奇怪和難以掌握的？這個世界突然要求更多地考慮副作用；語法、程式設計環境和程式院以前所熟知的也大為不 同。當他們被帶到這樣的世界時會如何？我知道你們已經在LINQ上做了很棒的工作，但是，LINQ和C#程式設計師所熟知的環境還是不太一樣。未來將會發生什 麼？
Anders：呃，（生產率）公式其實很簡單，我是說，當你加入新的語言特性，新的功能的時候，你必須要謹慎地考慮對學習曲線的兩端——熟手和生手——的 影響。也許生產率增加了。也許你現在只需要10行程式碼就能搞定以前要100行程式碼的東西。是的，你需要學習如何寫這10行程式碼，但是，嗨，一旦你學會了， 你就可以不斷地寫更多的10行，你的生產率會提高。這是個經典的公式。
Charles：而且這些東西的可組合性也更好……
Herb：最終，所有程式碼應該統一。現在，你可以用滑鼠選中一些程式碼，然後執行。然而，有的（新）東西你能很快掌握，有的東西就需要進一步學習了，這是語 言必然帶來的問題。大家關心的是，我們怎樣才能使某些（新）東西和現存語言的相應東西儘量相似，儘量吻合；使現有語言的概念和（新）概念能夠協同工作，反 之亦然。這樣做了，我們才不會出現如下場面：嗯，這裡是C#3，C#3支援硬嵌入其他語言的程式碼，這些程式碼不和C#3協同，但是它們和C#3使用同一個編 譯器，你可以在C#3中用不同的程式碼段硬嵌入它們。你肯定不希望出現這樣的場面，任何頭腦健全的人都不希望。因此，問題就是你怎樣才能更好的整合，這點才 是我們經常面臨的挑戰。
Brian：這裡就體現出LINQ的美妙了，因為LINQ可以讓你逐漸過渡。一開始你有遍歷器和“For…Each”語句，然後你可以使用新的，與SQL 語句更加類似的“For”語法。這是個漸進的過程，一步步來，慢慢學。要獲得LINQ給你提供的好處，你不必要一下就使用全套的“函式型”程式設計利器，搞一 擊必殺，你可以慢慢來。
Anders：呃，對我來說，價值所在是：我們在非常非常實際的問題——查詢、資料獲取、消除資料領域和通用程式設計領域之間進行對映困難——上應用了“函式型”程式設計的原則。你知道，這些是90%C#使用者每天都在做的事情，很明顯，我們在這裡的工作非常有價值。
Herb：同樣的事情也在“併發性”上發生。如果你用了些新的“硬嵌入”特性，也就是說，你寫了一些併發的程式碼，用了不能與其他程式碼協同工作的特性，你就 是在自求失敗，沒有人會發布這樣的庫，人們會一直等下去，最終你釋出不出來任何東西。因此，沒有人會這樣做。另一方面，你會想，我怎樣才能加一些東西，從 而使我自己能夠從一些一直在做，但一直很痛苦地用手工做的事情中解脫出來。這就是要用一些抽象層來幫自己。我喜歡用“物件”來舉例。現在，每個人都在“對 象”上工作，“物件”已經成了人所共知，非常俗的一個詞了，難道還有誰不知道虛擬函式是什麼東西嗎？但是，20年以前，我們參加那些“深入討論……”之類的 研討會時，人們熱烈討論“什麼是物件”，“什麼是虛擬函式”，針對這些問題，一本又一本質量參差不齊的書不斷地寫出來。實際上，這個所謂的“物件”並非什麼 全新的東西，在這個概念出現之前，人們已經用C寫了15年的面向物件的程式碼了。看看C的靜態庫，“fopen”為你建立了一個控制代碼；然後你呼叫 “ftell”，將這個控制代碼當作顯式傳遞的this指標；然後你呼叫“fclose”，相當於呼叫解構函式。因此，沒有什麼太新的東西。那麼，為什麼人們 要用“類”來代替這一切呢？因為我不想再用手寫虛表了，謝謝你，我有其他更加重要的事情要做。因此，這些抽象是為了處理人們已經在做的事情，而且，在一定 程度上，這是檢驗我們的設計是否良好的標尺——當你用這些抽象來處理已經在做的事情時，是更加痛苦了，還是簡單了？以上的討論當然適用於關於“併發”的抽 象，因為，手動處理執行緒和鎖，與寫C程式碼並無二致。用抽象層來處理這些老的併發問題時，應該使工作更容易；我們也談到了“可組合性”，抽象層也應該使“可 組合性”更簡單。LINQ實際上同時處理了幾個問題，因為可組合性往往與併發緊密相連。比如，“我怎樣才能在同一個地址空間中組合這兩個東西，讓它們同時 執行？”就是個與多方面相關的問題。因為LINQ內生的抽象性，它關注的是要做什麼，而不是如何去做的細節，這就使“執行時”可以接管排程和分配（比如， 在4個、8個CPU上協同一個EXE）的工作。不管硬體如何，“執行時”負責使程式運轉良好，程式設計師完全不用作這方面的決策。現在我們手動做這些事，是停 止“手工寫虛表”的時候了，但是，我們需要提供更好的工具，這樣人們才能真正放棄手工操作，轉而使用抽象層，用10行程式碼幹完以前100行代瑪乾的事。
（譯者注：Herb一說就是長篇大論，到後面說高興了，似乎已經忘記前面關於程式設計師要考慮副作用的事了。）
Erik：這是很重要的一點。我認為，作為語言的設計者，我們在“計算機幫助我們程式設計”上做得還不夠好，因此我們才有很多東西需要手動做。看看在型別推斷 上我們做的事情，對於那些我們已經掌握的關於程式的資訊，我們用計算機的力量來代替手動尋找。如果你想要“併發性”，如果你想要把程式語言設計得可以使用 工具，使用計算機來幫忙獲得更好的“併發性”，我認為我們可以做得更多。我們實際上可以把工具設計得可以互相幫忙，這樣就可以加速前進。我考慮過很多東 西，甚至“執行時”，因為我們有元資料，因此我們現在可以進行垃圾回收，以及進行其他處理。對我來說，這就是趨勢所在：你如何設計程式語言、程式設計環境，從 而其他程式可以“鉤入”，幫助你做事情。從一定意義上來說，對“非託管程式碼”，工具就不太能幫上忙了，因為沒有足夠的內部結構（讓其他工具可以鉤入）。我 認為，這是驅動很多東西的因素，我們今天談論的很多東西都可以從這個角度來審視。
Charles：我想問個問題：多少抽象才算多？你們在抽象的路上能走多遠？我的意思是，在某點上，有可能不用寫程式碼了嗎？
Anders：在抽象問題上，我通常看到的問題是：上移抽象層次，與增加抽象層次是有區別的。我認為，通常說來，上移抽象層次是一種罪惡。上移抽象層次意 味著我們在“美妙的工作流商業概念層”，或其他類似層次上程式設計，對吧？如果想往下靠靠，呃，很不幸，現在你不能呼叫方法，或者寫表示式，或者做其他以前你 能夠做的事情了。因此，你得到一些，失去一些，總體來說，夥計，有時候你幹不了事。我認為重要的是增加抽象層次。你不能拿走底層的東西。是的，我們可以談 工作流、規則，以及其他的東西，比如，在JDE（譯者注：Job Description Environment？工作描述環境？）中宣告東西。但是，你仍然可以到底層去，寫那麼兩行程式碼，從而省掉一天的時間，對吧？你不用經常到底層去，但是 救生口在那裡。對我而言，實際上，是“抽象的範圍”（譯者注：抽象覆蓋了多少個層次，也就是說有多少層抽象）體現了工具的能力，而非抽象的層次（譯者注： 在多高的層次上抽象，因為光追求高層次抽象就是把抽象層次上移），如果你一直在聽我說的話（你應該知道我的意思）。
Herb：當然，說的太對了。這和現在我們寫一個庫的情況是一碼事。我們寫一個函式，用名字呼叫它，因此我們就不必每次都寫上幾百行程式碼了。這個事情（是 否寫庫）可以由程式設計師自行決定，大量編寫（譯者注：這相當於增加抽象層次）。但是，談到語言特性時，有時，你不指望程式設計師能為你寫出另一部分編譯器（譯者 注：Herb指由應用程式開發者來實現某些語言特性。微軟的Phoenix專案將提供這樣的框架，可以由其他的程式設計師來實現部分的編譯器。呵呵），你希望 由語言來幫助你，由工具來幫助你（譯者注：這相當於抽象層次上移）。界限基本上就是：庫和語言。什麼地方真的需要工具的幫助？因為工具不知道（很多具體事 情），而工具影響程式碼產生的方式，然後，你就不能僅僅依靠程式設計師寫出更好的類、更好的框架（因為人們也能自行決定是否編寫框架）或其他什麼來解決問題了。 這些東西將使協同變得很複雜，很難理解。
（譯者注：看起來Herb不是很贊成使用很多工具來幫助程式設計，不知道理解得對不對）
Erik：呃，從定義上來講，我認為不可能有過多的抽象，因為抽象意味著剔除不必要的細節。因此，如果細節不是必要的，你就可以剔除它們。但是，我覺 得……（譯者注：場面混亂，噪音陡漲，眾人都紛紛對這個意外的角度表示感興趣）。有時候你會把必要的細節抽象出去了，因此你得不到這些必要的東西了，此時 抽象就走得太遠了。但是根據我的定義，你不是真的在抽象，因為你剔除了必要的細節。
Brian：我們管這叫“分散”。
Charles：那這就是說……，呃，好像有人要用這個會議室？
Anders：是的，我們要被趕走了。
Charles：我們還有一分鐘。剛才那個論點很棒，我是說，抽象的層次與僅僅上移抽象（Anders插嘴：抽象的範圍和抽象的層次）。但是，有的東西在 CLR就是很難得到，比如，當我寫一個完全託管的程式時，如果不用那個相當複雜的P/Invoke模型，要得到一些相當底層的結構，是相當困難的。
Anders：是的！但是，想象一下這樣的世界：你沒有P/Invoke！我是說，這實際上是個把抽象上移的例子。然而，救生口（P/Invoke模型）在那兒，當然，我們現在竭盡所能，使你根本不必動用這個救生口，但是，如果你必須要去那裡，你可以去，對吧？
Herb：對你自己而言，把救生口焊死是非常不利的。
Anders：是的。因為，在某些情況下，總有些傻傻的原因會使你從箱子上跌落下來，對吧？
Charles：好的。在走之前，讓我們輪流說說語言的發展方向。我沒有別的意思，只是想讓大家談談，就不斷演化的語言來說，我們正在向何處去？快速地輪流說說，告訴我你認為將來是怎樣的，比如，5年後會如何？對你來說，在你的語言中，向開發者提供什麼是重要的？怎麼樣？
（譯者注：Charles明顯有語無倫次的嫌疑。估計累了……）
Anders：我想說，好像從我開始哈（譯者注：Anders坐在桌子一頭，Herb坐在另一頭，Anders率先開說，突然之間覺得不妥，故此加了這一 句）。我們已經看到了語言特性的融合，對吧？對我來說，這就是主流。但是，關於將要解決的主要問題（正出現在地平線上），我想是：我們如何處理多核？更好 的併發程式設計模型是什麼？只是個非常簡單的概括。
Brian：我以前的模型是：讓數學家成為更好的程式設計師。我現在的模型是：讓程式設計師成為更好的數學家。我希望程式語言看起來更像數學。
（譯者注：竊以為Brian現在的模型不符合軟體工業化的要求）
Erik：我想用工具來增進人的智慧。計算機比我們的能力要強大得多，我希望計算機能夠幫助我程式設計，我希望我的程式能夠設計得使這種幫助成為可能。
Herb：大家說了很多了。是的，從其他語言借鑑，尤其是把“函式型”風格植入“命令型”語言，是個趨勢。這個趨勢不難看出，而且在未來幾年都將保持（譯 者注：Herb在這裡開了個什麼玩笑，沒有聽清）。另外就是，能夠討論併發問題，尤其是線上程和鎖之上增加抽象層次。很多人在解決這個問題，事務記憶體、交 互式物件，等等。LINQ在這裡很有希望，LINQ在非併發領域已經做了很多好工作，這些工作能夠直接應用到併發領域。所以，我們正在各方面不斷推進，並 且把所有工作整合到一起。
Charles：很棒！會議室到時間了。訪談很棒，謝謝大家。我希望能夠和大家再次交談，如果你們關於程式語言的演進有什麼想法，歡迎聯絡我。謝謝大家的寶貴時間！
本文是對微軟Channel 9中採訪幾個語言大牛的視訊的翻譯。
視訊在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
大家可以找來看看。
個人感覺這些大牛高屋建瓴，有點有面地談到了多個語言的發展和語言的相互關係，對於我們開拓視野非常有幫助。由於只能靠聽來翻譯，篇幅又長，只能分段（估計有4-5段）慢慢來。而且，水平所限，難免錯誤，請大家指正。
微軟架構師談程式語言發展（一）
譯者：程化
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更多偏向應用層面。而且，語言在不斷創新（譯者注：謝謝ponda的修正）。這一切是如何形成的？你們一起工 作嗎？你們是如何決定語言的創新的（譯者注：謝謝ponda的修正）？你們是一起設計，還是想到什麼後再與他人共享？很抱歉提這樣的怪問題，請試著回答。
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：我插句嘴。我在一定程度上代表了使用者。我是個物理學家，同時，我也經常寫點小程式，進行模擬和模擬，解決一些數學問題。要想成功，“可組合性 ”對我的來說是絕對地重要。我可以不在乎程式語言，但是我很在乎該語言是否有我所需要的元件。我有點誇張了，因為我其實還是在乎程式語言的，呵呵。基本 上，我十分願意使用任何能使我的工作更簡單的程式語言。
這裡，我先戴上頂“老人”帽，談談這個世界的歷史上，非常少的成功軟體之一——數值計算庫（譯者注：謝謝drdirac的修正）。這些東西是N年以前用 FORTRAN寫的。幾十年以來，人們用這些庫解決了許多非常重要的科學問題。任何頭腦正常的人都不會想坐下來從頭寫一個“線性代數包”（譯者注：謝謝 drdirac的修正）或者類似的東西。有許多數學家終其一生在完善這些軟體包。我們需要的是“互操作性”。不簡單的是互操作性，我們需要的是“可組合性 ”。所有人都知道，FORTRAN不支援遞迴，因為所有的變數都是引用傳遞。這就帶來了包之間介面問題。如果你想要整合某種自身內部不支援整合的東西，你 就不能再需要整合的兩邊使用這樣同一個包用於整合，這行不通。呃，我已經忘了最開始我在說啥了，哈哈，我盡講些物理小故事了。讓我回到C++、C#和VB 上。這些語言我都要使用，我更喜歡C#一些，因為我喜歡它的操作符過載。為什麼我喜歡操作符過載？因為我做數學計算，類似於四元數和八元數（譯者注：謝謝 pongba的修正）的奇怪線代運算，用一個小加號就能夠代表那些要進行的一大堆計算。
Erik：夥計，也許你想用的是模板？哈哈。
Brian：（譯者注：看樣子生怕別人認為自己不知道模板）不，我才不想用模板呢。只要我一用模板，我就會開始想：喔，模板的前處理器是圖靈完備的（譯者 注：謝謝drdirac的修正），也許我可以僅用（模板）就實現出一個連結串列處理庫來（譯者注：謝謝pongba的修正）……很快，我就會偏離真正的數學思 考。在應用程式絕對需要晚繫結的場合（比如，那些小的計算模擬器什麼的，晚繫結是成功的關鍵），此時，很自然地，我會選擇VB。至於C++，天哪，大多數 時候，C++用來實現其他的語言，做這類事C++很拿手。在用於科學的環境下，我多次實現過Scheme（譯者注：謝謝drdirac的修正）。
總而言之，我就是泛泛談談“可組合性”。
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以及我們的工業中目前絕大多數的執行時，都是“命令型”引擎，其指令集都是相當傳統的，比如，堆疊增長啥 的，以及擁有易變的狀態，包括易變的全域性狀態等等。在此之上能夠進行“函式型”程式設計，因為“函式型”程式設計從本質上來說，是“命令型”程式設計所具備的能力集的 一個子集。現在我們想做的是最大化這種靈活性，但其實不過也就是讓“函式型”能力子集越來越相關，使其越來越主流化而已。
Herb：我想，我們有必要在“函式型”程式設計領域做一個進一步區分，將其劃分成兩個部分。我非常同意Anders和Erik的意見。我不太同意的是這樣的 措辭：我們之所以繼續使用“命令型”程式語言，是因為這是大家目前所能理解的；通用程式設計師目前的工作並未取得巨大的成功；市場對於“所有的東西都是表達 式，所有的語言都應該是表示式型別的語言”這樣的理念已經非常接受了；“函式型”語言是“序列執行”的好藥方。我們要想使“函式型”語言運轉良好，關鍵的 並不是處理好基本的表示式問題，而是處理好lambda表示式和副作用的問題，關鍵是能夠將表示式作為第一級的程式設計要素來使用——LINQ也是最近才在 做，關鍵是能夠指出lambda表示式和Closure（譯者注：函式型程式語言中的一個概念，可以方便地組合函式，返回函式）的副作用。實際上，最後這 點目前是缺失的（Anders也附和著：對，對）。這些東西在“命令型”語言中也是要處理的東西。我為什麼提這些？因為我覺得說“函式型”語言是方向，目 前的“命令型”語言不夠好，因此是垃圾，必須要拋在腦後，全面採用“函式型”語言這樣的說法不對（譯者注：呵呵，對Anders的說法有點急了，畢竟是泡 在C++上，對C++有感情的人）。我認為，對於“函式型”語言能夠幫助程式設計師完成哪些工作，目前還不太明瞭。比如，能夠用它寫通用程式碼嗎？能夠用它系統 級程式碼嗎？當然，“函式型”語言有不少我們能夠應用的好東西，比如lambda表示式，比如Closure，C#借鑑了，C++也在借鑑，這些語言因此增 色不少。關於“函式型”語言還有另一個問題，那就是有兩種型別的“函式型”語言，一種是沒有副作用的，因此就沒有共享的易變的狀態的問題；一種是人人都在 使用的，對吧（譯者注：顯然Herb認為“沒有副作用”的理想情況是不太可能的）？因為你不太可能說，“瞧，我是完全併發安全的，因為每次我從XX（譯者 注：聽不清）向量中得到一個拷貝，或者我使用XX（譯者注：聽不清）元素的時候，我都是取得一個拷貝”。確實不錯，這裡是沒有共享的易變的狀態，但是是否 能夠完全併發安全則不一定。
Anders：是的。我的意思是，在類似C#或VB這樣的“命令型”程式語言中加入“函式型”結構，能給我們提供“以函式型風格”寫庫的能力，從而我們就 能夠非常明確地說，如果你能保證傳入的lambda表示式是純粹的函式，我們就能保證正確地把它分散到若干個執行緒或者CPU上，最後把它綜合起來，給你一 個正確的結果，我們能夠保證程式碼執行得更快，同時你還不用作任何編碼上的修改。如果你在寫一個大大的For迴圈，我們永遠都不可能保證做到前面所說的，此 時，“函式型”程式設計能夠提供給你的是一系列表示式，再加上“把程式碼當作引數傳遞”，“型別推論和泛型程式設計可以正確地繫結所有的型別”這些特性，這樣你就能 更方便地編寫“可組合的演算法塊”。
Charles：這樣一來不就削弱了抽象嗎（譯者注：Charles可能想的是程式設計師不需要再關心“可組合性”，語言和執行庫應該保證這件事，而現在聽起來並非如此）？
Herb：呃，我很同意Anders的意見，我想指出的是，當前所有的語言都有意不保證 “沒有副作用”。之所以如此的原因是，除非所有的語言都新增一些機制讓程式設計師可以清除副作用，我們這些做語言的人不敢打這個包票。但是，新增這樣的機制涉 及到眾多參加者，大家一起思考、討論什麼是最好的方法的過程會很漫長。我們所做的是相信程式設計師，因為我們自己不知道。然而，程式設計師在很多情況下也不知道， 因為他寫的函式要呼叫其他的庫。這裡“可組合性”又浮上水面了，程式設計師根本不知道他用的庫有怎樣的副作用。一般說來程式設計師會再增加一層間接性，但是問題依 然存在，沒有人能夠清楚地知道副作用，除非他擁有涉及到的所有的程式碼，這就是難題所在。上面這些討論對“鎖”也適用，因為“鎖”也是個全域性問題，對於“可 操作性”是個障礙。
Brian：（譯者注：在Herb說話的時候已經很著急地想說了幾次）在這點上Haskell做得很好，Haskell是“永遠沒有副作用”的範例。
Erik：是的，但做到這點的過程也是痛苦的，因為並非所有的情況都一目瞭然。一旦你的（庫）程式碼有副作用，而且因此使程式設計師的程式碼必須按照某種順序執行 （因為副作用的關係，該程式必須先幹某事，再幹某事），某種意義上你在用匯編語言編寫東西，因為程式設計師將不再能用“表示式+表示式”的方式來寫程式碼，他必 須決定先對某個表示式求值，再對另一表達式求值，再把值加起來。因此我認為我們在這點上幹得還是不夠漂亮。
Brian：現在，我們在“流庫”上有例子。好訊息是，我們已經有Haskell向你展示如何以“可行性”方面的代價，換來用絕對純粹的方式來做事。當然，除Haskell外我們有各種“雜牌”語言。呵呵！
（眾人均樂）
Charles：這是個供研究的語言嗎？
Brian：是的，我們將它設計為供研究用。
Anders：沒有純粹的好或壞，我認為，雖然進展緩慢，我們仍然快到一個令人滿意的中間點了。我完全同意說，如果我們確實能夠保證函式的純粹性，生活將會非常美好。最終我們必須要做到。
Brian：在研究領域，大概有20多項工作與此有關——契約語言，契約和限制，等等。
Erik：但是，不少的副作用也並非壞事，如果我的函式使用了一個區域性變數，這就是使用了一個狀態，但是，函式本身還是純粹的。如果你想要完全避免副作用，我覺得會非常困難，一些東西可以是區域性不純粹而整體純粹的。
Herb：回過頭，讓我們從整體上看看“可組合性”。讓我吃驚的一件事是，很多時候，人們甚至都沒有意識到這是個問題。他們並沒有意識到自己實際上經常碰 到這個問題。整個軟體工業，整個世界其實已經基於可組合的軟體了。在硬體會議上，我經常對硬體公司提到的是（呵呵，通常此時我都是在轟擊硬體工業，但是軟 件業也有同樣的問題）：硬體的併發問題被仔細地探索過了，而且，當前消除共享易變狀態的最好辦法就是“鎖”；但是，鎖是全域性的，是一種全域性資源，不能被組 合；“被鎖”是經常發生的事情，而擁有一個鎖時，我還能呼叫任何其他的未知的程式碼，這就破壞了“可組合性”。說到這裡，有的聽者往往一臉茫然：這有什麼問 題嗎？我於是指出，好的，你們是否上網下載
Charles：你這麼一說，關於“函式型”程式設計，我馬上想到一個問題是：在現有基礎上再加一層必須考慮的抽象，實際上能不能增加程式設計師的生產率，是否真 的有幫助？作為程式設計師，現在還要考慮“副作用”的問題。反正我現在用C#還是其他語言程式設計的時候，是不會像一個“函式型”程式設計師那樣考慮副作用的。
Herb：往一個語言上增加更多的特性無法使其變簡單，這是個我們面臨的基本難題。
Anders：作為一個語言設計師，對於程式語言，我們所能做的是——減緩新特性不斷累積的速度，從而避免最終的倒塌。我想說的是，你永遠不能收回某個特性。理論上，你可以收回某個特性，實際中，你不能這樣做，因為後果是若干程式碼的崩潰，這行不通。
Brian：是的，在從VB6到VB.NET的過程中，很多人已經感到飽受折磨了。是的，（微軟的）解決方案是說那（VB.NET）是個完全不同的語言。 但是，我認為，“函式型”程式設計的概念已經出現了不短的時間，新畢業的程式設計師至少聽說過這個概念。他們在Python、JavaScript或者其他什麼地 方見過lambda表示式，或者他們學過Scheme，總之這不是個沒聽說過的東西，因此，當他們在C#或其他的更傳統的程式語言，如VB或C++中看到 這些概念的時候，他們並不會感到畏懼，因為他們瞭解這些概念的優點，他們知道這些東西如果用得正確，可以增加程式碼的可組合性。你知道，傳統語言的可組合性 靠的是程式設計師的自覺。在某些方面，Haskell程式設計比“命令型”程式設計要痛苦得多，然而反過來說，它也比“命令型”程式設計要簡單些，因為你不會把事情弄得一 團糟。呵呵呵。
Anders：這裡我想插一句。我認為，在很大程度上，我希望我們在C#或VB上做的工作至少是——在很大程度上對“函式型”程式設計進行“去神祕化”。學院 式的人總是傾向於讓事情聽起來比實際的要複雜，因為這樣一來就顯得他們自己比較聰明。“呃，我並不是針對任何人，但是，這裡有不少符號代數和其他東西呢！ （譯者注：音訊提高了，似乎在學某些人的語氣）”。當我向人們解釋lambda表示式時，大家是另一種感覺：“你的意思是他們就是函式？這有什麼新鮮的？ 我們早就有函數了，lambda表示式只是些語法糖衣外殼吧？”是的，lambda表示式確實只是語法糖衣外殼，但這是種強有力的語法糖衣外殼，它使你能 按照一種新的方式去思考問題，以前總是存在的一些語法噪音——必須宣告函式，進行委託，等等——就會逐漸減少，最終，一個全新層次的表示式列表會產生出 來。這才是關鍵所在！圍繞著“函式型”程式設計還有非常多神祕，我希望我們能夠（在打破神祕上）有所突破……
Herb：關於（Brian）說的教育問題，就是關於人們能夠在學校中學到的東西的說法，我不太同意。我真的希望情況確實如此，但是我認為缺乏證據，或者 說除了 “Pascal熟悉者”之外，我們無法獲得更多。不管是在學校還是在今後的職業生涯中，人們都認為自己接觸了多種語言，因為他們用過C、C#、C++、 VB以及Pascal。但是，這些語言本質上是一樣的，是同一族的語言。人們並沒有接觸過APL——程式設計就象在直譯器外殼（譯者注：可以想象DOS的命令 行）上敲東西；不熟悉Prolog——任何東西都是規則；不知道Lisp——所有的都是連結串列。只有當你深入了2到3種這些東西后，你才知道，並不是所有的 東西都是命令。也許在你今後的職業生涯中用的都是命令型語言，正如我們大多數人一樣，但是，你不會對其他看待世界的觀點一無所知。某人從小到大，如果沒有 離開過成長的城市，如紐約，超過一英里的話，會錯過不少有趣的地方，不管你是否想在其他地方住下來，你應該知道它們，體驗它們。
Brian：呃，我覺得這是個漸變的過程，當然，我確實觀察到年輕一代程式設計師對於“函式型”程式設計有更好的認識了。你知道，10年，15年之前，如果你和人 們談起Scheme時，人們會感到不解地看著你，“什麼？你在說什麼？”。現在，人們聽說過了，他們見過“函式型”程式設計的關鍵字。而且，通過 JavaScript和Python，人們嘗試了“函式型”程式設計，也使得這些東西更加流行。我並不是說已經出現了巨大的變化，我是說逐漸的變化和更多的認 知，人們不再象以前那樣看到這些東西就害怕了。
Erik：也許JavaScript是這個世界上最……（譯者注：Brian一陣激動的插嘴，搞得Erik的話聽不清了）。我不確定當人們使用JavaScript時，他們是否意識到了這是一種把“函式”當作第一要素的語言。
Brian：你可以在執行的時候創造它們（函式）……
Charles：所有的東西都是一種型別，所有的東西都是物件，是吧？這是個有趣的語言。隨著整個網際網路的發展，你認為這種語言也應該有所進化……？
Brian：這裡的“所有的東西都是物件”，不是面向物件的意義。這裡是從“任何東西都是關聯連結串列”的角度來說。現在我聽起來像一個老Lisp程式設計者（譯 者注：Lisp基於連結串列），是吧？一個JavaScript的物件不像一個C#物件那樣——所有的記憶體排列都決定了，什麼東西都靜態地決定了。這意味著所 有的東西都可以新增、拿走，可以違反規則，它確實只意味著一個關聯連結串列。
Anders：屬性包（我得意地笑）……
Brian：是的，屬性包的說法更好！
Erik：是的，值可以是函式、其他物件，或者是其他屬性包。
Brian：JavaScript其實就是源自Lisp的Scheme。我又在說Scheme，因為我也許是這個屋子中唯一老到聽說過這個詞的人，呵呵！ 但是，Scheme有點類似於“上帝的Lisp”（譯者注：不知道是God’s Lisp, Guard’s Lisp還是什麼別的，懂得有限，暫時按God’s Lisp處理，達人請指教），所有的噪音都被消除了，只剩下最基本的、最少的東西。JavaScript就是把這些東西帶到了前臺，披上件不那麼可怕的外 衣的結果。因為JavaScript看起來有點“C”的味道，你可以使用花括號！呵呵！
（一陣亂哄哄）
Charles：但是，JavaScript只是一種解釋性語言，而且，對開發者來說，用它程式設計也不是很有效率。JavaScript不像C#或VB，它沒有一種真正的面嚮物件語言所應該具備的IDE，以及你可以工作於其上的框架。
Anders：呃，JavaScript是一種弱型別語言，或者說動態程式語言。人們經常把“編譯時”與語言的“型別強弱”相提並論。但是，這兩個概念其 實是相互獨立的，是吧？你可以有一種“強型別”，然而在執行期編譯的語言，如果你真想要這樣的東西的話。但是，對我來說，我以前也講過，我非常樂於向那些 喜歡“動態語言”、“指令碼語言”的人指出，正是他們所醉心的那些地方會有問題。經常地，人們都理所當然地認為，如果沒有型別礙事，就不用宣告什麼東西了， 可以隨手就用，諸如此類。這樣乾的時候你確實能夠更快地寫程式，然而，這裡有一個陷阱：因為沒有型別，我們（編譯器）給你提供的幫助就少得多。當你寫 “X.”時，對不起，“.”之後是什麼我們沒法告訴你，我們沒有足夠的智慧顯示給你，因為我們沒有任何辦法知道將發生什麼。有時我們可以猜，但我們有可能 猜錯，有時我們根本就一無所知，對吧？X或者其他引數，我們不知道將發生什麼。我發現，有趣的是，我們在C#中進行的型別推論的工作，在許多方面都使得 C#程式設計看起來更像動態語言，因為不會隨時看到型別，甚至壓根看不到。但是，型別在那裡，靜態地在那裡，這也意味著，我們仍然可以給你提供“語句完成”這 樣的智慧幫助。
Charles：你是在說“var”關鍵字囉？
Anders：“var”關鍵字只是個例子。光看這個關鍵字，似乎這是動態型別，然而，這是靜態型別。當你定義“var Blar”時，我們知道“Blar”是什麼型別；當你寫“Blar.”時，“.”之後我們可以為你顯示出東西。
Herb：我們（C++）中也在做一樣的事情。我有一個“int”型別的vector，我從該vector的頭部取出一個元素，我有什麼必要再用 vector<int> 來宣告一個遍歷器？編譯器知道它是這個型別，編譯器能夠將型別正確加到變數上。這就是“var”型別乾的事，你不必到處都寫出型別資訊。這帶來了很大的好 處，你可以書寫更好的“範型”程式碼，以前那些東西是寫“範型”程式碼的障礙。
Anders：我想說的是，（如果有型別），我們就能在你寫程式碼的時候給你許多的幫助，尤其在“智慧感知”上我說是大實話。當今世界，如果你想把“智慧感 知”去掉，人們絕對會大叫“不！不！”，呵呵，這工具太有用了。但是，這裡還有效能的問題。我是說，當編譯器知道型別時，它能夠為你生成更好的程式碼。就是 說，你會得到更好的執行效率。
Erik：這裡有件趣事。幾個月前我們有次編譯器XX（譯者注：沒聽清），參加者都反映說，“喔，你知道，F#是最好的動態語言！”要我來說的話，F#是 擁有最先進的靜態型別系統的語言。當然，你不用寫任何的型別，因為編譯器幫你推斷了所有的型別。很有趣的是，人們經常混淆“不用寫型別”與“動態型別”。
Brian：這些人可都是寫編譯器的職業程式設計師！這是在課程結束時，做調查時出的趣事：“你最喜歡的動態語言？”“F#！”
Charles：但是（結巴了一陣，可能是震驚了），從開發人員的角度來看，動態型別是設計期的事吧？就我自己而言，如果我不必對任何東西進行強型別處理，我就會假設是動態型別。這是不是錯了？我是說，編譯器是怎麼弄的？
Anders：“動態型別”和“隱式型別”是有區別的。一種情況是，靠編譯器推斷出型別，但編譯器在編譯期就推斷出來了。另一種情況是，編譯器在編譯時一 無所知，它假設這東西可以是任何型別，然後在執行時的適當時機，檢查到底是什麼型別。後一種情況下，當你分發一個虛擬函式呼叫時，也許會使用一個查詢表，或 是別的什麼東西，因為你壓根還不知道那是什麼東西。前一種情況，根據到底是C#或是C++，你可以預先構造好虛表，準確地知道使用這個虛表的哪個記憶體地址 來找到實際的東西，因為我已經計算好了。這就是預先有效地計算好了所有的東西。但是，人們往往錯誤理解（靜態型別）為，“我，我這個人本身，必須在任何時 候親自手動寫出型別”實際上這並不必要，因為型別可以被推斷出來，如果你在一個地方知道了型別，你可以跟蹤程式邏輯，根據這裡發生了什麼，型別是如何變化 的，從而知道在另一個地方型別是什麼。如果你是個足夠聰明的編譯器，你應該可以做到這些，是吧？我們正開始把這種“聰明”加入到程式語言中。
Brian：F#可能是這方面最好的例子。F#甚至欺騙了職業編譯器程式設計師！我認為人們真正喜歡的是快速的反饋。人們喜歡快速看到結果。在他們的意識中， 他們把這種喜好和“動態”相混淆了。下面我具體講講：你輸入了一個函式，然後馬上敲入一行程式碼來測試剛寫的函式，如果能夠正常工作，你就可以放心地忘掉它 們（譯者注：指可以投入下面的其他工作），這是人使自己的“大腦堆疊”保持滿負荷運作的方式，是人的力量。歷史上，“動態語言”在使人以這種方式工作上卓 有成效。你開啟一個Lisp，你實際上得到的是一個Lisp的監聽器，你鍵入程式碼，然後在相同的環境中立即測試程式碼。但是，這實際上是個工具問題，與編譯 器什麼的完全沒有關係。你能夠使動態語言有一個好的IDE和互動的開發環境，你也能使靜態語言，如F#，擁有這樣的IDE和互動的開發環境。這就是Sam 在F#演示上乾的事情。他開啟好長一段程式碼，用滑鼠選擇它們，用“GO”按鈕來執行；然後他開啟另外一段程式碼，再用滑鼠選擇，再按“GO”來執行。所有的 人都以為這是動態解釋執行的。實際上，這是靜態的，完全編譯的。這就是欺騙行家的方法。呵呵（我得意地笑……）。但這確實是人們喜歡的東西。大家都喜歡能 提供“不斷反饋”的好工具，或者是“互動式開發環境”，無論你管這叫什麼。只要你能夠隨時寫程式碼並且測試，你就不必寫一大堆程式碼後再測試。你會這樣想，“ 嘿，我寫了個叫‘RandomDouble’的函式，讓我把它敲進去看看是否能工作”。如果能正常工作，你就可以在進一步的Debugging前把它忘掉 （去做別的工作）。
（譯者注：訪談到現在，眾人已經很放鬆，談話隨意，插嘴較多，因此我加了比較多的句子補充和註解，利於理解。當然，這些是我自己的理解，可能是錯誤的，歡迎指正！）
Charles：但是在C#中做不到這樣，你不能選擇一些函式，然後就執行它們。
Anders：講錯臺詞了（譯者注：Anders開玩笑，因為C#是微軟的招牌，Anders暗指Charles這樣講不合適），實際上，這個東西我們也可以考慮一下（把它加到C#中），是的，這僅僅也只是工具方面的事情。
Herb：這是工具而已，從內部來說，實現它並沒有什麼障礙。這僅僅是工具的問題。你想要這東西嗎？有投資嗎？這東西對程式設計師重要嗎？符合這種語言的側重點嗎？要考慮的是這些問題。
Anders：當然，動態語言已經顯示出這是個重要的工具了。
Brian：之所以動態語言往往和這些互動的東西相聯絡，這完全是個歷史偶然事件。APL可以說是所有這些東西的母親。鍵入“/”、“←”、“(”、然後直接執行！哈哈哈！你知道，這些東西也是可以靜態編譯的。
Charles：讓我們稍微談談。對我而言，語言革命的發展方向似乎是“命令型”和“函式型”的結合，對嗎？
Anders：動態和靜態的結合，說實在的，我認為主流是融合各個領域的特點。經典的、面向物件的、函式型的、動態的，你知道，我們從所有這些吸收可取之處，比起以前，生硬地嵌入（另一種語言的東西）將越來越不可取了。
Charles：你認為，這些東西綜合起來對程式設計師生產率產生的影響，是否為正值？或者，對於那些如Herb所說，沒有能夠在20種語言上進行實驗的程式 員來說，這些將發生在C#和VB.NET上的事情將是奇怪和難以掌握的？這個世界突然要求更多地考慮副作用；語法、程式設計環境和程式院以前所熟知的也大為不 同。當他們被帶到這樣的世界時會如何？我知道你們已經在LINQ上做了很棒的工作，但是，LINQ和C#程式設計師所熟知的環境還是不太一樣。未來將會發生什 麼？
Anders：呃，（生產率）公式其實很簡單，我是說，當你加入新的語言特性，新的功能的時候，你必須要謹慎地考慮對學習曲線的兩端——熟手和生手——的 影響。也許生產率增加了。也許你現在只需要10行程式碼就能搞定以前要100行程式碼的東西。是的，你需要學習如何寫這10行程式碼，但是，嗨，一旦你學會了， 你就可以不斷地寫更多的10行，你的生產率會提高。這是個經典的公式。
Charles：而且這些東西的可組合性也更好……
Herb：最終，所有程式碼應該統一。現在，你可以用滑鼠選中一些程式碼，然後執行。然而，有的（新）東西你能很快掌握，有的東西就需要進一步學習了，這是語 言必然帶來的問題。大家關心的是，我們怎樣才能使某些（新）東西和現存語言的相應東西儘量相似，儘量吻合；使現有語言的概念和（新）概念能夠協同工作，反 之亦然。這樣做了，我們才不會出現如下場面：嗯，這裡是C#3，C#3支援硬嵌入其他語言的程式碼，這些程式碼不和C#3協同，但是它們和C#3使用同一個編 譯器，你可以在C#3中用不同的程式碼段硬嵌入它們。你肯定不希望出現這樣的場面，任何頭腦健全的人都不希望。因此，問題就是你怎樣才能更好的整合，這點才 是我們經常面臨的挑戰。
Brian：這裡就體現出LINQ的美妙了，因為LINQ可以讓你逐漸過渡。一開始你有遍歷器和“For…Each”語句，然後你可以使用新的，與SQL 語句更加類似的“For”語法。這是個漸進的過程，一步步來，慢慢學。要獲得LINQ給你提供的好處，你不必要一下就使用全套的“函式型”程式設計利器，搞一 擊必殺，你可以慢慢來。
Anders：呃，對我來說，價值所在是：我們在非常非常實際的問題——查詢、資料獲取、消除資料領域和通用程式設計領域之間進行對映困難——上應用了“函式型”程式設計的原則。你知道，這些是90%C#使用者每天都在做的事情，很明顯，我們在這裡的工作非常有價值。
Herb：同樣的事情也在“併發性”上發生。如果你用了些新的“硬嵌入”特性，也就是說，你寫了一些併發的程式碼，用了不能與其他程式碼協同工作的特性，你就 是在自求失敗，沒有人會發布這樣的庫，人們會一直等下去，最終你釋出不出來任何東西。因此，沒有人會這樣做。另一方面，你會想，我怎樣才能加一些東西，從 而使我自己能夠從一些一直在做，但一直很痛苦地用手工做的事情中解脫出來。這就是要用一些抽象層來幫自己。我喜歡用“物件”來舉例。現在，每個人都在“對 象”上工作，“物件”已經成了人所共知，非常俗的一個詞了，難道還有誰不知道虛擬函式是什麼東西嗎？但是，20年以前，我們參加那些“深入討論……”之類的 研討會時，人們熱烈討論“什麼是物件”，“什麼是虛擬函式”，針對這些問題，一本又一本質量參差不齊的書不斷地寫出來。實際上，這個所謂的“物件”並非什麼 全新的東西，在這個概念出現之前，人們已經用C寫了15年的面向物件的程式碼了。看看C的靜態庫，“fopen”為你建立了一個控制代碼；然後你呼叫 “ftell”，將這個控制代碼當作顯式傳遞的this指標；然後你呼叫“fclose”，相當於呼叫解構函式。因此，沒有什麼太新的東西。那麼，為什麼人們 要用“類”來代替這一切呢？因為我不想再用手寫虛表了，謝謝你，我有其他更加重要的事情要做。因此，這些抽象是為了處理人們已經在做的事情，而且，在一定 程度上，這是檢驗我們的設計是否良好的標尺——當你用這些抽象來處理已經在做的事情時，是更加痛苦了，還是簡單了？以上的討論當然適用於關於“併發”的抽 象，因為，手動處理執行緒和鎖，與寫C程式碼並無二致。用抽象層來處理這些老的併發問題時，應該使工作更容易；我們也談到了“可組合性”，抽象層也應該使“可 組合性”更簡單。LINQ實際上同時處理了幾個問題，因為可組合性往往與併發緊密相連。比如，“我怎樣才能在同一個地址空間中組合這兩個東西，讓它們同時 執行？”就是個與多方面相關的問題。因為LINQ內生的抽象性，它關注的是要做什麼，而不是如何去做的細節，這就使“執行時”可以接管排程和分配（比如， 在4個、8個CPU上協同一個EXE）的工作。不管硬體如何，“執行時”負責使程式運轉良好，程式設計師完全不用作這方面的決策。現在我們手動做這些事，是停 止“手工寫虛表”的時候了，但是，我們需要提供更好的工具，這樣人們才能真正放棄手工操作，轉而使用抽象層，用10行程式碼幹完以前100行代瑪乾的事。
（譯者注：Herb一說就是長篇大論，到後面說高興了，似乎已經忘記前面關於程式設計師要考慮副作用的事了。）
Erik：這是很重要的一點。我認為，作為語言的設計者，我們在“計算機幫助我們程式設計”上做得還不夠好，因此我們才有很多東西需要手動做。看看在型別推斷 上我們做的事情，對於那些我們已經掌握的關於程式的資訊，我們用計算機的力量來代替手動尋找。如果你想要“併發性”，如果你想要把程式語言設計得可以使用 工具，使用計算機來幫忙獲得更好的“併發性”，我認為我們可以做得更多。我們實際上可以把工具設計得可以互相幫忙，這樣就可以加速前進。我考慮過很多東 西，甚至“執行時”，因為我們有元資料，因此我們現在可以進行垃圾回收，以及進行其他處理。對我來說，這就是趨勢所在：你如何設計程式語言、程式設計環境，從 而其他程式可以“鉤入”，幫助你做事情。從一定意義上來說，對“非託管程式碼”，工具就不太能幫上忙了，因為沒有足夠的內部結構（讓其他工具可以鉤入）。我 認為，這是驅動很多東西的因素，我們今天談論的很多東西都可以從這個角度來審視。
Charles：我想問個問題：多少抽象才算多？你們在抽象的路上能走多遠？我的意思是，在某點上，有可能不用寫程式碼了嗎？
Anders：在抽象問題上，我通常看到的問題是：上移抽象層次，與增加抽象層次是有區別的。我認為，通常說來，上移抽象層次是一種罪惡。上移抽象層次意 味著我們在“美妙的工作流商業概念層”，或其他類似層次上程式設計，對吧？如果想往下靠靠，呃，很不幸，現在你不能呼叫方法，或者寫表示式，或者做其他以前你 能夠做的事情了。因此，你得到一些，失去一些，總體來說，夥計，有時候你幹不了事。我認為重要的是增加抽象層次。你不能拿走底層的東西。是的，我們可以談 工作流、規則，以及其他的東西，比如，在JDE（譯者注：Job Description Environment？工作描述環境？）中宣告東西。但是，你仍然可以到底層去，寫那麼兩行程式碼，從而省掉一天的時間，對吧？你不用經常到底層去，但是 救生口在那裡。對我而言，實際上，是“抽象的範圍”（譯者注：抽象覆蓋了多少個層次，也就是說有多少層抽象）體現了工具的能力，而非抽象的層次（譯者注： 在多高的層次上抽象，因為光追求高層次抽象就是把抽象層次上移），如果你一直在聽我說的話（你應該知道我的意思）。
Herb：當然，說的太對了。這和現在我們寫一個庫的情況是一碼事。我們寫一個函式，用名字呼叫它，因此我們就不必每次都寫上幾百行程式碼了。這個事情（是 否寫庫）可以由程式設計師自行決定，大量編寫（譯者注：這相當於增加抽象層次）。但是，談到語言特性時，有時，你不指望程式設計師能為你寫出另一部分編譯器（譯者 注：Herb指由應用程式開發者來實現某些語言特性。微軟的Phoenix專案將提供這樣的框架，可以由其他的程式設計師來實現部分的編譯器。呵呵），你希望 由語言來幫助你，由工具來幫助你（譯者注：這相當於抽象層次上移）。界限基本上就是：庫和語言。什麼地方真的需要工具的幫助？因為工具不知道（很多具體事 情），而工具影響程式碼產生的方式，然後，你就不能僅僅依靠程式設計師寫出更好的類、更好的框架（因為人們也能自行決定是否編寫框架）或其他什麼來解決問題了。 這些東西將使協同變得很複雜，很難理解。
（譯者注：看起來Herb不是很贊成使用很多工具來幫助程式設計，不知道理解得對不對）
Erik：呃，從定義上來講，我認為不可能有過多的抽象，因為抽象意味著剔除不必要的細節。因此，如果細節不是必要的，你就可以剔除它們。但是，我覺 得……（譯者注：場面混亂，噪音陡漲，眾人都紛紛對這個意外的角度表示感興趣）。有時候你會把必要的細節抽象出去了，因此你得不到這些必要的東西了，此時 抽象就走得太遠了。但是根據我的定義，你不是真的在抽象，因為你剔除了必要的細節。
Brian：我們管這叫“分散”。
Charles：那這就是說……，呃，好像有人要用這個會議室？
Anders：是的，我們要被趕走了。
Charles：我們還有一分鐘。剛才那個論點很棒，我是說，抽象的層次與僅僅上移抽象（Anders插嘴：抽象的範圍和抽象的層次）。但是，有的東西在 CLR就是很難得到，比如，當我寫一個完全託管的程式時，如果不用那個相當複雜的P/Invoke模型，要得到一些相當底層的結構，是相當困難的。
Anders：是的！但是，想象一下這樣的世界：你沒有P/Invoke！我是說，這實際上是個把抽象上移的例子。然而，救生口（P/Invoke模型）在那兒，當然，我們現在竭盡所能，使你根本不必動用這個救生口，但是，如果你必須要去那裡，你可以去，對吧？
Herb：對你自己而言，把救生口焊死是非常不利的。
Anders：是的。因為，在某些情況下，總有些傻傻的原因會使你從箱子上跌落下來，對吧？
Charles：好的。在走之前，讓我們輪流說說語言的發展方向。我沒有別的意思，只是想讓大家談談，就不斷演化的語言來說，我們正在向何處去？快速地輪流說說，告訴我你認為將來是怎樣的，比如，5年後會如何？對你來說，在你的語言中，向開發者提供什麼是重要的？怎麼樣？
（譯者注：Charles明顯有語無倫次的嫌疑。估計累了……）
Anders：我想說，好像從我開始哈（譯者注：Anders坐在桌子一頭，Herb坐在另一頭，Anders率先開說，突然之間覺得不妥，故此加了這一 句）。我們已經看到了語言特性的融合，對吧？對我來說，這就是主流。但是，關於將要解決的主要問題（正出現在地平線上），我想是：我們如何處理多核？更好 的併發程式設計模型是什麼？只是個非常簡單的概括。
Brian：我以前的模型是：讓數學家成為更好的程式設計師。我現在的模型是：讓程式設計師成為更好的數學家。我希望程式語言看起來更像數學。
（譯者注：竊以為Brian現在的模型不符合軟體工業化的要求）
Erik：我想用工具來增進人的智慧。計算機比我們的能力要強大得多，我希望計算機能夠幫助我程式設計，我希望我的程式能夠設計得使這種幫助成為可能。
Herb：大家說了很多了。是的，從其他語言借鑑，尤其是把“函式型”風格植入“命令型”語言，是個趨勢。這個趨勢不難看出，而且在未來幾年都將保持（譯 者注：Herb在這裡開了個什麼玩笑，沒有聽清）。另外就是，能夠討論併發問題，尤其是線上程和鎖之上增加抽象層次。很多人在解決這個問題，事務記憶體、交 互式物件，等等。LINQ在這裡很有希望，LINQ在非併發領域已經做了很多好工作，這些工作能夠直接應用到併發領域。所以，我們正在各方面不斷推進，並 且把所有工作整合到一起。
Charles：很棒！會議室到時間了。訪談很棒，謝謝大家。我希望能夠和大家再次交談，如果你們關於程式語言的演進有什麼想法，歡迎聯絡我。謝謝大家的寶貴時間！