Brian：我插句嘴。我在一定程度上代表了用户。我是个物理学家，同时，我也经常写点小程序，进行模拟和仿真，解决一些数学问题。要想成功，“可组合性”对我的来说是绝对地重要。我可以不在乎编程语言，但是我很在乎该语言是否有我所需要的组件。我有点夸张了，因为我其实还是在乎编程语言的，呵呵。基本上，我十分愿意使用任何能使我的工作更简单的编程语言。
这里，我先戴上顶“老人”帽，谈谈这个世界的历史上，非常少的成功软件之一——数值计算库（译者注：谢谢drdirac的修正）。这些东西是N年以前用FORTRAN写的。几十年以来，人们用这些库解决了许多非常重要的科学问题。任何头脑正常的人都不会想坐下来从头写一个“线性代数包”（译者注：谢谢drdirac的修正）或者类似的东西。有许多数学家终其一生在完善这些软件包。我们需要的是“互操作性”。不简单的是互操作性，我们需要的是“可组合性”。所有人都知道，FORTRAN不支持递归，因为所有的变量都是引用传递。这就带来了包之间接口问题。如果你想要集成某种自身内部不支持集成的东西，你就不能再需要集成的两边使用这样同一个包用于集成，这行不通。呃，我已经忘了最开始我在说啥了，哈哈，我尽讲些物理小故事了。让我回到C++、C#和VB上。这些语言我都要使用，我更喜欢C#一些，因为我喜欢它的操作符重载。为什么我喜欢操作符重载？因为我做数学计算，类似于XX和XX（译者注：听不清）的奇怪算法，用一个小加号就能够代表那些要进行的一大堆计算。
Erik：伙计，也许你想用的是模板？哈哈。
Brian：（译者注：看样子生怕别人认为自己不知道模板）不，我才不想用模板呢。只要我一用模板，我就会开始想：喔，模板的预处理器是图灵完备的（译者注：谢谢drdirac的修正），我也许能够在库中做队列处理……很快，我就会偏离真正的数学思考。在应用程序绝对需要晚绑定的场合（比如，那些小的计算模拟器什么的，晚绑定是成功的关键），此时，很自然地，我会选择VB。至于C++，天哪，大多数时候，C++用来实现其他的语言，做这类事C++很拿手。在用于科学的环境下，我多次实现过Scheme（译者注：谢谢drdirac的修正）。
总而言之，我就是泛泛谈谈“可组合性”。
Anders：如果你回过头去看看十年之前，会发觉潮流已经逐渐变化了。当我开始编程生涯时，进入编程这行的学习曲线就是：学习要使用的编程语言本身。各个编程语言几乎在每个方面都不相同。语法是你要学习的很大一部分。这是以前的事了。现在，你要学习巨大的框架，这个框架正越变越大，语法只是顶上的一小颗樱桃。我认为我们在这方面确实前进了很多。很有趣的是，编程语言就像你的眼镜一样，所有的东西根据编程语言的不同，要么看着是玫瑰色的，要么是紫色的，如此等等。但是，实际上起作用的东西是学习所有的API，学习你所基于的，越来越大的平台或者框架。如今，学习曲线的90%都耗费在这上面。掌握了这些，你就可以在C++、C#或者VB.NET什么的之间，毫不费力地进行语言转换，将部分项目使用这种语言，部分项目使用那种，并且找出组合这些语言的解决方案。相对于以前，实际上是不久之前，这是个主要的进步。当然，这些能出现，是由于有了通用的类型系统，以及各种语言中的那些抽象。每种语言之间的差别则是细微的，而且这些差别说不上来有什么特别的理由。
Brian：是的，在有的情况下，多种语言互相关联。比如，如今的Windows编程就是一项大苦差：你必须懂PHP、JavaScript、HTML、XML、SQL等等，要把这些东西全写到名片上，你就只有小小的一块地方可以写自己的名字了。哈哈哈。当然，能够同时使用多种语言也是有好处的，至少你可以选择自己喜欢的语法……
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以及我们的工业中目前绝大多数的运行时，都是“命令型”引擎，其指令集都是相当传统的，比如，堆栈增长啥的，以及拥有易变的状态，包括易变的全局状态等等。在此之上能够进行“函数型”编程，因为“函数型”编程从本质上来说，是“命令型”编程所具备的能力集的一个子集。现在我们想做的是最大化这种灵活性，但其实不过也就是让“函数型”能力子集越来越相关，使其越来越主流化而已。
