Groovy创始人:Java好日子到头了,Scala将取而代之2
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开发得更强大了（注：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确定有些不太一样，并且需要你经历一个学习曲线）
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开发得更强大了（注：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确定有些不太一样，并且需要你经历一个学习曲线）
还没人转发这篇日记
