天行健 君子当自强而不息

【ZT】微软架构师谈编程语言发展(3)


 
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:很棒!会议室到时间了。访谈很棒,谢谢大家。我希望能够和大家再次交谈,如果你们关于编程语言的演进有什么想法,欢迎联系我。谢谢大家的宝贵时间!

posted on 2007-09-11 14:20 lovedday 阅读(256) 评论(0)  编辑 收藏 引用 所属分类: ▲ Software Program


只有注册用户登录后才能发表评论。
【推荐】超50万行VC++源码: 大型组态工控、电力仿真CAD与GIS源码库
网站导航: 博客园   IT新闻   BlogJava   知识库   博问   管理


公告

导航

统计

常用链接

随笔分类(178)

3D游戏编程相关链接

搜索

最新评论