Charles：但是在C#中做不到這樣，你不能選擇一些函數(shù)，然后就執(zhí)行它們。
    Anders：講錯臺詞了(譯者注：Anders開玩笑，因為C#是微軟的招牌，Anders暗指Charles這樣講不合適)，實際上，這個東西我們也可以考慮一下(把它加到C#中)，是的，這僅僅也只是工具方面的事情。
    Herb：這是工具而已，從內(nèi)部來說，實現(xiàn)它并沒有什么障礙。這僅僅是工具的問題。你想要這東西嗎?有投資嗎?這東西對程序員重要嗎?符合這種語言的側(cè)重點嗎?要考慮的是這些問題。
    Anders：當(dāng)然，動態(tài)語言已經(jīng)顯示出這是個重要的工具了。
    Brian：之所以動態(tài)語言往往和這些交互的東西相聯(lián)系，這完全是個歷史偶然事件。APL可以說是所有這些東西的母親。鍵入“/”、“←”、“(”、然后直接執(zhí)行!哈哈哈!你知道，這些東西也是可以靜態(tài)編譯的。
    Charles：讓我們稍微談?wù)?。對我而言，語言革命的發(fā)展方向似乎是“命令型”和“函數(shù)型”的結(jié)合，對嗎?
    Anders：動態(tài)和靜態(tài)的結(jié)合，說實在的，我認(rèn)為主流是融合各個領(lǐng)域的特點。經(jīng)典的、面向?qū)ο蟮摹⒑瘮?shù)型的、動態(tài)的，你知道，我們從所有這些吸收可取之處，比起以前，生硬地嵌入(另一種語言的東西)將越來越不可取了。
    Charles：你認(rèn)為，這些東西綜合起來對程序員生產(chǎn)率產(chǎn)生的影響，是否為正值?或者，對于那些如Herb所說，沒有能夠在20種語言上進(jìn)行實驗的程序員來說，這些將發(fā)生在C#和VB.NET上的事情將是奇怪和難以掌握的?這個世界突然要求更多地考慮副作用;語法、編程環(huán)境和程序院以前所熟知的也大為不同。當(dāng)他們被帶到這樣的世界時會如何?我知道你們已經(jīng)在LINQ上做了很棒的工作，但是，LINQ和C#程序員所熟知的環(huán)境還是不太一樣。未來將會發(fā)生什么?
    Anders：呃，(生產(chǎn)率)公式其實很簡單，我是說，當(dāng)你加入新的語言特性，新的功能的時候，你必須要謹(jǐn)慎地考慮對學(xué)習(xí)曲線的兩端——熟手和生手——的影響。也許生產(chǎn)率增加了。也許你現(xiàn)在只需要10行代碼就能搞定以前要100行代碼的東西。是的，你需要學(xué)習(xí)如何寫這10行代碼，但是，嗨，一旦你學(xué)會了，你就可以不斷地寫更多的10行，你的生產(chǎn)率會提高。這是個經(jīng)典的公式。
    Charles：而且這些東西的可組合性也更好……
    Herb：最終，所有代碼應(yīng)該統(tǒng)一?，F(xiàn)在，你可以用鼠標(biāo)選中一些代碼，然后執(zhí)行。然而，有的(新)東西你能很快掌握，有的東西就需要進(jìn)一步學(xué)習(xí)了，這是語言必然帶來的問題。大家關(guān)心的是，我們怎樣才能使某些(新)東西和現(xiàn)存語言的相應(yīng)東西盡量相似，盡量吻合;使現(xiàn)有語言的概念和(新)概念能夠協(xié)同工作，反之亦然。這樣做了，我們才不會出現(xiàn)如下場面：嗯，這里是C#3，C#3支持硬嵌入其他語言的代碼，這些代碼不和C#3協(xié)同，但是它們和C#3使用同一個編譯器，你可以在C#3中用不同的代碼段硬嵌入它們。你肯定不希望出現(xiàn)這樣的場面，任何頭腦健全的人都不希望。因此，問題就是你怎樣才能更好的集成，這點才是我們經(jīng)常面臨的挑戰(zhàn)。
    Brian：這里就體現(xiàn)出LINQ的美妙了，因為LINQ可以讓你逐漸過渡。一開始你有遍歷器和“For…Each”語句，然后你可以使用新的，與SQL語句更加類似的“For”語法。這是個漸進(jìn)的過程，一步步來，慢慢學(xué)。要獲得LINQ給你提供的好處，你不必要一下就使用全套的“函數(shù)型”編程利器，搞一擊必殺，你可以慢慢來。
    Anders：呃，對我來說，價值所在是：我們在非常非常實際的問題——查詢、數(shù)據(jù)獲取、消除數(shù)據(jù)領(lǐng)域和通用編程領(lǐng)域之間進(jìn)行映射困難——上應(yīng)用了“函數(shù)型”編程的原則。你知道，這些是90%C#用戶每天都在做的事情，很明顯，我們在這里的工作非常有價值。
    Herb：同樣的事情也在“并發(fā)性”上發(fā)生。如果你用了些新的“硬嵌入”特性，也就是說，你寫了一些并發(fā)的代碼，用了不能與其他代碼協(xié)同工作的特性，你就是在自求失敗，沒有人會發(fā)布這樣的庫，人們會一直等下去，最終你發(fā)布不出來任何東西。因此，沒有人會這樣做。另一方面，你會想，我怎樣才能加一些東西，從而使我自己能夠從一些一直在做，但一直很痛苦地用手工做的事情中解脫出來。這就是要用一些抽象層來幫自己。我喜歡用“對象”來舉例。現(xiàn)在，每個人都在“對象”上工作，“對象”已經(jīng)成了人所共知，非常俗的一個詞了，難道還有誰不知道虛函數(shù)是什么東西嗎?但是，20年以前，我們參加那些“深入討論……”之類的研討會時，人們熱烈討論“什么是對象”，“什么是虛函數(shù)”，針對這些問題，一本又一本質(zhì)量參差不齊的書不斷地寫出來。實際上，這個所謂的“對象”并非什么全新的東西，在這個概念出現(xiàn)之前，人們已經(jīng)用C寫了15年的面向?qū)ο蟮拇a了?？纯碈的靜態(tài)庫，“fopen”為你創(chuàng)建了一個句柄;然后你調(diào)用“ftell”，將這個句柄當(dāng)作顯式傳遞的this指針;然后你調(diào)用“fclose”，相當(dāng)于調(diào)用析構(gòu)函數(shù)。因此，沒有什么太新的東西。那么，為什么人們要用“類”來代替這一切呢?因為我不想再用手寫虛表了，謝謝你，我有其他更加重要的事情要做。因此，這些抽象是為了處理人們已經(jīng)在做的事情，而且，在一定程度上，這是檢驗我們的設(shè)計是否良好的標(biāo)尺——當(dāng)你用這些抽象來處理已經(jīng)在做的事情時，是更加痛苦了，還是簡單了?以上的討論當(dāng)然適用于關(guān)于“并發(fā)”的抽象，因為，手動處理線程和鎖，與寫C代碼并無二致。用抽象層來處理這些老的并發(fā)問題時，應(yīng)該使工作更容易;我們也談到了“可組合性”，抽象層也應(yīng)該使“可組合性”更簡單。LINQ實際上同時處理了幾個問題，因為可組合性往往與并發(fā)緊密相連。比如，“我怎樣才能在同一個地址空間中組合這兩個東西，讓它們同時運行?”就是個與多方面相關(guān)的問題。因為LINQ內(nèi)生的抽象性，它關(guān)注的是要做什么，而不是如何去做的細(xì)節(jié)，這就使“運行時”可以接管調(diào)度和分配(比如，在4個、8個CPU上協(xié)同一個EXE)的工作。不管硬件如何，“運行時”負(fù)責(zé)使程序運轉(zhuǎn)良好，程序員完全不用作這方面的決策?，F(xiàn)在我們手動做這些事，是停止“手工寫虛表”的時候了，但是，我們需要提供更好的工具，這樣人們才能真正放棄手工操作，轉(zhuǎn)而使用抽象層，用10行代碼干完以前100行代瑪干的事。