微软架构师谈编程语言发展（二）

 

微软架构师谈编程语言发展（二）

译者：程化

 

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