JRuby团队成员质疑IronRuby-InfoQ

在微软宣布了.NET 平台的 Ruby 实现IronRuby之后，Ruby 社区开始舌战不断。JRuby 团队的成员 Ola Bini 炮轰 IronRuby，对项目的可行性表示怀疑态度。他的主张源于 IronRuby 背后的一个至关紧要的问题：根据推测，由于版权或者许可证问题，该项目的开发人员不能查看 Ruby 的源代码。另外一个问题就是微软拒绝来自外部的代码贡献。 Ola 解释说：

恕我斗胆直言，在目前的情况下，我不相信 John Lam 和他的团队有可能在 18 个月内完成一个可以运行 Rails 的 Ruby 实现。老实说，这么长时间是不短的。就像我在上面所说的，我完全有信心说，如果 John 有合适的资源，那么他肯定可以拿出漂亮东西出来。但是，尽管有开源社区带来的所有好处，创建一个 Ruby 实现也是够难的了。

Ola 给出了一个解决方案，即专注于加速完整的Ruby 规范的制定工作：

就这一点我想提出两点：Ruby 社区必须认真开始对待创建出一份良好且完整的规范和测试套件这件事情了。现在我们就该着手进行此事了，我们需要它。这不是一个人的战斗，整个社区都需要参与到当中来。（没错，那两个 SoC 项目是一个非常良好的开端。但你仍然需要能够运行 RSpec 才能充分利用他们；让我们去面对这件事情吧，RSpec 实现使用了许多非常精巧的 Ruby 技巧。）

在规范上所做的努力很早就已经开始了：

Google SoC 项目支持了两名学生参与规范的RSpec测试（ InfoQ 在最近发布过一篇特稿，采访了其中一名学生）
JRuby 的 Charles O. Nutter 在很早之前就创建了 Ruby 语言规范的 Wiki
Rubinius项目也在专注于创建许多 RSpec 测试，来检查兼容性，而且他们也和 JRuby 团队合作从事测试。

尽管看起来 Ola 相信，只要 Ruby 的规范可以详细地制定出来，那么 IronRuby 就可以成为一个完整且符合标准的 Ruby 实现，但是 Charles O. Nutter 就显得悲观得多了：

在熬过了 Ruby 夹道相讽的日子，以及在一手把 JRuby 从什么都运行不了，缔造成一个现在几乎可以 100% 完美运行 Rails 的 Ruby 实现之后，我可以很有信心地说，除非人们可以参照已有的 Ruby 实现，否则在只有目前的规范和测试的情况下，任何人都不可能从零开始创建出一个可以运行 Rails 的 Ruby 实现。说实话，我真的不相信有这种可能。

同时 Charles 也怀疑微软这边缺乏决断力：

这是我一个好朋友的观点，但他说服我相信了他的观点：我们不相信微软会愿意允许 IronRuby 走到支持 Rails 那一步，因为这样的话会直接和他们的 ASP.NET 服务器、软件还有相应工具套件产生竞争关系。对于他们来说，究竟一个运行着免费框架能给他们带来什么好处呢？基本上是没有。

这话从参与 JRuby 项目的 Sun 雇员嘴里说出来，还真是令人大跌眼镜（退一步说）。Sun 聘用了两名全职开发人员从事 JRuby 的开发，另外还雇用两名开发人员从事 Netbeans Ruby 工具的开发。然而，Sun 在这个项目上的投资，不会导致一个钢蹦儿直接流进自己的腰包，因为 JRuby 是一个独立的项目（它 _ 不是 _ 一个 Sun 专属的项目），而且 Netbeans 的工具也是分文不取的。事实上，如果使用 Charles 的理由，那么 Sun 也不会希望 JRuby 可以运行 Rails，因为使用 JRuby on Rails 的开发人员不会使用 JSP、JSF 或者其它的 Java 技术。因此，除非开发人员或者公司在 Sun 的硬件上使用 JRuby on Rails 或者使用 Sun 的软件支持服务，来使其在 Sun 的软件上运行，Sun 在这个努力上面一分钱也捞不回来。因此，按照 Charles 的逻辑，不可能存在四个 Ruby 运行时，以及领着相应工资的开发人员，而事实上，他们还是存在着。

这条逻辑存在的另一个漏洞，就是每个在.NET 上使用 Rails 的开发人员都会从 ASP.NET 平台转出来，而这样会导致微软利润上的损失。但这未必是真的。让一个成熟的 ASP.NET 团队转向不同的语言和框架会带来重新培训的开销。转向 Rails 能带来的好处，对于允许其发生的特定项目来说，一定是相当可观的。同样也存在这样一个问题：当.NET 开发人员可以从来自微软的多种技术进行选择的时候，是否他们所有人都能看见 Rails 带来的效益呢？.NET 开发人员 Aaron Erickson 阐述了他此时对微软平台的感受：

在基于微软的平台上度过了 14 年的美好开发时光，我一直都以自称微软平台的开发人员而感到自豪。来自 Anders Hejlsberg 和 C#团队的创造，更不用说随着 DLR 和 Silverlight 一起问世的东西，堪称这些年来这个领域内最优秀的一部分创新。

如果有更多的.NET 开发人员这么想，并且他们对微软提供的技术和工具支持感到完全满意，那么从.NET 工具向 Ruby 的大举迁移是不太可能发生的。

这群打算扔掉他们的工具并转移到 Rails 上的开发人员，在 Java 平台上也做了同样的事情，他们丢掉了 Struts、JSF 和 Co，转而使用了 Rails。这是一群对以前解决问题的旧方式不满的开发人员，或者 Web 领域初来乍到，对旧方式不习惯的开发人员。

在.NET 上存在完整的 Rails 版本，会确保对 Rails 感兴趣的开发人员还能留守在.NET 和微软的软件方案上，并且保留他们（在 Windows、IIS 和 Visual Studio 等）原有的大部分经验。如果 Rails 不可用，那么这群人就可能逐渐离开，并且转向非微软的 Ruby 方案，比如说可能转向另外一个操作系统和 Web 服务器上的 JRuby on Rails。有了完整的 Rails 实现，微软可以将开发人员留在.NET/ 微软的软件方案上，而且，如果有良好的工具支持，那就可能吸引更多的人。这就为微软带来了直接效益：使用 Windows 和微软服务器软件及工具的公司将为此支付许可证费用，更不用说签署支持合同或者支付培训课程的费用了。在 IDE 支持方面， Ruby in Steel 更是在 Visual Studio 中文为 Ruby 和 Rails 提供了艺术级的支持。

总的想法就是，让.NET 在更多人面前变得更有吸引力，可以保持并可能吸引更多的付费客户，而不会损害到其它产品的销售。

Charles 并不相信 IronRuby 有什么机遇，他提到另外一种将 Ruby 引入.NET 平台的方式：

由于这些事实和目前的现状，我得说，作为一个社区，我们更应当把眼光投向 Gardens Point 的 Ruby.NET 编译器项目上去，这个项目早已比 IronRuby 发展得更为成熟 [……] 此外，这个项目是真正开源的（你可以贡献代码），而且他们的开发人员可以查看 Ruby 的源码（并且他们已经承认至少在解析器上是这么做了）。去年我还对 Ruby.NET 持谨慎和怀疑态度，但现在看来他们是 Ruby 在 CLR 上最大的希望了。

Gardens Point 的 Ruby.NET 编译器是一个活跃的项目，这个项目的目标是创建一个把 Ruby 转换成.NET 字节码的编译器，它包含一个 Ruby 或者 JRuby 命令行版本行为相似的可执行文件，但并不解释 Ruby 的抽象语法树（Abstract Syntax Tree，AST），而是在 Ruby 代码运行之前将其编译成 MSIL（CLR 上用到的指令集）。

像这样的争论使得 IronRuby 的第一个发布版本变得越来越有趣了。IronRuby 的开发人员 John Lam最近提到， IronRuby 的第一个面向公众的发布版本将在 2007 年 7 月 23 日至 27 日间 O’Reilly 的 OSCON 大会上公布。

查看英文原文： JRuby Team members doubtful about IronRuby