【51CTO精选译文】前日，Groovy创始人James Strachan在博客上撰文称Scala将成为Java的替代者。当时51CTO的译者对全文做出了翻译，并节选出其中一些精彩的回复放入了文中。事实上，几乎所有的评论都十分精彩，以至于我们决定对这些回复进行更加紧密的跟踪。
51CTO编辑推荐：Scala编程语言专题
原文入口：Groovy创始人：Java面临终结 Scala将取而代之（BlogSpot上的原文地址在此）。下面的评论中，我们对博主James的回复做了蓝色标注。
◆Alan said...
在用Scala开发程序的过程，最吸引我的一点就是简单的构建过程。它能非常智能地帮我解决Scala项目的依赖关系处理，编译，以及常见的Ant/Maven任务，而且不需要编写XML文件。
◆Justin Lee said...
我很想知道你对fandev.org上的东西是怎样的看法。它似乎提供了很多你期望在Scala里出现的功能（我不太懂Scala，所以我也没法准确地进行对比）。我用Java开发已经有很长的时间了，一直希望能找到其它更好用的语言，现在我觉得fan这种语言就是我要找的。不过从你对Scala的评价来看，显然Scala也可能是。所以，我想知道你是否了解过Fan。我并有没有要为Fan打广告或者说要说服你改变看法的意思。毫不隐瞒地说，我只是看看你的想法，因为你是一个语言天才，而我远远不是。
◆James Strachan said...
我也认为Fan是一门很棒的语言，尽管我有点担心它会变得既不像.Net又不像Java。它的静态和动态类型实现方式和Groovy里几乎一模一样。我本人还是更偏好静态类型实现一点，而且Scala里的泛型/运算符的重载都非常好用。
最后，相比于fan/groovy里生硬地加入对闭包的支持，Scala提供的对函数式编程和不变状态(immutable state)的支持看起来更适用一点。
◆Jeff Foster said...
我个人觉得根本就没有必要发明一种语言来取代JVM里的Java。像现在这样在一个虚拟机之上运行多种语言我觉得非常好（51CTO编者注：事实上，在哪种语言将统治多核时代 再看函数式语言特性一文中也有这样的看法，那就是多种语言并存的前景），不同的人各取所需。
您是否尝试过Clojure？它就需要大量的击键输入（因为它是动态类型的），但是宏和并行能力(因为它支持软件事务性内存（STM）的提供使得这门语言也非常吸引人。
◆R. Mark Volkmann said...
我看到作者作了不少这样的辩解：
“Scala给人的最初印象可能是符号用得太多了点，但是你并不需要使用所有的符号”。
我对这类说法非常不满，因为虽然你可能用不到所有的符号，但是你得阅读并理解别人的代码，那个人说不定就用到所有的符号了。
◆The Kaos Jester said...
我想以几个问题回应你：
0 ）既然我们会一直停留在Java 6，为什么我们还要这么急切地想挣脱Java呢？你先是嫌Java的语法标准太厚了，但接着又怪它没有什么新功能。为什么我们放弃Java？（51CTO编者注：Java EE 6的草案早在2007年初便已经提交，但是JavaOne 09都已经结束了，还是千呼万唤出不来。详情可参考51CTO之前的译文Java EE 6遥遥无期 预览版两极分化）
1 ）你怎么看待数组？我知道链表用起来是“很好”，但是数组这一数据结构并不仅仅是描述了数据的存储，它还提供了一个可在O(1)时间复杂度内访问的内存分布。如果采用链表，就根本没法保证这样的高效。这买卖划算吗？
2 ）Java里的泛型和C++里的模板差不多就是一个东西，只不过泛型在编译时没有类型推断。Scala也差不多，只不过有类型推断，但是程序员现在还根本没有办法控制它。比如，每次我要实现一个KD树时，我就通过扩展TreePoint来在变量T上实现泛型。其中TreePoint是一个提供了getVal(int axis)函数的接口。这样就让我得以构建一个泛型的空间树，而且它肯定能在任何实现了TreePoint的类下工作。如果我想用Scala构建这样的数据结构的话怎样才能办得到呢？是不是我得TreePoint变成一个对象，并通过其它对象来扩展它？Scala甚至连继承都不支持吧？还有接口呢？（有关Scala泛型的优势，51CTO曾致信Scala创始人Martin Odersky，他曾比较详细的解释过。详情可点击这里）
3 ）您称赞Scala说它更优雅。我觉得有必要展示一下。
这是用Java编写的打印偶数的程序。
- even(int max) {
- for(int i = 0; i < max; i++) {
- if (i % 2 == 0) System.out.print(i + " ");
- }
- }
这是用Scala写的：
- def even(to: Int): List[Int] =
- for (i <- List.range(0, to) if i % 2 == 0) yield i
- Console.println(even(0, 20))
这样的写法对我来讲是件痛苦的事情。另外，Scala写的示例程序让人觉得代码结构不太清晰。这样非标准的for循环如何能有助于代码的复杂性和简洁性？它对编写代码有什么好处？
4 ）由于它是一个脚本语言，行尾不使用' ; ' ，而是使用' \n'作为结束符，这再一次给我们带来麻烦。我也知道Ruby，Python这些语言都很酷，因为它们都不需要你写行结束符，但是难道你不觉得这样很容易让人迷惑吗？事实上，我认为这会让Scala程序员非常苦恼，因为连下面这样的写法都是合法的：
- val t = a(i); a(i) = a(j); a(j) = t
5 ）你首先就拿Java语法手册有600多页说事，后面又说Scala有多少扩展库可以实现类似功能。但是，Java语法手册这么长的原因本来就是因为官方为保证各个Java版本的一致性而集成了大量库。试问Scala又是如何保证这些后来加进来的库的一致性呢？
6 ）你说Java的基本类型很是让人不爽。我不知道你为什么会有这种感觉，Scala又采取了什么措施来解决这一问题呢？
7 ）我想你肯定知道JavaScript不能用来开发桌面应用程序，对不对？同样的道理，也不会有哪种语言可以替代Java，Python，Ruby等。
8 ）Java里有一点和字符串相关的多态性值得一提：Java里的所有对象都提供了一个toString方法，并且所有你自己编写的对象都可以自定义toString方法（只要在类里面定义这个方法并在方法前加上"@Override")。所以，你可以让Java完全按照你的所想去打印任何对象。试问在Scala里怎样才能实现这一功能呢？
以上只是我个人的一些愚见。Scala看起来还是挺强大的（不过我仍然会首选Java和Scheme），但是似乎你所抱怨的Java中的这些问题也同样存在于Scala中，并没有得到什么改善。我们仍然在使用虚拟机，它带有虚拟机内存，字节码在运行时才编译，它还带有可变类型。这篇文章并不是要招来口水战，但是我读了你的这篇文章之后确实产生了一系列的疑问。
◆James Strachan said...
0 ）javac的过期时间已经步步逼近。难道我们不该投奔另一种更好的语言吗？你可以选择继续死守。这一点都不奇怪，直到现在还有人在用COBOL呢。
1 ）数组不是Collection，它们没有实现 Iterbale < T>。（Scala里的FWIW链表和数组支持迭代和自然数索引操作，例如myArray(5) ）
2 ）我不确定我可以100%做到这点，但是我想可能值得去读读Scala里如何支持这种抽象类型。
3 ）我不太认同你所说的。这一段Scala代码定义了一段随时都可以方便地结束的代码，而在Java里必须得进行迭代。你不光是拿苹果和桔子在进行比较。你还把Scala 的for语句的好多强大功能给忽视掉了。
http://www.scala-lang.org/node/111
这可避免大量丑陋的嵌套循环。
4 ）Scala和Javac一样严格，当然，我也一样喜欢像JavaScript、Ruby、Groovy那样的宽松语法。
5 ）Scala是一门简单却又非常强大的语言。优雅设计的诀窍就是如何尽可能地进行化简却依然保持原有的功能。
6 ）比如说，在Java中有那么多的与基本类型、自动封装以及数组相关的麻烦。
7 ）JavaScript和Java/Ruby之间根本就没有什么可比性。你还可以用Rhino在JVM里完成大部分任务呢。
8 ）Scala里，一切都是对象。
总之，我非常喜欢JVM以及它的平台和无数扩展库。我只是在为javac作长远打算，而且我觉得Scala是一个巨大的进步。
◆James Strachan said...
@The Kaos Jester
我想顺便再强调下希望你能看看我在文章里提到的两本Scala编程书。不要心怀芥蒂。
Scala很好地解决了Java里的大部分问题（我看了这些Scala编程书之后才想起来Java有这么多不尽如人意的地方），而且它能让我们大开眼界，看到如何漂亮地把面向对象编程和函数式编程统一起来。
因此，Scala不仅仅是比Java更好，它完全就是面向对象语言和函数式语言的结合体，而且还有比Java更简洁优雅的语法，它所编译成的字节码运行效率也和Java不相上下（有时候要相对快一点，有时候要慢一点）。
◆Cedric said...
对不起James，但我真的不认为Java社区已经对Scala 这样复杂的东西做好了准备。因为它确实是复杂的，不管你是不是这样认为。此外，我认为像你自己这样的语法设计者有时候太渊博了，所作的判断也和我们普通人不太一样（你不是把“单体”(monad)单独列出来吗？想想这个问题吧。）
很多时候，我都觉得Scala之于Java就像C++之于C。有着丰富的功能，并且也辩称“你不必掌握所有这些功能”，但到了实际开发中，往往加大了工程的复杂程度。你可以去看看我在Scala每日邮件列表里发的代码片段，我想说的是：它比Java的泛型复杂10倍。
和你一样，我也经常对Java的哆嗦感到恼火，不过如果我想在Java里达到类型推断和静态类型的话，我就可以折中地写成"List< String> l = Lists.newArrayList()",这样就能基本上实现类型推断。
我敢打赌，在五年内，Java将依然是最主要的JVM语言，但还是会有一帮人在提倡Scala是一个更好的替代。
纯粹从设计角度看，Fan更容易吸引Java社区的开发人员加入，因为它不像Scala那样需要跨过那么复杂的门槛。但是 1）.NET兼容性问题让我担心这语言会不会被削弱。 2）我怀疑Andy和Frank没有在他们的IDE上做足够的努力。
◆Tom Flaherty said...
难得的好文章！在我最近所作的演示中我就暗示过一个类似的观点，就是说Scala未来可能会取代Java。我的主要依据是强类型是实现一个稳定基础系统的关键，而其它弱类型动态语言也只有在这个稳定的基础系统上才能实现。而根据目前所知，Scala简直无所不能。我真得感谢你的深入分析和你推荐的资料。
【相关阅读】
