JRuby团队成员质疑IronRuby

作者 Werner Schuster 译者 Jason Lai 发布于 2007年6月17日 下午7时30分

社区

.NET,

Ruby

主题

JRuby,

动态语言,

脚本

标签

IronRuby,

CLR,

RSpec,

JRuby,

DLR

在微软宣布了.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

• 更早的 >