微软架构师谈编程语言发展(一)

  
本文是对微软Channel 9中采访几个语言大牛的视频的翻译。
名字为Anders Hejlsberg, Herb Sutter, Erik Meijer, Brian Beckman: Software Composability and the Future of Languages
大家可以找来看看。
个人感觉这些大牛高屋建瓴,有点有面地谈到了多个语言的发展和语言的相互关系,对于我们开拓视野非常有帮助。由于只能靠听来翻译,篇幅又长,只能分段(估计有4-5段)慢慢来。而且,水平所限,难免错误,请大家指正。
 
微软架构师谈编程语言发展(一)
译者:程化
 
Charles:好的。今天我们请到了微软设计编程语言的大师们。请你们介绍一下自己。
(译者注:Channel 9的主持人,从其对话来看,应该是编程出身,对于程序有很好的理解)
 
Herb:我是Herb Sutter,我是VC++小组的架构师。
(译者注:C++标准委员会主席,Exceptional C++系列的作者,C++领域的大牛人)
 
Erik:Erik Meijer,我在VB以及C#小组工作。
(译者注:先是SQL Server组的架构师,现为VB、C#组的架构师,从事把CLR、关系数据库、XML数据合为一体的伟大事业)
 
Brian:我是Brian Beckman,和Erik Meijer一起工作。呵呵
(译者注:物理学家,天体物理为主,业余时间写程序,包括编译器,自称来自从事影视娱乐业的家族,家里以其从事科学研究为奇)
 
Anders:我是Anders Hejlsberg,我的技术领域是C#。
(译者注:微软的“技术小子”,公认的牛人,C#的主要设计者,.NET框架的重要参与者。微软之前,Anders是Borland的工程师,Turbo PASCAL的主要开发人员,Delphi的首席架构师)
 
Charles:我们今天访谈主要讨论两个相关的论题:可组合性(Composability)与编程语言。作为程序员,当我们构造系统时,总是要面对这两个问题。你们是创设语法,搭建架构的人。所以,我想讨论的一点是,你们是如何协调工作的?三个语言——C#、VB和C++,都在演进,同时又服务于不同的目的,C++更多服务于系统级,C#和VB更多偏向应用层面。而且,语言在不断创新(译者注:谢谢ponda的修正)。这一切是如何形成的?你们一起工作吗?你们是如何决定语言的创新的(译者注:谢谢ponda的修正)?你们是一起设计,还是想到什么后再与他人共享?很抱歉提这样的怪问题,请试着回答。
 
Anders:我想,你说的两种情况都存在吧。事实上,早在我们做LINQ之前,Erik就在Comega项目做了很多工作了。在LINQ和Omega之间有很多相似之处,有很多互相影响的部分。我们一直在讨论相关的问题。而且,Erik实际也在C#设计组中,所以,我们总是就当前的工作及时交换意见。VB组和C++组的人也在一幢楼里工作,大家经常碰到一起。所以,我认为这一切是相互渗透,以及不断聊天的结果。
 
Charles:但是我的意思是,你们是否也象最终用户一样对自己做出区分?比如,有的事情在VB中能做,C#中就做不了。比如,对于VB来说,完全的晚绑定以非常简单的方式实现了,而C#中就没有晚绑定。为什么VB和C#有这样的不同?你们有意如此的吗?
 
Anders:我认为这个问题更多的是历史原因。我想说的是,我们必须考虑历史因素,尤其当你讨论VB时更是如此。VB有其悠久而丰富的历史,从一开始,VB就作为晚绑定的语言出现。(开始时)VB没有任何类型。很显然,晚绑定对于VB来说有某种核心作用。但是,从那时开始,VB已经逐步演进为一种更为“强类型”的语言,到现在,甚至你可以把VB看作一种支持晚绑定的强类型语言。呵呵。但实际上,这个过程是相反的。C#从一开始就是强类型语言,而且直到现在,我们都坚持早绑定。这并不是说我们在未来也不会支持晚绑定,但是,我们很可能以不同于VB的方式支持,而且可能对晚绑定的方式做些改进。C#是否支持晚绑定其实只是一种选择。对于老式的弱类型对象模型来说,比如OLE,如果我们从晚绑定角度出发,会比从早绑定角度出发好讨论得多,因为这种对象模型无非就是对象的若干方法的交互,反射,等等。
 
Charles:这些东西完全可以靠底层帮你完成……
 
Anders:是的,对,非常正确!
 
Herb:语言之间的差异在一定程度上是由用户引起的。对于靠近底层编程的C和C++程序员来说,性能永远都是一个核心和主要的问题。你可能发现不同语言有不同的特性,但是,更经常的是,你会发现这些不同特性想要解决的都是同一类的问题,比如,“并行执行”。现在,没有谁能够忽视这个问题,并且,一种语言如果想在未来5到10年保留在主流编程语言的队伍中,这个问题就是无法忽视的,因为这是硬件的发展方向。我们正处于一个新的时代,50年以来,我们首次在非单核的机器上工作。任何人都无法忽视这个现象。因此,就这个问题来说,大家都要处理一些相似的东西,但是,处理方式、语法可能不同,具体的特性也可能不尽相同。我也相信,不同语言推出同一特性的时间先后顺序也不相同,因为不同语言针对不同的客户群体服务,客户要求的东西不一样,因此,对于特性处理的时间先后顺序并不一致。就像Anders说的,各种情况都有一些。
 
Erik:是这样的。对VB和C#有怎样的差异,我可以给出一个具体的例子。该例子是“无名函数(或‘lambda表达式’)”。我们想在VB中也加入这种功能。首先就是寻找正确的语法。我们向VB项目组要到了VB的名称表,名称表中的名字支持两种语法的都有(VB和C#)。但是,这次他们想要更像关键字的名字,而不是C#那样长长的名字,因为他们觉得像关键字的名字更加“VB化”一些。这里你看到的就是语法上的区别。但是,在语义上也是有区别的。当你查看一个大函数内部的,嵌套很深的结构,比如“for”循环的时候,语言是何时、如何处理变量捕获,如何进行实例保护的就非常不同。在C#中,每次循环时实例都被保护,而在VB中,象JavaScript那样,变量是被隐性提升到函数顶部的。所以,在变量捕获方面,语义上的区别也存在。有时这些区别是极其细微的,你必须写非常变态的程序才能看到这些区别。
 
Anders:每次你写出依赖这样的特性的程序时,我们就能找出成百的Bug。呵呵
 
Erik:是啊是啊。
 
Brian:你逃不出作战室的
(译者注:微软的“作战室”,是产品、程序、测试人员一起对需求、找Bug之所在。)
 
Charles:这样看来,大家都同意不同语言在相互影响,不断演进。对于VB和C#来说,你们有相同的核心——处理引擎,你们必须在CLR的基础上出发,随着CLR的演进而演进。很显然,C++属于另一个世界。但是,各种语言要互相影响,你们必须在C#中加点什么来吸引用户,让他们用C#而不是VB.NET,是吧?应该不止是语法的区别,语言中必须还有一些核心的东西来吸引用户。
 
Herb:我认为你说的是对的。但是,我不同意你提出的理由,说我们必须在各自的语言中加点什么特性吸引用户,从而使他们不去使用其他的微软的语言。为什么呢?比如我吧,我更加关心使用C++或者C#的用户到底需要什么,我怎样才能帮助他们把工作完成得更好。也许某处有某种很牛的特性的语言,但我的工作是——怎样才能使客户的工作更成功?我必须要考虑客户会如何集成,我怎样做才能使客户工作得更好,这也是CLR的核心所在,因为目前已经不是靠一种语言就能做完整个项目的时代了。我怀疑在稍有点规模的实际项目中,是否还有人仅仅依靠一种开发语言。一般说来,你用脚本语言写点东西,其他语言写工具和组件,系统语言写核心的东西。你不停地在做集成。这就带来了我们所讨论的“可组合性”的问题。因为“可组合性”本质上就是跨语言产生的问题。当你写Web浏览器时,你不知道某个插件是用C#,C++,某种CLR扩展,还是其他什么写的。不管如何,这些东西必须一起工作,这就是主要挑战之所在。因为,要想使这种“可组合性”成为现实,我们必须时时将CLR和CLR以外的东西当作白盒来考虑。但是,我们这样做的时候又会碰到“锁”的问题。“并行执行”已经越来越重要了,但是,“锁”是完全不具备组合性的。因此,这是“可组合性”面对的主要障碍。我实际上已经转移到另一个话题上了。总之,对我而言,这更多的是一个语言交互的问题,而非语言竞争的问题。
 
Brian:我插句嘴。我在一定程度上代表了用户。我是个物理学家,同时,我也经常写点小程序,进行模拟和仿真,解决一些数学问题。要想成功,“可组合性”对我的来说是绝对地重要。我可以不在乎编程语言,但是我很在乎该语言是否有我所需要的组件。我有点夸张了,因为我其实还是在乎编程语言的,呵呵。基本上,我十分愿意使用任何能使我的工作更简单的编程语言。
这里,我先戴上顶“老人”帽,谈谈这个世界的历史上,非常少的成功软件之一——数值计算库(译者注:谢谢drdirac的修正)。这些东西是N年以前用FORTRAN写的。几十年以来,人们用这些库解决了许多非常重要的科学问题。任何头脑正常的人都不会想坐下来从头写一个“线性代数包”(译者注:谢谢drdirac的修正)或者类似的东西。有许多数学家终其一生在完善这些软件包。我们需要的是“互操作性”。不简单的是互操作性,我们需要的是“可组合性”。所有人都知道,FORTRAN不支持递归,因为所有的变量都是引用传递。这就带来了包之间接口问题。如果你想要集成某种自身内部不支持集成的东西,你就不能再需要集成的两边使用这样同一个包用于集成,这行不通。呃,我已经忘了最开始我在说啥了,哈哈,我尽讲些物理小故事了。让我回到C++、C#和VB上。这些语言我都要使用,我更喜欢C#一些,因为我喜欢它的操作符重载。为什么我喜欢操作符重载?因为我做数学计算,类似于四元数和八元数(译者注:谢谢pongba的修正)的奇怪线代运算,用一个小加号就能够代表那些要进行的一大堆计算。
 
Erik:伙计,也许你想用的是模板?哈哈。
 
Brian:(译者注:看样子生怕别人认为自己不知道模板)不,我才不想用模板呢。只要我一用模板,我就会开始想:喔,模板的预处理器是图灵完备的(译者注:谢谢drdirac的修正),也许我可以仅用(模板)就实现出一个链表处理库来(译者注:谢谢pongba的修正)……很快,我就会偏离真正的数学思考。在应用程序绝对需要晚绑定的场合(比如,那些小的计算模拟器什么的,晚绑定是成功的关键),此时,很自然地,我会选择VB。至于C++,天哪,大多数时候,C++用来实现其他的语言,做这类事C++很拿手。在用于科学的环境下,我多次实现过Scheme(译者注:谢谢drdirac的修正)。
总而言之,我就是泛泛谈谈“可组合性”。
 
Anders:如果你回过头去看看十年之前,会发觉潮流已经逐渐变化了。当我开始编程生涯时,进入编程这行的学习曲线就是:学习要使用的编程语言本身。各个编程语言几乎在每个方面都不相同。语法是你要学习的很大一部分。这是以前的事了。现在,你要学习巨大的框架,这个框架正越变越大,语法只是顶上的一小颗樱桃。我认为我们在这方面确实前进了很多。很有趣的是,编程语言就像你的眼镜一样,所有的东西根据编程语言的不同,要么看着是玫瑰色的,要么是紫色的,如此等等。但是,实际上起作用的东西是学习所有的API,学习你所基于的,越来越大的平台或者框架。如今,学习曲线的90%都耗费在这上面。掌握了这些,你就可以在C++、C#或者VB.NET什么的之间,毫不费力地进行语言转换,将部分项目使用这种语言,部分项目使用那种,并且找出组合这些语言的解决方案。相对于以前,实际上是不久之前,这是个主要的进步。当然,这些能出现,是由于有了通用的类型系统,以及各种语言中的那些抽象。每种语言之间的差别则是细微的,而且这些差别说不上来有什么特别的理由。

没有更多推荐了,返回首页