John Lam如何评价Ruby.NET与IronRuby差异

2008 年 1 月 10 日

最近,M. David Peterson 在 O’Reilly Network 发表了一篇名为《Ruby.NET 与 IronRuby:差别在何处》的文章。这篇文章引起了微软 IronRuby 项目的领导者——John Lam 的注意。John 在 David 文章后面跟贴,阐述了他自己对于 IronRuby 的一些观点。

David 在文章中对 Ruby.NET 和 IronRuby 进行了比较。关于 IronRuby,David 说:

* IronRuby 构建于动态语言运行时(DLR)之上。DLR 是 CLR 的一个扩展,致力于支持静态类型语言(如 C#)和动态语言(如 Ruby)之间的差异。

而对于 Ruby.NET 来说

* Ruby.NET 构建于 CLR 之上。考虑到 DLR 是 CLR 的一个扩展(换句话说,DLR 需要 CLR), IronRuby 和 Ruby.NET 在能力方面并没有根本性的差别。

John 解释了 DLR 为那些使用它的语言所带来的好处:

  • 共享的代码生成引擎。使用我们的代码生成 API 比 Reflection.Emit 更加简单,所以这为编译器实现者们节省了时间。这同时也意味着 DLR 在未来的性能提升会惠及那些基于 DLR 的语言。
  • 公共的宿主接口。我们扮演的是宿主与编程语言之间的中间人的角色。如果你编写的宿主程序面向 DLR,那么我们的编程语言(以及那些虽然不是我们编写的,但基于 DLR 的编程语言)不需要任何特别的努力就可以与你的程序协同工作。而我们的团队正在构建 Silverlight 和 ASP.NET 的宿主程序。

另一个随之而来的问题是,如果 CLR 已经赋予编程人员访问任意与 CIL 兼容语言的能力,那为什么还需要面向 DLR 进行工作呢。如果无法回答这个问题,那么很明显应该选择 Ruby.NET 而不是 IronRuby。

对此 David 提出了一个根本性的问题:

对于编程者来说,需要的到底是 CLR 所提供的强大语言互操作能力(这也是 Ruby.NET 的所长之一),还是 DLR 所提供的动态语言性能优势(这则是 IronRuby 的优点)?

John 进行了回复,解释了他的观点:

我不认为使用 DLR 会失去任何与现有基于 CLR 的语言族之间的互操作能力。虽然对于我们来说,到现有基于 CLR 的语言的动态分发机制确实还有很大的改进空间(你应该更愿意用 C#或 VB.NET 调用 Office API 吧?),但现在在 C#中调用 IronRuby library 代码应该没有什么障碍。只要你通过我们的宿主接口(hosting interfaces)进行,互操作就可以很好的工作。我不清楚对于像 Ruby 这样要求上下文环境的语言来说,如何能够在不传递上下文环境的情况下,保证在 C#中可以调用任意 Ruby.Net 代码。

David 同时说:

IronRuby 动态编译的特性使其更适合那些在编译过程中可预测的部分较少的程序,比如客户端应用。反之,对于服务器端这种可预测部分很多的程序来说,Ruby.NET 可能更加适合。

John 回复道:

Ruby.NET 采用了静态编译模型,其优点之一在于减少了冷启动时间。由于 Ruby.NET 的装配必须是 JIT(Just In Time)的,所以 Ruby.NET 仍然需要处理 CLR 的冷启动问题。而 IronRuby 则采用了生成 IL 和 JIT 代码的方法。我想暂时把这一讨论放下而说一点题外话。对于客户端应用来说,冷启动时间至关重要,而这也正是 Ruby.NET 的优势所在。我们曾经在 IronPython 中使用过一个 AOT 编译模型,但已经将其从的 DLR 1.0 的特性列表中去掉了。关于这一问题,我们会在 1.0 之后的版本中重新考虑。

David 这篇文章的原文已经在 John Lam 发表看法后进行了修改,不过文章仍然留下了几个没有回答的问题。关于 Ruby.NET 和 IronRuby,Ruby 开发者现在想知道的一个问题是什么时候 Ruby on Rails 可以在这两个平台上运行。据 Ruby.NET 社区的一名开发者称,在完成 Ruby 实现中的几个关键构件后,才能考虑在 Ruby.NET 上运行 Ruby on Rails。关于 IronRuby 是否会支持 Ruby on Rails 在其上运行,除了 John Lam 在 07 年 RubyConf 的表态外,尚无任何具体信息。而跟据 Seo Sanghyeon 的说法,融合 Ruby 和.NET 的最初工作是 RubyCLR,由 John Lam 所创建的一个项目。

当考虑在 IronRuby、Ruby.NET 和 RubyCLR 中进行选择时,会涉及许多问题。这些项目目前尚处于初期,因此如果你打算在.NET 平台上编写 Ruby 代码,密切关注这些项目是一个明智之举。

关于 IronRuby 的更多信息可以通过 IronRuby 网站和 John Lam 的个人blog 获得。

查**** 看英文原文: John Lam Responds to Ruby.NET vs. IronRuby

2008 年 1 月 10 日 00:34 275
用户头像

发布了 0 篇内容,共 1 次阅读,收获喜欢 0 次。

关注

评论

发布
暂无评论
发现更多内容

架构师训练营:第二周 作业

Bruce Xiong

北京疫情反弹 区块链怎样破解食品溯源难题?

CECBC区块链专委会

区块链技术 商品溯源 上链

第二周学习总结

赵龙

架构师训练营第二周作业

张锐

极客大学 极客大学架构师训练营

架构师实现自己架构目标工具手段-软件设计

WulalaOlala

极客大学架构师训练营

重拾依赖倒置原则(训练营第二课)

看山是山

oop 极客大学架构师训练营 依赖倒置原则 DIP

架构师训练营第二周感悟

张锐

极客大学架构师训练营

【架构师训练营】第2周作业

花生无翼

极客大学架构师训练营

ElasticSearch原理解析

Chank

elasticsearch

架构师训练营week2 学习小结

李锦

架构师训练营第二周作业(1)

hiqian

2020/6/16 架构学习心得

架构5班杨娟Jessie

极客大学架构师训练营

面向对象设计原则课后作业

周冬辉

架构师训练营第二周作业(2)

hiqian

week02 小结

Geek_196d0f

基于docker部署的Java应用jmx无法远程访问的问题

qihuajun

依赖倒置及Cache重构设计

架构5班杨娟Jessie

极客大学架构师训练营

如何进行信息搜集: 从6亿人月收入仅1000元谈起

lmymirror

知识管理 读书方式

依赖倒置原则

Z冰红茶

Week 02 学习总结 框架 设计原则

Z冰红茶

SharePoint 往事之:使用Bootstrap定制SharePoint网站页面

手艺人杨柳

SharePoint

架构师训练营第二周作业

olderwei

极客大学架构师训练营

极客时间架构课 Week02- 作业一:命题作业

yulyulcl

week02 作业

Geek_196d0f

第二周作业

carol

依赖倒置 接口隔离原则

docker-mcr 助您全速下载 dotnet 镜像

newbe36524

Docker netcore

手撕设计原则:接口隔离

柳旭

面向对象 架构师 面向对象设计 面向对象设计原则

架构师训练营:第二周学习总结

Bruce Xiong

架构师训练营第二周总结

olderwei

Spring中依赖倒置原则的理解

李广富

第二周作业

赵龙

跨越计算鸿沟:如何靠软硬件协同突破算力瓶颈?

跨越计算鸿沟:如何靠软硬件协同突破算力瓶颈?

John Lam如何评价Ruby.NET与IronRuby差异-InfoQ