微软架构师谈编程语言发展之五

Charles：但是在C#中做不到这样，你不能选择一些函数，然后就执行它们。

　　Anders：讲错台词了(译者注：Anders开玩笑，因为C#是微软的招牌，Anders暗指Charles这样讲不合适)，实际上，这个东西我们也可以考虑一下(把它加到C#中)，是的，这仅仅也只是工具方面的事情。

　　Herb：这是工具而已，从内部来说，实现它并没有什么障碍。这仅仅是工具的问题。你想要这东西吗?有投资吗?这东西对程序员重要吗?符合这种语言的侧重点吗?要考虑的是这些问题。

　　Anders：当然，动态语言已经显示出这是个重要的工具了。

　　Brian：之所以动态语言往往和这些交互的东西相联系，这完全是个历史偶然事件。APL可以说是所有这些东西的母亲。键入“/”、“←”、“(”、然后直接执行!哈哈哈!你知道，这些东西也是可以静态编译的。

　　Charles：让我们稍微谈谈。对我而言，语言革命的发展方向似乎是“命令型”和“函数型”的结合，对吗?

　　Anders：动态和静态的结合，说实在的，我认为主流是融合各个领域的特点。经典的、面向对象的、函数型的、动态的，你知道，我们从所有这些吸收可取之处，比起以前，生硬地嵌入(另一种语言的东西)将越来越不可取了。

　　Charles：你认为，这些东西综合起来对程序员生产率产生的影响，是否为正值?或者，对于那些如Herb所说，没有能够在20种语言上进行实验的程序员来说，这些将发生在C#和VB.NET上的事情将是奇怪和难以掌握的?这个世界突然要求更多地考虑副作用;语法、编程环境和程序院以前所熟知的也大为不同。当他们被带到这样的世界时会如何?我知道你们已经在LINQ上做了很棒的工作，但是，LINQ和C#程序员所熟知的环境还是不太一样。未来将会发生什么?

　　Anders：呃，(生产率)公式其实很简单，我是说，当你加入新的语言特性，新的功能的时候，你必须要谨慎地考虑对学习曲线的两端——熟手和生手——的影响。也许生产率增加了。也许你现在只需要10行代码就能搞定以前要100行代码的东西。是的，你需要学习如何写这10行代码，但是，嗨，一旦你学会了，你就可以不断地写更多的10行，你的生产率会提高。这是个经典的公式。

　　Charles：而且这些东西的可组合性也更好……

　　Herb：最终，所有代码应该统一。现在，你可以用鼠标选中一些代码，然后执行。然而，有的(新)东西你能很快掌握，有的东西就需要进一步学习了，这是语言必然带来的问题。大家关心的是，我们怎样才能使某些(新)东西和现存语言的相应东西尽量相似，尽量吻合;使现有语言的概念和(新)概念能够协同工作，反之亦然。这样做了，我们才不会出现如下场面：嗯，这里是C#3，C#3支持硬嵌入其他语言的代码，这些代码不和C#3协同，但是它们和C#3使用同一个编译器，你可以在C#3中用不同的代码段硬嵌入它们。你肯定不希望出现这样的场面，任何头脑健全的人都不希望。因此，问题就是你怎样才能更好的集成，这点才是我们经常面临的挑战。

　　Brian：这里就体现出LINQ的美妙了，因为LINQ可以让你逐渐过渡。一开始你有遍历器和“For…Each”语句，然后你可以使用新的，与SQL语句更加类似的“For”语法。这是个渐进的过程，一步步来，慢慢学。要获得LINQ给你提供的好处，你不必要一下就使用全套的“函数型”编程利器，搞一击必杀，你可以慢慢来。

　　Anders：呃，对我来说，价值所在是：我们在非常非常实际的问题——查询、数据获取、消除数据领域和通用编程领域之间进行映射困难——上应用了“函数型”编程的原则。你知道，这些是90%C#用户每天都在做的事情，很明显，我们在这里的工作非常有价值。

　　Herb：同样的事情也在“并发性”上发生。如果你用了些新的“硬嵌入”特性，也就是说，你写了一些并发的代码，用了不能与其他代码协同工作的特性，你就是在自求失败，没有人会发布这样的库，人们会一直等下去，最终你发布不出来任何东西。因此，没有人会这样做。另一方面，你会想，我怎样才能加一些东西，从而使我自己能够从一些一直在做，但一直很痛苦地用手工做的事情中解脱出来。这就是要用一些抽象层来帮自己。我喜欢用“对象”来举例。现在，每个人都在“对象”上工作，“对象”已经成了人所共知，非常俗的一个词了，难道还有谁不知道虚函数是什么东西吗?但是，20年以前，我们参加那些“深入讨论……”之类的研讨会时，人们热烈讨论“什么是对象”，“什么是虚函数”，针对这些问题，一本又一本质量参差不齐的书不断地写出来。实际上，这个所谓的“对象”并非什么全新的东西，在这个概念出现之前，人们已经用C写了15年的面向对象的代码了。看看C的静态库，“fopen”为你创建了一个句柄;然后你调用“ftell”，将这个句柄当作显式传递的this指针;然后你调用“fclose”，相当于调用析构函数。因此，没有什么太新的东西。那么，为什么人们要用“类”来代替这一切呢?因为我不想再用手写虚表了，谢谢你，我有其他更加重要的事情要做。因此，这些抽象是为了处理人们已经在做的事情，而且，在一定程度上，这是检验我们的设计是否良好的标尺——当你用这些抽象来处理已经在做的事情时，是更加痛苦了，还是简单了?以上的讨论当然适用于关于“并发”的抽象，因为，手动处理线程和锁，与写C代码并无二致。用抽象层来处理这些老的并发问题时，应该使工作更容易;我们也谈到了“可组合性”，抽象层也应该使“可组合性”更简单。LINQ实际上同时处理了几个问题，因为可组合性往往与并发紧密相连。比如，“我怎样才能在同一个地址空间中组合这两个东西，让它们同时运行?”就是个与多方面相关的问题。因为LINQ内生的抽象性，它关注的是要做什么，而不是如何去做的细节，这就使“运行时”可以接管调度和分配(比如，在4个、8个CPU上协同一个EXE)的工作。不管硬件如何，“运行时”负责使程序运转良好，程序员完全不用作这方面的决策。现在我们手动做这些事，是停止“手工写虚表”的时候了，但是，我们需要提供更好的工具，这样人们才能真正放弃手工操作，转而使用抽象层，用10行代码干完以前100行代玛干的事。