综述:Scala 是 Java 未来的后继者

阅读数:11305 2009 年 7 月 19 日 08:04

作为 Java 未来的后继者之一,Scala 最近受到了大量关注。Groovy 的创始人 James Strachan 和 James Gosling、Charles Nutter 一样,是 Scala 的拥趸,后两人分别是 Java 的创造者和 JRuby 的核心开发者。

James 首先解释了他不喜欢的Java 特性

Java 是一个令人惊讶的复杂语言(规范有 600 页,但是有人的确对 Java 的特性心领神会了吗?),表现在它的自动装箱 (在这里隐藏了可爱的 NPE),原生类型,讨厌的数组(它们不是 collection,而且由于缺少多态性,对于通用数据结构和 bean 特性需要很冗繁的 语法,并且仍然没有闭包(即使在 JDK7 中),导致了大量令人烦躁的 try/catch/finally 的语句,除非你使用包含了全新自定义 API 的架 构,但是这样会导致语言更加复杂。Java 甚至有类型引用,不过我们还是不要使用它来存储任何typing/reading。

尤其是没有Java7 (即使在Snorcle 之后它显得更加有意义 - 我想知道javac 是否会被jdkc 取代?我猜javac 已经达到其巅峰;而且闭包看起来不会带来任何的简化或者进步),这个问题表现得更加严重。

他看起来已经被 Scala 深深影响了,尤其是当他说到如果那个时候有可用的Scala,那么他不会一开始就去发明Groovy

老实说,如果在 2003 年就有人给我介绍了 Martin Odersky Lex Spoon 和 Bill Venners 的 Programming in Scala ,那么我很可能不会创造 Groovy。

当然,也有一些 Scala 的特性他不是那么热衷:

对于任何一门语言来说,都有你喜欢和不喜欢的东西。Scala 给我的早期印象的确看起来它在尝试使用一点更多的符号,但是你不需要全部使用。如果你喜欢,你可以仍然使用 Java 风格的 OO。但是我想未来为“特殊物体”使用符号来避免和标识符冲突。

我不是嵌入 import 语句的狂热粉丝,使用 _root_.java.util.List 来区分从相对 import 中得到的“全局”import。我更喜欢子前缀,例如,如果你从 com.acme.cheese.model.Foo 导入,那么导入 model.impl.FooImpl 的时候,我喜欢使用一个相对前缀,也就是说,导入 _.impl.FooImpl 将会使事情简化,而且和 Scala 在 简化和删除冗余代码(导入 java.util._ 是多种类型的)保持一致。

任何时候和 Java 相比, James 都认为 Scala 好太多了

Java 的不足可以比作大量的毛疣,那么同样在 Scala 中,这些地方正是表现了 Scala 的美、简化和强大。

Adam Bien 在他的博客中指出,即使是Java 之父James Gosling,看起来也是对Scala 喜爱有加

在一个社区(java.net booth)举办的和 James Gosling 对话会议上,一个与会者问了一个非常有意思的问题:“除了 Java,现在你会把哪种语言运行于 JVM 之上?”。答案是惊人地快速简洁:Scala

Charles Nutter,JRuby 核心开发者,他也认为和Groovy 和JRuby 相比,Scala 更可能替代Java

我必须说 Scala 看起来是是现在 Java 王座的继承人。其他在 JVM 的语言看起来不可能有 Scala 那样的能力来取代 Java,Scala 背后的推动力是无可置疑的。Scala 还不是一个动态语言,但是它有许多流行动态语言的特性,例如它的灵活富类型系统,稀疏和简洁的 语法,函数式语言和面向对象范式的完美结合。Scala 的缺点:“太复杂”或者“太丰富”,但这些可以通过编码规范很好避免,从而构建更健壮的编辑器和工 具,以及指导多语言开发者明白如何更好地使用 Scala。Scala 是 JVM 上静态语言的重生,它也像 JRuby 那样延伸平台的性能,这些都是 Java 做 不到的。

Scala 现在已经是今年 JavaOne 的一个主题,有一些相关的议程,而且在大会的最后一天甚至会有一个开放的讨论

你怎么想呢?Scala 是不是在将来最合适取代 Java 的语言?或者, Java 是最后一门巨型语言(LBL)

查看英文原文: Roundup: Scala as the long term replacement for Java

收藏

评论

微博

用户头像
发表评论

注册/登录 InfoQ 发表评论