主题：微软架构师谈编程语言发展之二

　　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以及我们的工业中目前绝大多数的运行时，都是“命令型”引擎，其指令集都是相当传统的，比如，堆栈增长啥的，以及拥有易变的状态，包括易变的全局状态等等。在此之上能够进行“函数型”编程，因为“函数型”编程从本质上来说，是“命令型”编程所具备的能力集的一个子集。现在我们想做的是最大化这种灵活性，但其实不过也就是让“函数型”能力子集越来越相关，使其越来越主流化而已。