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

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

译者：程化

（译者注：访谈到现在，众人已经很放松，谈话随意，插嘴较多，因此我加了比较多的句子补充和注解，利于理解。当然，这些是我自己的理解，可能是错误的，欢迎指正！）

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行代玛干的事。

（译者注：Herb一说就是长篇大论，到后面说高兴了，似乎已经忘记前面关于程序员要考虑副作用的事了。）

Erik：这是很重要的一点。我认为，作为语言的设计者，我们在“计算机帮助我们编程”上做得还不够好，因此我们才有很多东西需要手动做。看看在类型推断上我们做的事情，对于那些我们已经掌握的关于程序的信息，我们用计算机的力量来代替手动寻找。如果你想要“并发性”，如果你想要把程序语言设计得可以使用工具，使用计算机来帮忙获得更好的“并发性”，我认为我们可以做得更多。我们实际上可以把工具设计得可以互相帮忙，这样就可以加速前进。我考虑过很多东西，甚至“运行时”，因为我们有元数据，因此我们现在可以进行垃圾回收，以及进行其他处理。对我来说，这就是趋势所在：你如何设计程序语言、编程环境，从而其他程序可以“钩入”，帮助你做事情。从一定意义上来说，对“非托管代码”，工具就不太能帮上忙了，因为没有足够的内部结构（让其他工具可以钩入）。我认为，这是驱动很多东西的因素，我们今天谈论的很多东西都可以从这个角度来审视。

Charles：我想问个问题：多少抽象才算多？你们在抽象的路上能走多远？我的意思是，在某点上，有可能不用写代码了吗？

Anders：在抽象问题上，我通常看到的问题是：上移抽象层次，与增加抽象层次是有区别的。我认为，通常说来，上移抽象层次是一种罪恶。上移抽象层次意味着我们在“美妙的工作流商业概念层”，或其他类似层次上编程，对吧？如果想往下靠靠，呃，很不幸，现在你不能调用方法，或者写表达式，或者做其他以前你能够做的事情了。因此，你得到一些，失去一些，总体来说，伙计，有时候你干不了事。我认为重要的是增加抽象层次。你不能拿走底层的东西。是的，我们可以谈工作流、规则，以及其他的东西，比如，在JDE（译者注：Job Description Environment？工作描述环境？）中声明东西。但是，你仍然可以到底层去，写那么两行代码，从而省掉一天的时间，对吧？你不用经常到底层去，但是救生口在那里。对我而言，实际上，是“抽象的范围”（译者注：抽象覆盖了多少个层次，也就是说有多少层抽象）体现了工具的能力，而非抽象的层次（译者注：在多高的层次上抽象，因为光追求高层次抽象就是把抽象层次上移），如果你一直在听我说的话（你应该知道我的意思）。

Herb：当然，说的太对了。这和现在我们写一个库的情况是一码事。我们写一个函数，用名字调用它，因此我们就不必每次都写上几百行代码了。这个事情（是否写库）可以由程序员自行决定，大量编写（译者注：这相当于增加抽象层次）。但是，谈到语言特性时，有时，你不指望程序员能为你写出另一部分编译器（译者注：Herb指由应用程序开发者来实现某些语言特性。微软的Phoenix项目将提供这样的框架，可以由其他的程序员来实现部分的编译器。呵呵），你希望由语言来帮助你，由工具来帮助你（译者注：这相当于抽象层次上移）。界限基本上就是：库和语言。什么地方真的需要工具的帮助？因为工具不知道（很多具体事情），而工具影响代码产生的方式，然后，你就不能仅仅依靠程序员写出更好的类、更好的框架（因为人们也能自行决定是否编写框架）或其他什么来解决问题了。这些东西将使协同变得很复杂，很难理解。

（译者注：看起来Herb不是很赞成使用很多工具来帮助编程，不知道理解得对不对）

Erik：呃，从定义上来讲，我认为不可能有过多的抽象，因为抽象意味着剔除不必要的细节。因此，如果细节不是必要的，你就可以剔除它们。但是，我觉得……（译者注：场面混乱，噪音陡涨，众人都纷纷对这个意外的角度表示感兴趣）。有时候你会把必要的细节抽象出去了，因此你得不到这些必要的东西了，此时抽象就走得太远了。但是根据我的定义，你不是真的在抽象，因为你剔除了必要的细节。

Brian：我们管这叫“分散”。

Charles：那这就是说……，呃，好像有人要用这个会议室？

Anders：是的，我们要被赶走了。

Charles：我们还有一分钟。刚才那个论点很棒，我是说，抽象的层次与仅仅上移抽象（Anders插嘴：抽象的范围和抽象的层次）。但是，有的东西在CLR就是很难得到，比如，当我写一个完全托管的程序时，如果不用那个相当复杂的P/Invoke模型，要得到一些相当底层的结构，是相当困难的。

Anders：是的！但是，想象一下这样的世界：你没有P/Invoke！我是说，这实际上是个把抽象上移的例子。然而，救生口（P/Invoke模型）在那儿，当然，我们现在竭尽所能，使你根本不必动用这个救生口，但是，如果你必须要去那里，你可以去，对吧？

Herb：对你自己而言，把救生口焊死是非常不利的。

Anders：是的。因为，在某些情况下，总有些傻傻的原因会使你从箱子上跌落下来，对吧？

Charles：好的。在走之前，让我们轮流说说语言的发展方向。我没有别的意思，只是想让大家谈谈，就不断演化的语言来说，我们正在向何处去？快速地轮流说说，告诉我你认为将来是怎样的，比如，5年后会如何？对你来说，在你的语言中，向开发者提供什么是重要的？怎么样？

（译者注：Charles明显有语无伦次的嫌疑。估计累了……）

Anders：我想说，好像从我开始哈（译者注：Anders坐在桌子一头，Herb坐在另一头，Anders率先开说，突然之间觉得不妥，故此加了这一句）。我们已经看到了语言特性的融合，对吧？对我来说，这就是主流。但是，关于将要解决的主要问题（正出现在地平线上），我想是：我们如何处理多核？更好的并发编程模型是什么？只是个非常简单的概括。

Brian：我以前的模型是：让数学家成为更好的程序员。我现在的模型是：让程序员成为更好的数学家。我希望编程语言看起来更像数学。

（译者注：窃以为Brian现在的模型不符合软件工业化的要求）

Erik：我想用工具来增进人的智能。计算机比我们的能力要强大得多，我希望计算机能够帮助我编程，我希望我的程序能够设计得使这种帮助成为可能。

Herb：大家说了很多了。是的，从其他语言借鉴，尤其是把“函数型”风格植入“命令型”语言，是个趋势。这个趋势不难看出，而且在未来几年都将保持（译者注：Herb在这里开了个什么玩笑，没有听清）。另外就是，能够讨论并发问题，尤其是在线程和锁之上增加抽象层次。很多人在解决这个问题，事务内存、交互式对象，等等。LINQ在这里很有希望，LINQ在非并发领域已经做了很多好工作，这些工作能够直接应用到并发领域。所以，我们正在各方面不断推进，并且把所有工作整合到一起。

Charles：很棒！会议室到时间了。访谈很棒，谢谢大家。我希望能够和大家再次交谈，如果你们关于编程语言的演进有什么想法，欢迎联系我。谢谢大家的宝贵时间！

<<全部翻译结束>>