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)上，如果我們用“命令型語言”編程，我們的基本成份是“語句”?！罢Z句”使用并且共享“狀態(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ì)上來說，是“命令型”編程所具備的能力集的一個子集?，F(xiàn)在我們想做的是化這種靈活性，但其實不過也就是讓“函數(shù)型”能力子集越來越相關(guān)，使其越來越主流化而已。
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)上，如果我們用“命令型語言”編程，我們的基本成份是“語句”?！罢Z句”使用并且共享“狀態(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ì)上來說，是“命令型”編程所具備的能力集的一個子集?，F(xiàn)在我們想做的是化這種靈活性，但其實不過也就是讓“函數(shù)型”能力子集越來越相關(guān)，使其越來越主流化而已。