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：很棒！會議室到時間了。訪談很棒，謝謝大家。我希望能夠和大家再次交談，如果你們關于編程語言的演進有什么想法，歡迎聯系我。謝謝大家的寶貴時間！