从编程一开始，人们就会在一种语言与另一种语言的有效性和有用性之间进行辩论。开发者、管理者、博客们等等没完没了地反复争论为什么一种语言比另一种语言更好。让我们回到 2006 年 9 月，当时，广为人知创造了 Java 的 Sun Microsystems 摆出了一个明显的姿态，它将支持 JRuby 。消息源自于 Sun 宣布他们打算雇佣两个 JRuby 项目的主要开发者—— Charles Nutter 和 Thoams Enebo ，来全职开发 JRuby 项目。正如历史所证实的，Sun 支持这一项目的决定引发了一场新的辩论。
最近， Rick Hightower 在博文中写出了自己对 Sun 支持 JRuby 一事的感受，并请愿道，
Sun，请停止对 JRuby 的支持。这是浪费时间。把这些钱花在 Groovy 上吧，它兼容 Java 语法的。请在 Groovy 上进行语言进化并停止滥用 Java 语法。给我们提供像样的 Groovy IDE 工具。停止对 Java 这么频繁的胡搞。
Rick 就其对 Sun 的请愿提供了几条原因，包括语法方面的问题，
Sun 通过投资 JRuby 来投资 Ruby。咄！Groovy 看起来更象 Java。它更容易上手。其语法也不会让开发者感到厌烦。
除了语法，Rick 提出语言流行趋势也应被考虑，而且他还展示了一个图表以显示 Java 比 Ruby 更流行。
这是不要在 Ruby 上投巨资的另一个原因。提醒一下色盲：RUBY 排在最后！Ruby 排在最后。如果能发生一场革命的话早就应该发生了。Ruby 要终结这一可怜地位却又显得有些年迈了。你不这么认为吗？
Java 之所以流行是因为长得象 C++ 和 C。C++ 之所以流行是因为长得象 C。C#之所以流行是因为长得象 Java。看一下这个模式吧。让我们在 Gosling 的 领导下，增加一些对 Groovy 像样的支持（代码补全，重构等）。如果新的语言特性变为主流，那么就把它加入 Java（如果没有意义就算了）。
对 Rick 博客上的观点和建议，有相当多的议论。实际上，在他的这篇文章下跟有超过 50 个评论。
大多数评论者认为可以选择编程语言是一件好事情，
我认为我们应该可以选择，因此要求停止开发 JRuby 对我来说不公平。不要误解我，我也不喜欢 JRuby，而且现在我在用 Groovy，但是应该让 JRuby 和 Scala 活着，有得选总是好事。
Michael Galpin 发表了另一篇回应，站在了辩论的另一方。特别是，Michael 提供了一个理由，解释为什么投资 Scala 是一件值得做的事。
带有控制抽象功能的语言有巨大的潜能。Scala 就是这么一门语言。Scala 能够实现 actor 模型（一个不共享任何东西、基 于消息的并行计算设计）。这在 Java 里是不可能的。你也可以在 Groovy 中做到几分，但是它可能会很笨拙。原因很简单。如果你有一个对象调用了一个 method，而该 method 又调用了 closure（以此为例），在 Scala 中 closure 可以将控制返回给对象，但是在 Groovy 中只能返回 给方法。Groovy 中耦合了一些额外的控制结构，使得控制抽象的一些方面显得非常笨拙。
另一个博客作者， Ola Bini ，也不同意 Rick Hightower，他说道：
我认为 JRuby 是重要的，因为它可以在与 Java 一样的环境中运行，但是却没有 Java 的一些问题。
Ola 继续解释他认为存在于 Java 中的一些问题以及为什么 JRuby 是更好的选择。作为附加内容 Michael Galpin 解释了为什么 Sun 对 JRuby 有兴趣。
Sun 知道什么是成功引入一个新语言和平台以及使其成为工业实际标准的必要条件。这是很困难且昂贵的。他们只能做一次，这耗费了 他们大量资金。Java 不能总是停留在顶点。他们不想再为这一战役进行战斗了。然而，如果他们能够在上面所描述的场景下让 Rails 继续生存下去，那么他 们这次无需进行任何作战即可“停留在顶点”。他们让 Rails 社区为他们做到这一点。
Sun 除了站在 JRuby 一边之外，还发展 NetBeans IDE 支持 JRuby。然而，需要提及的是，Netbeans 正在积极发展对 Groovy 和 Grails 的支持。事实上， Martin Adamek 在其博客上提供了一个对NetBeans 的更新，它支持Groovy 和Grails。
那么，你作何感想呢，JVM 有容纳不同语言的空间吗？Sun 应该站在Groovy 一边并加大对它的开发和工具支持吗？
暂无签名
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
评论