为 IronRuby 和 IronPython 辩护
我想每个人都已经听说过关于 一些关键开发人员离开动态语言团队，因为他们认为 Microsoft 对动态语言的支持正在减弱。
我非常喜欢Python并且经常尝试使用它。因此，推而广之，我关心 IronPython，并希望看到它继续发展。我相信很多人对 IronRuby 都有同样的感觉。但我仍然不太明白的是为什么 .NET 开发人员应该关心 IronRuby 和 IronPython？
如果您要写一封信给 Microsoft，要求他们继续支持和开发 DLR，铁语言，你会使用什么论据？
如果您要说服您的雇主投入开发人员的时间来为尚未开发的、社区支持的 IronPython 或 IronRuby 版本做出贡献，您将如何在商业价值方面合理化它？
以下是我可以提出的一些有趣的用例，但如果我让经理思考上述问题，我可能不会发现它们那么引人注目：
- 更大的嵌入式脚本语言应用程序：一个有效的用例，但对于大多数开发人员来说这似乎是一个利基场景。
- 测试和测试自动化：Ruby 尤其具有丰富的优质测试工具和库可供选择，如果能够通过 IronRuby 将它们用于 .NET，那就太好了。但似乎等效的 .NET 库正在填补这一空白，例如 SpecFlow 和 Selenium 的 WebDriver。
- 在 Microsoft Stack 上运行现有框架：如果 IronRuby 能够使 Ruby on Rails 能够在带有 IIS 和 MS SQL 的 Windows 上运行，这可能会鼓励在 Microsoft Stack 上进行标准化的商店采用 RoR。
有人能想出更好的办法吗？
I guess everyone has already heard the news about some key developers leaving the Dynamic Languages team due to what they perceive as waning support for Dynamic Languages at Microsoft.
I'm quite fond of Python and try to use it often. So, by extension, I care about IronPython and would like to see it continue to evolve. I'm sure many people feel the same for IronRuby. But the thing that I still can't quite figure out is why should .NET developers care about IronRuby and IronPython?
If you were to write a letter to Microsoft asking them to continue supporting and developing the DLR and the Iron languages, what arguments would you use?
If you were to convince your employer to commit developers' time to contributing to the yet-to-be-made community-supported versions of IronPython or IronRuby, how would you rationalize it in terms of business value?
Here are the few interesting use cases that I could come up with, but if I where a manager pondering the question above, I probably wouldn't find them that compelling:
- Embedded scripting languages in bigger applications: A valid use case, but it seems like a niche scenario for most developers.
- Testing and test automation: Ruby in particular has a rich selection of fine testing tools and libraries, and it would be nice to have them usable in .NET through IronRuby. But it seems that equivalent .NET libraries are filling that gap, such as SpecFlow and Selenium's WebDriver.
- Running existing frameworks on the Microsoft Stack: If IronRuby would enable Ruby on Rails to run on Windows with IIS and MS SQL, this could encourage shops that have standardized on the Microsoft stack to adopt RoR.
Can anyone think of something better?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您在那里写的内容是正确的，我将添加更多项目符号：
What you wrote there is right and I'll add some more bullets:
我不会低估将其中之一嵌入到大型应用程序中的价值。我使用 Ruby 的元编程功能来动态修改应用程序的内部结构，以挂钩通常难以访问的内容（对于事件尤其如此；我可以轻松添加临时外部挂钩来手动引发事件测试而不是实际修改和重新编译 C# 源）。这让我能够更轻松地寻找错误并重现棘手的场景。它还让我可以对各种代码进行原型设计，然后将其制作成单元测试或新类。
此外，它对于 QA 手动测试人员也很有用。常见任务可以合并到它们可以运行的自动化脚本中。
I wouldn't underestimate the value of embedding one of them in a large application. I've used Ruby's meta-programming capabilities to modify an app's internals on the fly to hook into things it would usually be difficult to access (this is especially true for events; I can easily add a temporary external hook to manually raise an event for testing instead of actually modifying and recompiling the C# source). This has let me hunt down bugs and reproduce tricky scenarios more easily. It has also let me prototype various code that I would later make into a unit test or new classes.
In addition, it can be useful for QA manual testers. Common tasks can be incorporated into automated scripts they can run.
轻量级脚本是在 .Net 工具包中使用动态、嵌入式语言的一个非常令人信服的理由。
我的公司是做科学仪器软件的。数据采集和分析都是通过框架应用程序中的脚本完成的。这使我们能够快速响应客户的不同需求。
我们一直在评估升级软件的技术，这样我们就不必维护自己的脚本语言。我研究过 Qt/PyQt，但当它被卖给诺基亚时我就临阵退缩了。我决定等待，看看 IronPython 如何成熟。 .Net4 和 C# 4 出现后，我决定使用 IronPython。
我想现在我可能做出了错误的决定，正在考虑回到 Qt/PyQt。这怎么能是一个令人信服的理由呢？
Lightweight scripting IS a very compelling reason to have dynamic, embedded, languages in the .Net toolkit.
My company does scientific instrument software. Data acquisition and analysis are both done with scripting in a framework application. This allows us to be very responsive to our customers' varying needs.
We've been evaluating technologies to upgrade our software so we don't have to maintain our own scripting language. I looked at Qt/PyQt but got cold feet when it was sold to Nokia. I decided to wait to see how IronPython matured. I decided to use IronPython after .Net4 and C# 4 came out.
I think now I might have made the wrong decision and am considering going back to Qt/PyQt. How's that for a compelling reason?