Scala起源Martin Odersky访谈(第一部分)by Bill Venners and Frank Sommers译者杨博
摘要
Martin Odersky与Bill Venners谈论Scala编程语言如何创立的相关历史。
Scala,一门通用用途、面向对象、函数式的JVM语言,是瑞士洛桑联邦理工大学教授Martin Odersky的心血结晶。本访谈系列由多部分组成。本文是第一部分,Martin Odersky与Artima网站的Bill Venners谈论了Scala的历史。
发现编译器的魅力
Bill Venners: 我们从头开始谈谈吧。你最早是如何开始涉猎编程语言的呢?
Martin Odersky: 编译器和编程语言一直都是我最喜欢的主题。我第一次钻研编译器是在1980年。那时我还是个本科生,想编写一个自己的编译器。 当时我唯一能远程用上的电脑是Sinclair ZX 80。它上面有1KB内存。我差点就在上面开始尝试了。但幸好我很快就得到更强大的机器Osborne-1。这是世界上第一款“便携式”计算机,远看就像一台倾斜90度的缝纫机。 它的屏幕五英寸大,每行只能显示52个小小的字符。但它亦有惊人之处。内存多达56KB,软盘驱动器有两个,每个容量90KB。
那些日子,我花了一些时间与另一个叫做Peter Sollich的同学呆在一起。我们学了一门新语言Modula-2。我们觉得它既优雅又精致。 于是我们诞生出了一个新计划:我们要为8位计算机Z80编写Modula-2编译器。编写时有个小问题,Osborene附带的唯一语言是微软的Basic语言。Basic语言完全不合乎我们设想,它甚至不支持带参数的例程——除了全局变量就别无所有了。而当时其他编译器对我们穷学生来说太贵了。 因此,我们决定采用经典的自举(bootstrapping)技术。 Peter用Z80汇编语言写了第一个编译器,支持Pascal的小部分语言子集。接着,我们使用这个编译器来编译一个稍大的语言。以此类推,在几次迭代后,我们终于可以编译完整的Modula-2代码了。它可以生成解释型字节码,以及Z80二进制文件。 它生成的字节码,在当年所有系统中,文件最小;它生成的二进制文件,在8位计算机中,速度最快。在当时,算得上能力很强的系统了。
在我们快完成编译器之时,Borland公司推出了Turbo Pascal,还在考虑进入Modula-2市场。事实上,Borland公司决定购买我们的Modula-2的编译器、命名为Turbo Modula-2再卖到CP/M,此外他们还想开发IBM PC版。 我们愿意为他们开发IBM PC版,但他们告诉我们,他们另有计划。 不幸的是,他们开发IBM PC版所费时间远超预期。 产品发布已经是三四年后。实现团队已经从公司分拆,成为了我们所知的TopSpeed Modula-2。由于缺了IBM PC版,Borland公司从未为Turbo-Modula-2提供营销资源, 所以它一直没什么名气。
我们完成Modula-2编译器之际,Borland公司立时就邀请我和Peter加入。Peter去了他们公司。我差点也去了。但我的问题是,我还有一年课程要读,还有硕士项目要做。那时我差点没忍住辍学的诱惑。 最后,我决定坚持上大学。 在我硕士项目期间(关于增量解析),我发现我挺喜欢科研的。所以最后,我放弃加入Borland编写编译器,转而攻读博士学位。我的导师是Pascal和Modula-2的发明者,苏黎世联邦理工学院的Niklaus Wirth。
改善Java的工作
Bill Venners: Scala是怎么诞生的?有什么历史吗?
Martin Odersky: 在我快要离开苏黎世时,大约1988年至1989年,我越来越喜欢函数式编程了。所以我继续科研之路,并最终成为德国卡尔斯鲁厄大学教授。 我最初工作更偏向编程的理论方面,比如call-by-need lambda演算. 这项工作与Phil Wadler共同完成。当时他在格拉斯哥大学。 有一天,Phil告诉我,他的组里有个热血助理听说一门新的语言刚出来,仍处于Alpha阶段,名叫Java。 助理向Phil宣告:“瞧瞧我大Java,它有移植性,有字节码,能运行在Web上,还有垃圾收集。这东西可以完爆你。你打算怎么办呢?”Phil说:“呃,可能他说得有点道理。”
答案是,我和Phil Wadler决定从函数式编程中提取一些点子,移植到Java界。 我们的努力转化成为一门名叫Pizza的语言,其中具备函数式编程的三大特性:泛型、高阶函数和模式匹配。Pizza首次发布于1996年,即Java推出后一年。Pizza还算成功,因为它表明,JVM平台上可以实现函数式语言特性。
接着,Sun核心开发团队的Gilad Bracha和David Stoutamire联系了我们。他们说:“我们对你已经做的泛型什么的东西还真挺感兴趣。我们来做个新项目专注这个功能吧。”这个新项目就成了GJ(Generic Java)。 因此,我们在1997/1998年开发了GJ。6年后,GJ再加上当时我们还没做的额外功能,就成为了Java 5中的泛型。那个没做的额外功能就是Java泛型的通配符功能,后来由Gilad Bracha和奥胡斯大学的人独立开发。
虽然我们的泛型扩展被搁置了6年,但Sun对我为GJ写的编译器产生了强烈的兴趣。有证据表明,GJ比他们的第一个Java编译器更稳定,更易于维护。 因此,他们决定,在2000年发布的Java 1.3版及以后版本的中,都采用GJ编译器作为标准javac编译器。
设计比Java更好的语言
Martin Odersky: 此刻,在Pizza和GJ的经验中,我常常感到沮丧,因为Java是一门具有硬性约束的语言。因此,我做很多事情时都不能用我本来想用的方式,不能用我确信正确的方式来做。毕竟那时候我的工作重点是改善Java。所以,在那段时期过去以后,我决定,我该退一步了。我想从一张白纸开始,看看我能不能设计出比Java更好的东西。但同时我又知道我不能完全从头开始。 我必须利用上现有的基础设施,不然的话,光是无中生有的自举,没有任何库,工具之类的东西,根本就不现实。
所以我决定,即使我想设计不同于Java的语言,总归得连接到Java的基础设施——即JVM和Java库。 我的想法就是这样。 当时我正有个大好机会,因为当时我在洛桑联邦理工学院做教授,这让我有了独立研究的良好环境。我可以组成一个小团体的研究人员,可以专心工作,不会因外部的赞助人而耗光我所有的时间。
起初我们相当激进。 我们想创造的东西,基于一种非常优美的并发模型,叫做join演算。我们创造了面向对象版的join演算,叫做Functional Nets,还创造了一门语言,叫做Funnel。过了一段时间,我们发现,Funnel语言的确非常纯粹,但却算不上很实用。 Funnel根植于非常小的内核。 人们认为理所当然应具备的功能(比如类、模式匹配)都必须要对内核编码才能提供。从学术角度看,这技术非常优雅。但实践中不大行得通。 初学者想要找出该怎么编码会相当困难,而专家却发现一次又一次重复编码又很无聊。
结果,我们决定再次重头做点事情,介于纯粹的学术语言Funnel,以及非常务实但受限重重的GJ之间。我们要创造的东西,将会既具有实用价值,又比Java中的先进。2002年时,我们开始开发这门新的语言。我们叫它Scala。首次公开发布于2003年。 2006年年初时有一次相对较大的重新设计。 此后它一直持续成长并逐渐稳定。
改善Java时所受的约束
Bill Venners: 你说,你需要与Java向后兼容,你受到重重约束,因而多次让你感到沮丧。你能否具体举些例子说说,有哪些事,戴着镣铐跳舞时无法做到,而只保证二进制兼容但无视源代码兼容时就可以做到?
Martin Odersky: 设计泛型时,我遇到许多非常非常紧的约束。最紧的约束,最难应付的,就是被迫要完全向后兼容无泛型Java。这个故事是这样的,Java1.2才刚刚加入集合库,Sun不想仅仅因为推出了泛型就另外新增一整套集合库。而不这么做,泛型就得以完全透明的方式实现。
这就是存在一些相当丑陋的东西的原因。 你不得不处处让无泛型类型和泛型类型一起工作,即所谓的raw类型。而且你还不能改变数组的行为不然就会碰上unchecked警告。最重要的是,处理数组时无法按你想要的方式来做,比如创建具有类型参数T的数组,或者创建你还不知道元素类型的数组。反正你就是没办法做。后来我们在Scala中确实找到了办法,但前提条件是我们让Scala的数组不再支持协变和逆变。
Bill Venners: 你能否阐述一下Java的协变数组有些什么问题吗?
Martin Odersky: Java发布初版时,Bill Joy、James Gosling以及Java团队的其他成员都觉得Java就该支持泛型,可惜他们没有时间好好设计。所以考虑到Java(至少初版)不支持泛型,他们觉得至少要让数组能支持协变。这就意味着,举例说吧,String数组就是Object数组的子类型。这么做的原因是,他们想要支持编写某种泛型排序方法,接受一个Object数组参数,以及一个比较器(comparator)参数,而该方法可以把Object数组排序。然后,允许你把String数组传入其中。总而言之,这类设计算得上一般意义上的类型错乱了。这就是你在Java中会遇到数组修改异常的罪魁祸首。实际上,也正是它导致泛型数组无法正常实现以及数组在Java泛型中根本没法用的原因。你不能声明字符串列表的数组,压根就做不到。你必须用丑陋的raw类型,只能永无止尽地使用列表的数组。因此,它有点像原罪。 他们做得很快,觉得这只是权宜之计。它实际上把未来的每一次设计决定全都毁了。 因此,为了不再次陷入同样的​​陷阱,我们不得不另寻他路。现在我们宣布,不会与Java向上兼容,有些事情,我们想要做得不同。

转自:知乎

作者:杨博
链接:https://www.zhihu.com/question/54160642/answer/138198226

著作权归作者所有。