Ruby.NET前途未卜

过去的两年里，在可选Ruby实现方面进展很大：在官方MRI及后续的Ruby 1.9之后，许多其他Ruby实现的项目被启动：基于JVM的JRuby和XRuby、.NET平台的Ruby.NET和IronRuby以及一个自托管的虚拟机Rubinius。

现在看来一些合并已经发生了：XRuby的开发已经慢了下来——因为JRuby更大的动力和更广泛的使用，还因为它不能够像JRuby的扩展那样在Java中支持原生Ruby函数（例如：OpenSSL、Oniguruma正则表达式引擎等等）。

Ruby.NET的维护者Wayne Kelly博士现在看来已经在Ruby.NET和IronRuby之间做出了个人的决定。他在Ruby.NET的邮件列表中宣布：

\u0026#xD;\n

\u0026#xD;\n

上周在Lang.NET讨论会上，我展示了我们在Ruby.NET项目上的工作，同时也有机会了解到IronRuby项目的进展以及DLR的内部运作（Charles Nutter也展示了JRuby项目）。

我的结论是DLR无疑会一直走下去，它甚至已经成为微软平台的一个非常重要的部分。我也深信如果想达到产品级别的质量和性能， Ruby.NET必须要重新发明（或者采用）某种相当于DLR的东西。如果今天我们启动这个项目的话，我们没有理由不用DLR。尽管Ruby.NET起初 比起IronRuby项目来有一个很好的开端；在引入Ruby.NET的解析器和扫描器以及对充分利用DLR以后，我此时相信IronRuby作为. NET平台上的一个产品级别的Ruby实现将会更有可能取得成功。我认为在.NET上没有必要最终存在两个不同的Ruby实现。所以，如果Ruby.NET不可能是这个最终实现的话，那么我们就没有必要再浪费开发者的努力去徒劳地追求这个目标。

\u0026#xD;\n

\u0026#xD;\n

动态语言运行时（DLR）协助创建（动态）语言运行时的库。例如，它禁止开发者直接创建MS IL指令，而是通过DLR将开发者创建的DLR树转换成MS IL。

\u0026#xD;\n

最近这种方法正逐渐被关注，因为它为语言制订人简化了许多工作。来自Ruby In Steel团队的Dermot Hogan描述了如何通过Antrl树语法来生成DLR树：

\u0026#xD;\n

现在，在Antlr方面我时常碰到的问题是，已经得到AST后接下来该做什么？通过Antlr得到一个简单的语法很容易，但是要 通过它做点儿什么可就得需要些神迹了，因为CLR代码并不简单。但是，通过树语法将Antlr的AST和DLR连接起来就方面多了——看看上面的代码。就 是编写DLR的“适配器”类而已。

\u0026#xD;\n

部分对Kelly博士消息的反应集中在IronRuby是否真的是.NET平台唯一可行的Ruby实现。例如，JRuby团队的Ola Bini说道：

\u0026#xD;\n

我一点儿也不喜欢这些新闻。在很多时候拥有一个强劲的竞争者将会促进生态系统中的每一个人。现在IronRuby即将变成这个领 域唯一的玩家，除非其他人（比如Ted Neward和David Peterson）决定接手Ruby.NET。我希望有人这样做。这会让.NET的世界变得更好。 \u0026#xD;\n

关键问题并不在于我们是否相信John Lam关于IronRuby的想法，而是在于我们是否相信微软在做正确的事情。我们相信吗？

\u0026#xD;\n

\u0026#xD;\n

这里提到了重要的一点：因为Ruby.NET是一个开源项目，一个开发者的离开并不意味着项目的结束——其他开发者们可以接手并继续开发。

同时，IronRuby的John Lam就此事说道：

\u0026#xD;\n

我们将会热烈欢迎Wayne，并邀请任何希望从事IronRuby的朋友加入我们的 开源项目。微软研究院资助了部分Ruby.NET的开发，他们的解析器同时也应用于IronRuby。感谢Wayne在制作 Gardens Point Parser Generator上杰出的工作。\u0026#xD;\n

[...]

\u0026#xD;\n

在CLR只有一个单一的实现在.NET社区是可以理解的。Ruby不仅仅是语言，还有运行在其上的程序。我们项目中最难的部分并不是如何让语言正确 工作（尽管这也不容易），而是使得IronRuby可以运行Ruby的程序。不管Rails的反对者们过去都说了什么，Rails依然是一个重要的程序。

\u0026#xD;\n

\u0026#xD;\n

这和之前的帖子相印证，在其中John提到当前IronRuby的开发策略：

\u0026#xD;\n

最终，我们谈到了如何才能到达1.0。当前我们正在向全局驱动开发过程转换。我们的下一个目标是让“gem install hoe”工作起来。Rakefile中包含一个叫做“gap”的任务，可以让你针对目标应用程序通过set_trace_proc解释器钩子来进行gap 分析。

\u0026#xD;\n

这和Kelly博士支持Rails的目标看上去很相似：

\u0026#xD;\n

我依然觉得我们还有未完成的工作——我们将目标设定为可以在.NET上运行Rails，但是我们还没有达到。如果我们能贡献出我们的经验用来帮助IronRuby实现它的话，至少我个人对于可以帮助这个任务完成而感到非常满足。

\u0026#xD;\n

注意：无论Rails对于.NET开发者来说有多么重要——其代码涉及到了Ruby的大部分特性，尤其是元编程特性。不凡的Rails应用在IronRuby上工作正常意味着Ruby特性的一大部分已经被正确的实现了。通过在IronRuby上运行Rubinius项目定义的可执行Ruby规格，将会客观地反映IronRuby的兼容性究竟如何。

\u0026#xD;\n

查看英文原文：Ruby.NET future uncertain