Python 和 Ruby 应用程序将如何受到 .NET 的影响？
我很好奇 .NET 将如何影响 Python 和 Ruby 应用程序。
用 IronPython/IronRuby 编写的应用程序是否会如此特定于 .NET 环境，以至于它们本质上会变得特定于平台？
如果他们不使用任何 .NET 功能，那么 IronPython/IronRuby 相对于非 .NET 同类产品的优势是什么？
I'm curious about how .NET will affect Python and Ruby applications.
Will applications written in IronPython/IronRuby be so specific to the .NET environment, that they will essentially become platform specific?
If they don't use any of the .NET features, then what is the advantage of IronPython/IronRuby over their non .NET counterparts?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
我不能对 IronRuby 说什么，但大多数 Python 实现（如 IronPython、Jython 和 PyPy）都尝试尽可能忠实于 CPython 实现。 不过，IronPython 正在迅速成为这方面最好的之一，并且 Planet Python 上有很多关于它的流量。
鼓励开发人员编写与 CPython 中编写的代码不同的主要因素是缺少 NumPy 等 C 扩展模块（这也是 Jython 和 PyPy 中的问题）。
IronClad 是一个值得您关注的有趣项目，它可以让您从 IronPython 中调用 C 扩展模块。 这最终意味着您可以使用您喜欢的任何模块在 CPython 下开发代码，并且无需修改即可在 IronPython 上运行。
http://www.resolversystems.com/documentation/index.php/Ironclad
因此，回答您的问题：
编写也可在 CPython 上运行的 IronPython 应用程序应该很容易，但我可能会采取相反的方式：也可在 IronPython 上运行的 CPython 程序。 这样，如果它不起作用，那么它更有可能是一个已知的错误，并且有已知的解决方法。
IronPython 等现有的优点是它们提供了该语言的替代实现，有时对于发现 CPython 中的错误很有用。 如果由于某种原因您发现自己处于不适合将 CPython 实现与应用程序一起分发的情况（例如 silverlight），它们还提供了部署 Python 应用程序的替代方法。
I can't say anything about IronRuby, but most python implementations (like IronPython, Jython and PyPy) try to be as true to the CPython implementation as possible. IronPython is quickly becoming one of the best in this respect though, and there is a lot of traffic on Planet Python about it.
The main thing that will encourage developers to write code that's different from what they would write in CPython is the lack of C extension modules like NumPy (This is a problem in Jython and PyPy as well).
An interesting project to keep your eye on is IronClad, which will let you call C extension modules from within IronPython. This should eventually mean that you can develop code under CPython, using whatever modules you like, and it will run unmodified on IronPython.
http://www.resolversystems.com/documentation/index.php/Ironclad
So to answer your questions:
It should be easy enough to write IronPython applications that work on CPython as well, but I would probably aim to go the other way around: CPython programs that work on IronPython as well. That way, if it doesn't work then it's more likely to be a known bug with a known work-around.
The advantage of IronPython et al existing is that they provide alternative implementations of the language, which are sometimes useful for spotting bugs in CPython. They also provide alternative methods for deploying your Python applications, if for some reason you find yourself in a situation (like silverlight) where distributing the CPython implementation with your application is not appropriate.
IronRuby 目前附带了大多数核心 ruby 标准库，并支持 ruby gem。
这意味着它将支持几乎所有不依赖 C 扩展的本机 ruby 应用程序。
另一方面是，可以在 IronRuby 中编写不依赖于 CLR 的本机 Ruby 应用程序，并且这些应用程序可以移植到 MRI。
人们是否选择使用 CLR 为其应用程序创建或使用扩展与人们是否为 MRI 创建或使用 C 扩展是同一个问题 - 一个并不比另一个更便携。
还有一个附带问题“因为在 C# 中创建 IronRuby 扩展比在 C 中创建 CRuby 扩展容易得多，人们会在应该坚持使用本机 ruby 代码的地方创建扩展吗？”
但总的来说，我认为任何能让创建扩展变得更容易的事情都是一个巨大的胜利。
性能：IronRuby 在很大程度上已经比MRI 1.8，离 MRI 1.9 不远了，未来只会有所改善。 我认为 python 在这方面是相似的。
部署：正如人们所提到的，对于一些基于 Windows 的开发人员来说，在 IIS 中运行本机 ruby 跨平台 Rails 应用程序是一个有吸引力的提议，因为它可以让他们更好地与现有服务器/管理基础设施/等集成
稳定性：虽然 MRI 1.9 比 1.8 好得多，我认为没有人会不同意 CLR 比 C ruby 具有更好的垃圾收集器和基本运行时。
IronRuby currently ships with most of the core ruby standard library, and support for ruby gems.
This means that it will support pretty much any native ruby app that doesn't rely on C extensions.
The flipside is that it will be possible to write native ruby apps in IronRuby that don't rely on the CLR, and those will be portable to MRI.
Whether or not people choose to create or use extensions for their apps using the CLR is the same question as to whether people create or use C extensions for MRI - one is no more portable than the other.
There is a side-question of "because it is so much easier to create IronRuby extensions in C# than it is to create CRuby extensions in C, will people create extensions where they should be sticking to native ruby code?", but that's entirely subjective.
On the whole though, I think anything that makes creating extensions easier is a big win.
Performance: IronRuby is already faster for the most part than MRI 1.8, and isn't far off MRI 1.9, and things will only improve in future. I think python is similar in this respect.
Deployment: As people have mentioned, running a native ruby cross-platform rails app inside IIS is an attractive proposition to some windows-based developers, as it lets them better integrate with existing servers/management infrastructure/etc
Stability: While MRI 1.9 is much better than 1.8 was, I don't think anyone could disagree that CLR has a much better garbage collector and base runtime than C ruby does.
IronPython/IronRuby 是为在 .net 虚拟机上工作而构建的，因此正如您所说，它们本质上是特定于平台的。
显然，只要您的程序中不使用任何 .net 框架，它们就与 Python 和 Ruby 兼容。
IronPython/IronRuby are built to work on the .net virtual machine, so they are as you say essentially platform specific.
Apparently they are compatible with Python and Ruby as long as you don't use any of the .net framework in your programs.
如果您创建了一个库或框架，人们就可以通过他们的 .NET 代码在 .NET 上使用它。 这对他们和你来说都非常酷！
在开发应用程序时，如果您放弃使用 .NET 的功能，那么您就会失去“跨平台性”，而这并不总是一个问题。
如果使用内部 API 包装这些用途，则可以稍后用纯 Python、包装的 C（对于 CPython）或 Java（对于 Jython）替换 .NET 实现。
If you create a library or framework, people can use it on .NET with their .NET code. That's pretty cool for them, and for you!
When developing an application, if you use .NET's facilities with abandon then you lose "cross-platformity", which is not always an issue.
If you wrap these uses with an internal API, you can replace the .NET implementations later with pure-Python, wrapped C (for CPython), or Java (for Jython) later.
根据 Mono 页面，IronPython 与 Mono 的 .Net 运行时实现兼容，因此可执行文件应该可以在 Windows 和 Linux 上运行。
According to the Mono page, IronPython is compatible with Mono's implementation of the .Net runtime, so executables should work both on Windows and Linux.
你用第二个问题回答你的第一个问题，如果你不使用.Net中的任何东西，只使用语言实现提供的原始库，你可以用另一个实现解释你的 *.py 或 *.rb 文件，它应该工作。
优点是，如果您是 .Net 商店，您通常会在客户端计算机上安装正确的框架等...如果您想要 python 或 ruby 代码，您现在需要支持另一个“框架”需要分发安装，解决版本问题等...所以有两个优点，在另一种语言中使用.Net框架的力量+保持分发/维护尽可能简单。
You answer your first question with the second one, if you don't use anything from .Net only the original libs provided by the implementation of the language, you could interpret your *.py or *.rb file with another implementation and it should work.
The advantage would be if your a .Net shop you usually take care of having the right framework installed on client machine etc... well if you want python or ruby code, you now need to support another "framework" need to distribute install, take care of version problem etc... So there 2 advantages, using .Net framework power inside another language + keep the distribution/maintenance as simple as possible.
在 IIS 下运行 Rails/Django 而不是 Apache/Mongrel 类型的解决方案会很酷
It would be cool to run Rails/Django under IIS rather then Apache/Mongrel type solutions