【转】微软架构师谈编程语言发展

1、.【转】微软架构师谈编程语言发展【网络综合-计算机软件程度考试指南】：Charles：好的。今天我们请到了微软设计编程语言的大师们。请你们介绍一下自己。译者注：Channel 9的主持人，从其对话来看，应该是编程出身，对于程序有很好的理解Herb：我是Herb Sutter，我是VC+小组的架构师。译者注：C+标准委员会主席，Exceptional C+系列的作者，C+领域的大牛人Erik：Erik Meijer，我在VB以及C#小组工作。译者注：先是SQL Server组的架构师，现为VB、C#组的架构师，从事把CLR、关系数据库、XML数据合为一体的伟大事业Brian：我是Brian Be

2、ckman，和Erik Meijer一起工作。呵呵译者注：物理学家，天体物理为主，业余时间写程序，包括编译器，自称来自从事影视娱乐业的家族，家里以其从事科学研究为奇Anders：我是Anders Hejlsberg，我的技术领域是C#。译者注：微软的"技术小子"，公认的牛人，C#的主要设计者，.NET框架的重要参与者。微软之前，Anders是Borland的工程师，Turbo PASCAL的主要开发人员，Delphi的首席架构师Charles：我们今天访谈主要讨论两个相关的论题：可组合性Composability与编程语言。作为程序员，当我们构造系统时，总是要面对这两个问题

3、。你们是创设语法，搭建架构的人。所以，我想讨论的一点是，你们是如何协调工作的?三个语言-C#、VB和C+，都在演进，同时又效劳于不同的目的，C+更多效劳于系统级，C#和VB更多偏向应用层面。而且，语言在不断创新译者注：谢谢ponda的修正。这一切是如何形成的?你们一起工作吗?你们是如何决定语言的创新的译者注：谢谢ponda的修正?你们是一起设计，还是想到什么后再与别人共享?很抱歉提这样的怪问题，请试着答复。Anders：我想，你说的两种情况都存在吧。事实上，早在我们做LINQ之前，Erik就在Comega工程做了很多工作了。在LINQ和Omega之间有很多相似之处，有很多互相影响的部分。我们一

4、直在讨论相关的问题。而且，Erik实际也在C#设计组中，所以，我们总是就当前的工作及时交换意见。VB组和C+组的人也在一幢楼里工作，大家经常碰到一起。所以，我认为这一切是互相浸透，以及不断聊天的结果。Charles：但是我的意思是，你们是否也象最终用户一样对自己做出区分?比方，有的事情在VB中能做，C#中就做不了。比方，对于VB来说，完全的晚绑定以非常简单的方式实现了，而C#中就没有晚绑定。为什么VB和C#有这样的不同?你们有意如此的吗?Anders：我认为这个问题更多的是历史原因。我想说的是，我们必须考虑历史因素，尤其当你讨论VB时更是如此。VB有其悠久而丰富的历史，从一开场，VB就作为晚绑

5、定的语言出现。开场时VB没有任何类型。很显然，晚绑定对于VB来说有某种核心作用。但是，从那时开场，VB已经逐步演进为一种更为"强类型"的语言，到如今，甚至你可以把VB看作一种支持晚绑定的强类型语言。呵呵。但实际上，这个过程是相反的。C#从一开场就是强类型语言，而且直到如今，我们都坚持早绑定。这并不是说我们在将来也不会支持晚绑定，但是，我们很可能以不同于VB的方式支持，而且可能对晚绑定的方式做些改进。C#是否支持晚绑定其实只是一种选择。对于老式的弱类型对象模型来说，比方OLE，假设我们从晚绑定角度出发，会比从早绑定角度出发好讨论得多，因为这种对象模型无非就是对象的假设干方法的

6、交互，反射，等等。Charles：这些东西完全可以靠底层帮你完成Anders：是的，对，非常正确！Herb：语言之间的差异在一定程度上是由用户引起的。对于靠近底层编程的C和C+程序员来说，性能永远都是一个核心和主要的问题。你可能发现不同语言有不同的特性，但是，更经常的是，你会发现这些不同特性想要解决的都是同一类的问题，比方，"并行执行"。如今，没有谁可以无视这个问题，并且，一种语言假设想在将来5到10年保存在主流编程语言的队伍中，这个问题就是无法无视的，因为这是硬件的开展方向。我们正处于一个新的时代，50年以来，我们首次在非单核的机器上工作。任何人都无法无视这个现象。因此，

7、就这个问题来说，大家都要处理一些相似的东西，但是，处理方式、语法可能不同，详细的特性也可能不尽一样。我也相信，不同语言推出同一特性的时间先后顺序也不一样，因为不同同语言针对不同的客户群体效劳，客户要求的东西不一样，因此，对于特性处理的时间先后顺序并不一致。就像Anders说的，各种情况都有一些。Erik：是这样的。对VB和C#有怎样的差异，我可以给出一个详细的例子。该例子是"无名函数或'lambda表达式'"。我们想在VB中也参加这种功能。首先就是寻找正确的语法。我们向VB工程组要到了VB的名称表，名称表中的名字支持两种语法的都有VB和C#。但是，这次他们想

8、要更像关键字的名字，而不是C#那样长长的名字，因为他们觉得像关键字的名字更加"VB化"一些。这里你看到的就是语法上的区别。但是，在语义上也是有区别的。当你查看一个大函数内部的，嵌套很深的构造，比方"for"循环的时候，语言是何时、如何处理变量捕获，如何进展实例保护的就非常不同。在C#中，每次循环时实例都被保护，而在VB中，象JavaScript那样，变量是被隐性提升到函数顶部的。所以，在变量捕获方面，语义上的区别也存在。有时这些区别是极其细微的，你必须写非常变态的程序才能看到这些区别。Anders：只要你写出依赖这样的特性的程序，我们就能找出成百的Bug

9、。Brian：你逃不出"作战室"的。译者注：微软"作战室"，是产品、程序、测试人员一起确认需求、找Bug之所在。Charles：这样看来，大家都同意不同语言在互相影响，不断演进。对于VB和C#来说，有一样的核心：处理引擎，你们必须在CLR的根底上出发，随着CLR的演进而演进。很显然，C+属于另一个世界。但各种语言要互相影响，你们必须在C#中加点什么来吸引用户，让他们用C#而不是VB.NET，是吧?应该不止是语法的区别，语言中必须还有一些核心的东西来吸引用户。Herb：你说得对。但是，我不同意你提出的理由，说我们必须在各自的语言中加点什么特性吸引用户，从而

10、使他们不去使用其他的微软的语言。为什么呢?比方我更加关心使用C+或者C#的用户到底需要什么，怎样才能帮助他们把工作完成得更好。也许某种语言性能强大，但我的工作是怎样才能使客户的工作更成功?我必需要考虑客户会如何集成，我怎样做才能使客户工作得更好，这也是CLR的核心所在，因为目前已经不是靠一种语言就能完成整个工程的时代了。我疑心在稍有点规模的工程中，是否还有人仅仅依靠一种开发语言。一般说来，你用脚本语言写代码；其他语言写工具和组件；系统语言写核心-不停地在做集成。这就带来了我们所讨论的"可组合性"的问题。因为"可组合性"本质上就是跨语言的问题。当你写Web

11、阅读器时，你不知道某个插件是用C#、C+，某种CLR扩展，还是其他什么写的。不管如何，这些东西必须一起工作，这就是主要的挑战。因为，要想使这种"可组合性"成为现实，我们必须时时将CLR和CLR以外的东西当作白盒来考虑。但是，这样做的时候又会碰到"锁"的问题。"并发执行"已经越来越重要了，但是，"锁"完全不具备可组合性。因此，这是"可组合性"面对的主要障碍。总之，对我而言，这更多的是一个语言交互的问题，而非语言竞争的问题。Brian：我在一定程度上代表了用户。我是个物理学家，同时，我也经常写点小程

12、序，进展模拟和仿真，解决一些数学问题。要想成功，"可组合性"对我的来说非常重要。我可以不在乎编程语言，但是我很在乎该语言是否有我所需要的组件。根本上，我非常愿意使用任何能使我的工作更简单的编程语言。这里，我要戴上顶"老人"帽，谈谈历史上非常少的成功软件之一：数值计算库。这些东西是N年以前用Fortran写的。几十年以来，人们用这些库解决了许多非常重要的科学问题。任何头脑正常的人都不会想重新写一个"线性代数包"或者类似的东西。有许多数学家终其一生在完善这些软件包。我们需要的是"互操作性"，更是"可组合性&q

13、uot;。所有人都知道，Fortran不支持递归，因为变量基于引用传递。这就带来了包接口的问题：假设你想要集成自身就做集成的东西，你就不能在用这个包来集成自己，这行不通。回到C+、C#和VB上，这些语言我都使用，但更喜欢C#一些，主要因为它的操作符重载。为什么我喜欢操作符重载?因为我做奇怪的线代计算，如四元数、八元数，此时用一个小加号就可以代表一大堆怪异的计算。可能听上去有点像是使用模板，但绝不是这样，我一用模板就会开场想：模板的预处理器是完备的，也许我可以仅用模板就实现出一个链表处理库来解决。很快，我就会偏离真正的数学考虑。在应用程序绝对需要晚绑定的场合，比方，那些小的计算模拟器。此时，我很

14、自然地会选择VB。至于C+，大多数时候，它被用来实现其他的语言。在用于科学的环境下，我屡次实现过Scheme。总之，就是泛谈"可组合性"。Anders：当我开场编程生涯时，进入编程这行的学习曲线就是：学习要使用的编程语言本身。各个编程语言几乎在每个方面都不一样。语法是你要学习的很大一部分。但这是以前的事了，如今你要学习宏大的框架，这个框架正越变越大，语法只是顶上的一颗"小樱桃"，我认为这方面确实进展很大。但是，实际上起作用的东西是学习所有的API，学习你所基于的，越来越大的平台或者框架。如今，学习曲线的90%都消耗在这上面。掌握了这些，你就可以在C+、C

15、#或者VB.NET什么的之间，毫不费力地进展语言转换，将部分工程使用这种语言，部分工程使用那种，并且找出组合这些语言的解决方案。相对于以前，实际上是不久之前，这是个主要的进步。当然，所有这些得以出现，是由于有了通用的类型系统，以及各种语言中的那些抽象。每种语言之间的差异那么是细微的，而且这些差异说不上来有什么特别的理由。Brian：有时，这些语言必须综合运用。比方，如今的Windows编程就是一大苦事：你必须懂PHP、JavaScript、HTML、XML、SQL等等，要把这些东西全写到名片上，你就只有小小的一块地方可以写自己的名字了。当然，可以同时使用多种语言也有好处，至少你可以选择自己喜欢

16、的语法。Erik：我们的编程语言之所以有差异，还是因为这些语言没有可以统一起来，在语言下面还有假设干不一致的地方，我们实际上是被强迫使用不同的东西。CLR就不一样，基于CLR上使用一样的库，这些语言之间的排他性就要少一些，你可以选择，而非被迫使用某种特定的语言。Brian：目前我们做得很多工作就是减少大家被迫使用某种语言这种情况。我们努力改进平台，增加更多的功能，提供更多的.NET库。Charles：但是，C+除之外，像VB和C#这样的语言，确实绑定在某个框架上。这样的话，在一定意义上是否有局限性?如函数型程序等将如何融入到我们所谈的宏大的框架中呢?比方Haskell，又比方流行的F#，它们的

17、构造与如今的语言完全不同。Erik：假设我们用"命令型语言"编程，我们的根本成份是"语句"。"语句"使用并且共享"状态"，从而导致不太好的"可组合性"。你不能拿着两段语句，然后简单地把它们粘合到一起，因为它们的全局状态不能很好地交互。这就导致"命令型语言"不能很好地组合到一起。假设你看看LINQ，就会发现我们已经更多地采用"函数型语言"的风格，所有的东西都基于表达式。"表达式"从其定义来说就是可组合的。从一定意义上来说，我认为在C#3和

18、VB9中没有什么东西是Haskell或F#中没有的。这里面有一些深奥的事情，假设你看看Haskell的类型系统，你就会发现这个类型系统跟踪程序的副作用。这给了你一定形式的可组合性。如今你虽然不能把有某种副作用的语句组合到有其他副作用的语句上，但是，你可以组合副作用一样的东西。F#有一个非常强悍的类型推断机制，它从设计之初就考虑了类型推断。我们以前也有类型推断，这并非什么新东西，但是如今的类型推断要考虑很多困难因素，比方，重载，这些东西使类型推断很困难。假设你从这个角度来看，我认为我们已经在很大程度上采用了浓重的"函数型"风格，并且以相当"可组合"的方式来

19、使用表达式和lambda表达式。Anders：我们对"函数型编程"的兴趣并非学院式兴趣。实际上，当编程语言向前推进时，我们面临两类挑战。一是古老的追求-不断进步程序员的消费率，对此将沿用一直以来的方法：提升抽象的层次，给程序员垃圾回收机制、类型平安、异常处理，甚至是全新的"声明型"编程语言等。在提升抽象层次的过程中，正如Erik指出的，这些"声明型"语言获得了更高层次的"可组合型"。"函数型"语言之所以有魅力，因此你可以做出"没有副作用"，或者其他承诺，这样一来可组合性就极大

20、地进步了。不仅如此，在如何保证多核处理器、多CPU，比方，32个CPU始终繁忙，我们也会有所收获。显然，当我们更多地使用"函数型"或者"声明型"风格的编程时，我们更有可能把运行时框架构建得能更好地发挥多核的优势，更好地处理并发。假设以"命令型"风格来工作，我们可以发挥的余地就很小，因为你无法预见所有动作-这儿拿点东西，那儿放点东西，所有动作必须串行执行，否那么不可意料的事情就会发生。Charles：作为程序员，使用了如此宏大的一个处理引擎-比方CLR之后，当然认为这些底层的东西应该被抽象掉。你的意思也是，假设我使用了一个4核的机器，运

21、行时引擎应该有才能负责在CPU上的分配分配进程。Anders：你这样想很正常。但是，CLR以及目前我们工业中绝大多数的运行时，都是"命令型"引擎，其指令集都相当传统，比方，堆栈增长；它们也拥有易变的状态，包括易变的全局状态等等。在此之上，之所以能进展"函数型"编程，是因为"函数型"编程从本质上来说，是"命令型"编程所具备的才能集的一个子集。如今我们想做的是最大化这种灵敏性，但其实不过也就是让"函数型"才能子集越来越相关，使其越来越主流化而已。Herb：我认为有必要将"函数型"编程领域划分成两个部分。我非常同意Anders和Erik的意见。我不太同意的是这样的措辞：我们之所以继续使用"命令型"编程语言，是因为这是大家目前所能理解的；通用程序开发者