Groovy创始人：Java面临终结 Scala将取而代之
转载▼Groovy创始人James Strachan前日在其博客（地址在Blogspot，未架好梯子前请勿随便点击）上发表了一篇文章，题目为《Scala将取代Java /javac？》。如下是正文部分的翻译：html
【51CTO独家译文】不要误解个人意思——我在过去的这十来年里写了无数的Java代码，而且坚信它相对C++和Smalltalk来讲是一个巨大的进步（固然，不少其它语言也颇有帮助，像JavaScript，Ruby，Groovy，Python等）。可是我仍是一直期待着能有javac的替代者出现。我甚至还自创了一门语言（51CTO编者注：此处指Groovy）好让我暂时知足一下这种指望。 java
Java是一种使人惊叹的复杂语言（它的语法规范长达600页，我怀疑到底有没有人能真正理解它），它有自动装箱(Autoboxing)，空指针异常(NPE)每每就是这时抛出的。其中的基本类型(primitive type)，字符串/文字/缓冲器/集合类(collections)以及数组缺少多态性，以致于处理任何数据结构都须要冗长的语法；并且，因为Bean属性和对闭包支持的缺失（甚至在JDK 7里也仍然还不支持），这会让你的代码里充满了 try/catch/finally 这些语句（除非你使用框架和新的自定义API）。除了这些还有好多数不清的麻烦问题。Java却是有类型推断(type inference)功能但却不用，使得咱们要多输/读如此大量的代码。node
这个问题在没有Java7后变得更加紧迫 （在Snorcle以后它变得更加剧要：我不知道javac是否是要被jdkc 取而代之了？）。因此我猜javac可能已经走到了尽头，它看起来根本就没有什么进展或简化了。 程序员
那么，从长久来看，谁能取代javac 呢？固然，像Ruby，Groovy，Python，还有JavaScript这些动态语言在过去几年里很受欢迎——不少人喜欢他们。 web
我认为未来可能替代javac的就是Scala 。它实在太让我印象深入了。我甚至能够诚实地说，若是有人在2003年把Martin Odersky，Lex Spoon以及Bill Venners写的那本《Programming in Scala》拿给我看了的话，那我根本就不会再去发明Groovy了。 shell
那么，为何我会看好Scala呢？Scala是静态类型的，它能够被编译成与Java一样快速的字节码，因此它的速度与Java不分上下（有时快一点，有时慢一点）。你能够看看 Scala 在与 groovy 或jruby一块儿进行测试时表现有多好。注意：速度并非咱们追求的惟一目标——有时候咱们可能宁可让代码慢上十倍，也要写得简洁一点；可是若是要取代javac，速度固然仍是很重要的。 apache
Scala已有类型推理(type inference)功能，所以它和Ruby/Groovy同样简洁，可是它彻底是静态类型的。这是颇有好处的，它使得理解代码、阅读代码以及编写文档都简单多了。在任何片断(token)/方法/符号上点击，你均可以跳转到相应的代码或文档中去浏览。不须要打那些怪异的补丁，也不用操心谁何时新增了一个方法——这对于那些须要一个团队一块儿长期开发的大项目是颇有好处的。Scala彷佛已经实现了动态语言(dynamic language)的那种简洁，而实际上它是彻底静态类型的。因此，我根本不须要去记哪些魔术方法可用——或是在shell里运行脚原本查看这些对象——IDE/编译器在你编辑代码时就已经知道这些了。 编程
Scala已经提供了对高阶函数和闭包的支持，另外还支持序列解析（sequence comprehensions) ，这样你就能够很容易用Scala写出漂亮简洁的代码。Scala还把函数式和面向对象的编程思想很好地统一到了一种语言里，它比Java要明显简单一些（虽然它的类型体系(type system)和泛型(generics)须要花费差不一样一个数量级的时间去理解，可是，它一般是框架开发者才须要考虑的问题，应用程序开发人员并不须要涉及）。它也使得从传统的面向对象/Java编程模式向函数式编程的转变变得更加容易——这对于编写并行或异步程序的开发人员尤为意义重大（这是由于如今芯片的主频已经达到了数个GHz，很难再有提高了；而芯片集成的核心数则在快速增加。51CTO以前曾发布过哪一种语言将统治多核时代再看函数式语言特性一文，对于函数式语言在多核时代的潜力作了至关深刻的分析）。你能够在最开始用面向对象的方法编程，而后当你须要它的好处时，就能够迁移到用不变状态(immutable state)函数式编程正变得愈来愈重要，由于咱们老是但愿能把问题变简单，而且在一个更高的层次上解决它（如闭包，高阶函数，模式匹配，单子(monad)等），同时咱们还须要经过不变状态(immutable state)实现并发和异步。 数组
Scala也有适当的混入(mixin)（特性(trait)），因此你没必要去摆弄面向对象编程的缺陷来得到模块化的代码。若是你确实须要一些鸭子类型(duck typing)，Scala甚至能为你提供构造类型(structural type)。 安全
最让我印象深入的一点就是它的核心语法极其精练简洁（它的语法手册只有大概Java的四分之一），可是其方式却更增强大和灵活，并且很是容易经过库来扩展，添加新的语义和功能。能够看看这个例子：Scala Actors。所以它很是适合用于建立嵌入式DSL或外部DSL 。有了它之后就真不必再用Java，XPath ，XSLT，XQuery，JSP，JSTL，EL和SQL这些东西了——你能够在各类各样的场合使用DSL。
Scala确实须要花点时间去习惯——我认可第一次我看Scala时并不以为顺眼——用了Java以后你就会习惯用一堆冗长的代码来作一点点事，刚开始时咱们也都不会一看到几个符号就以为有多惊讶。（我花了好长一段时间才习惯Scala里用_做“通配符”，由于在Scala里是用做标识符/方法）。
若是你一直在写Java，那么最开始确实会以为Scala很不同（如在声明方法/变量/参数时在类型或标识符上加上阶，虽然那样作的缘由是为了能更方便地略去一多余的类型信息）。
例如，在Java中的写法：
- List< String> list = new ArrayList< String>()
在Scala中的写法：
- val list = new List[String]
或者，若是你要指定确切的类型的话：
- val list : List[String] = new List[String]
可是若是你坚持用上一段时间，Scala优美的一在很快就显现出来。它对Java里的许多地方进行了简化，让你能够用很是简洁的代码就描述出意图，而不用花上大段代码去实现细节——同时还为你提供了一条迁移到函数式编程的不错途径，这对于编写并发和分布式程序是很是有利的。
我强烈建议你学习一下Scala：以开放的心态看看（当你的思惟转过来后）你是否能发现它的美丽之处。
一些Scala资料的连接和在线演示文档
51CTO编辑推荐：Scala编程语言专题
◆我强烈推荐由 Martin Odersky，Lex Spoon 和 Bill Venners编写的《Programming in Scala》一书。它很是好地介绍了Scala的特色以及设计时的选择。这本书至关厚，可是你能够先跳着读，必要时再深刻细节。
◆《O'Reilly Scala book》这本书我只跳着读了一点，可是看起来也很是不错。
◆若是你想在短期内就知道个大概语法，那么能够看看《Tour of Scala》。不过看了以后你也还得花上一些时间来真正理解为何它跟Java会有这样那样的不一样。
◆Martin Odersky 的JavaOne 2008上关于Scala的演说
◆Jonas Bonér在 Real-World Scala上做的报告
◆Gert's的 对他如何建立 Apache Camel DSL for Scala 的介绍
◆用于JDBC类型安全查询的一个Scala版LINQ，顺便再了解下DBC。
◆一份很是不错的报告，介绍了把 Scala 和 OSGi 与DSL结合使用
◆如何使用 Scala和XML （语言里已经自带了处理XML，XPath ， XSLT， XQuery的简洁语法）
◆这个例子显示了如何 建立的bean风格的属性 （或C ＃风格的getter函数）
◆建立一个 用Lift实现的聊天演示程序 或查看 Lift网站上的更详细介绍
若是你还有一些空余时间的话，这些视频资料也很是不错
◆Bill Venners所发表的The Feel of Scala
◆Lex Spoon所做的Scala: 把将来的语言带到JVM里来
好用的Scala框架和库
◆liftweb ：Scala的rails
◆语言规范和ScalaTest for BDD 以及其它一些入门测试(literate testing)能让你体会到类型安全的DSL对于编写IDE友好 的简洁代码有多大帮助。
◆scalaz 是一个颇有用的例程库。
另外，顺便说一下，对于那些像我同样一喜欢JAXRS的，如今能够经过jersey-lift模块使用lift模板和Jersey了。
做为这的实例，你能够看看RestMQ，这是一个我最近也参与了的开源项目，它旨在为面向消息的中间件提供REST风格的API和Web控制台，它也是基于JAXRS（Jersey），Scala，Lift构建的。
至于开发工具方面，有Ant/Maven插件，它带有一个交互式Scala控制台（REPL）和一个用于IDEA的IDE插件，还有Eclipse，NetBeans，以及TextMate，Emacs这些通用编辑器，均可以供你选择。在IDE插件的丰富程度上与Java仍是有差距的，可是这些工具所提供的代码导航和自动补全功能仍是颇有用的。
我试用过NetBeans，Eclipse和IDEA这几个IDE上的插件，它们都各有优劣。看起来，Scala的追随者也由于这些工具分裂成了几派。若是要代码导航和自动补全，那我发现IDEA很是不错。当你打开一个Maven pom.xml，它好像就能很是好地自动解析代码，找出Scala源，那样你就能很方便地在任意的类型/方法以及它们对应的文档/源代码中跳转浏览。（一般你必须在运行/调试任务里手动添加Scala）。不过IDEA在错误代码高亮上并非最好的。在做上一些弥补后，它们都能变得与对应的Java工具同样好用。试试这几个工具吧，找出你最习惯的那个。
Scala Nit
任何一种语言都有你喜欢的一面，也有你不是那么热衷的一面。Scala给你的最初印象可能确实是符号太多了点，可是你并不须要使用全部的这些符号——若是你喜欢的话，你能够继续沿用不少Java里的东西。但我想到了那个时候最好仍是用符号来实现“特殊任务”以免标识符冲突。
我对嵌套的引入声明不太感冒，使用_root_.java.util..List来把一个”全局“引入和相对引入区别开来。我还更愿意使用子引入。例如，若是你引入了com.acme.cheese.model.Foo，而后，为了引入model.impl.FooImpl，我就更喜欢用一个明确的相对前缀，就像：import _.impl.FooImpl。这对简化任务有一些好处，对于保持和Scala的简洁性就更有帮助了。
然而，和Java里大把的毛病相比，再考虑到Scala的优美，简洁和强大，Scala的这一些负面因素和根本不算什么了。
结语：
既然 MrJava（Adam Bien），MrJRuby（Charles Nutter） 和 MrGroovy（做者本人）都认为Scala将会是javac的的替代者，那确定是有些缘由的。那你还在等什么呢？赶快去买《Programming in Scala》或 《O'Reilly Scala book》一探究竟吧！
这篇博文发布后，马上有不少Scala，Groovy和Java开发者进行了回复。Scala的创始人Martin Odersky也对这篇文章发表了本身的赞扬之词。如下是Martin的留言：
James，感谢你的承认！这对我来讲意义重大。我相信，若是咱们一块儿努力向Java开发者们展现如今在JVM上更加美好的语言选择，咱们你们都会所以而获得好处。感谢你在这方面带了个好头。
根据我对Groovy的了解（很惋惜的，个人了解没有你了解Scala那样多），它看起来并不是是意图填补同一块领域的。Groovy的吸引力在于它是一个语法接近Java的动态脚本语言。Scala的吸引力在于它是一个强类型的，静态的，结合函数式和面向对象的语言。
此外还有不少精彩的评论，51CTO译者对这些评论进行了一些筛选，挑出部分翻译以下：
Scala的体验
去年，我在作一些调查项目时把Scala引进到了个人小Java车间里。
现在Scala成为了咱们最主要的编程语言。
经过使用Scala，咱们如今能够构建类型系统(type system)，跟踪总结之前所作项目的经验教训，并用它来替代咱们过去以模型为导向(model-driven)的开发方式。而后，咱们利用函数分发(pass around functions)的特性来改进组件的参数化。
总之，对于创建可重用的组件，Scala提供了一套比Java更好的机制。
C#和Java？
我以为你能够去看看C#。它解决了你在Java中遇到的许多问题。若是你不喜欢微软的话，就能够试试.NET的开源替代版本Mono。
有关Scala和F#
其实，在.NET平台里与Scala对应的语言并非C#，而是F#。无论何时，我都更倾向于使用Scala，而不是F#，缘由以下：
1 ）在F#文化里，面向对象看起来并不重要。在全部讲F#的书里，都一定有一章介绍类，而后，剩余部分就是专门讲解函数式。相比之下，Odersky在发明Scala时，并无照搬Java的这一套机制，而是经过对象类型、特性(trait）、加强的可见性规则(visibility rule)等概念扩展并超过了Java的这一套机制。Scala使得像我这样有根深蒂固面向对象思想的开发人员以为很温馨，它提供的函数式语法特性让我能够用来把代码变得很是简洁。
2 ）F#比Scala看起来更接近人类语言，初看起来这彷佛是好事。不幸的是，因为开发者不多须要写类型说明(type annotation)，大部分代码里也都没写，这就使得代码变得更加难于理解。在Scala里，至少要声明参数类型，并且最好也声明一个方法的返回类型，除了那些一目了然的状况。
3 ）F#一直力求尽可能往OCAML的语法靠拢，因此它在语法也真是没有什么创新之处。而Scala则是博取众长，吸纳了各类语言的优势。此外，它还让人感受有些机制并非必须的，而是为了让开发者更好地表达意图而加入的。经过加入隐式转换(implicit conversion)，析取器(extractor)这些功能，Martin从我这里获得了很大的帮助。
4 ）在我看来，Java程序员学会Scala比从C#到F#的过渡要容易得多。大致上来讲，缘由是Java程序员不须要花很大的代价入门，Scala能够直接被看成一门少了些模板(boilerplate)的Java使用。当程序员渐渐熟练后，他就能够开始发掘函数式编程的威力了。在其它任何的面向对象/函数式编程语言里我都找不出能够这样过渡学习的。
Groovy盖棺定论了？
James，我一直在留意你的博客，这篇文章写得棒极了，堪称高超。你发过一份声明说不会再继续把Groovy开发得更强大了（51CTO编者注：James Strachan在写这篇博文以前好久已经离开了Groovy开发团队），这份声明影响力很大，并且几乎能够说是给Groovy盖棺定论了。
咱们有一个面向最终用户的数据处理软件，而后咱们选择的是Groovy （而没用Jython和JRuby ）来做为实现各类功能扩展（从对变量编写公式到编写脚本）的途径。大家在开发Groovy所写的代码不少都是粘合代码(glue code)(对核心语言起补充做用）。咱们充分利用Groovy所支持的这些特性与MS Office产品和Web服务进行整合。我真的但愿，若是大家的开发团队更中意Scala的话，也请尽可能让咱们到时候在Scala里也能用上这些有用的库。
James Strachan对上文的回复
我不认为任何一种主要的JVM语言会消失，确定会一直有一大帮人继续维护Groovy, Jruby, Cojure, Jython, Rhino等。
JVM中最大的一点好处就是这些语言很容易共存，重用另外一种语言的代码也很是容易。所以，只要相信大众的选择，就不用担忧会选错开发语言。
并且我也并不认为Scala会是Ruby/Groovy/Fan这些动态语言的替代者；大多数状况下性能仍是很重要的。对于一个快速、静态类型的编译器来讲，过去Java显然是第一选择——可是如今，Scala才是首选——这是由于Java已经显出老态了。（它可能永远也不会支持闭包，永远也不会考虑支持类型推断等新特性）。
自从发现了类型推断的威力以后，我实际上愈来愈以为动态类型(就是很简洁的代码实现功能）的动机变得愈来愈难以琢磨了。好比说，你能够用Scala写一些脚本，它就会像Ruby/Groovy同样进入”读取-执行-打印循环“(Read-Evaluate-Print Loop, REPL)。
可是我发这篇文章的目的并非要挑起Scala拥护者和Ruby/Grovy/Clojure/JavaScript这些动态语言支持者之间的战争——我只是想让被Java一叶障目的开发者们意识到，这个世上已经有了比Java更好的静态类型语言：这门语言有他们所想要的所有功能（还附带有Java最须要加强的功能）。全部这一切，都能在这门语言里用简洁、优美的代码表示出来（尽管这门语言和Java肯定有些不太同样，而且须要你经历一个学习曲线）。
附录：有关Scala编程语言的其余言论
◆Java的不足能够比做大量的毛疣，那么一样在Scala中，这些地方正是表现了Scala的美、简化和强大。——James Strachan
◆在一个社区（java.net booth）举办的和James Gosling对话会议上，一个与会者问了一个很是有意思的问题：“除了Java，如今你会把哪一种语言运行于JVM之上？”。答案是惊人地快速简洁：Scala。——Java之父James Gosling
◆我必须说Scala看起来是是如今Java王座的继承人。其余在JVM的语言看起来不可能有Scala那样的能力来取代Java，Scala背后的推进力是不容置疑的。Scala还不是一个动态语言，可是它有许多流行动态语言的特性，例如它的灵活富类型系统，稀疏和简洁的语法，函数式语言和面向对象范式的完美结合。Scala的缺点：“太复杂”或者“太丰富”，但这些能够经过编码规范很好避免，从而构建更健壮的编辑器和工具，以及指导多语言开发者明白如何更好地使用Scala。Scala是JVM上静态语言的重生，它也像JRuby那样延伸平台的性能，这些都是Java作不到的。——JRuby核心开发者Charles Nutter
原文：Impression on Scala 做者：Ricky
编者后记：开发者对于语言的喜爱在某种程度上和开发者的性格有很大关系，正如敏捷大师Dave Thomas所说的，就好像喜欢猫的每每不喜欢狗，喜欢狗的每每不喜欢猫同样。而不知是否巧合，一样是Ruby狂热爱好者的Dave Thomas也曾在访谈中表示本身就是毫无理由的不喜欢Scala，对Scala的一些用法感到困惑。这样看来就仿佛Ruby是只猫而Scala是只狗同样。固然也有反例，好比这位从Ruby出家到Scala的程序员，以及曾经一直使用Ruby作后台的Twitter后来投向了Scala，而其团队并无像上面两位那样表示困惑。看来开发者对语言的喜爱真是一个难以琢磨的话题呢。