Making the Case for IronRuby and IronPython

Question

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:

1. Embedded scripting languages in bigger applications: A valid use case, but it seems like a niche scenario for most developers.
2. 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.
3. 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?

Dunghill

Answer 1

What you wrote there is right and I'll add some more bullets:

• Using the interactive console for quick browsing/testing of methods.
• Since developing in IronRuby/IronPython is faster, you can use it to write POCs and later implement the real application in C# or whatever you're using.
• Implement DSLs in IronRuby and use them from static languages.
• Adding dynamic capabilities (REPL consoles, for example) to static language applications.
• Gestalt.
• For Rubyists: writing WPF and Silverlight (WP7 apps too, potentially) in IronRuby.

Zavala

Shay, I happened on your blog while researching the answer for this question before posting it here, and I've noticed that you're a staunch advocate of IronRuby. So +1 for taking the time to reply here, and a thank you. Unfortunately, judging by the resounding unpopularity of this question and the general "meh" that I'm seeing online about this subject, it seems that a strong and compelling argument is yet to be made. It would be great if someone with your background would manage to articulate a more definitive answer. – Dunghill

Well I don't think there is a "definitive answer". Ruby is a programming language just like C# is and you can do with it whatever you can do with C# and even more sometimes. However, IronRuby is a bit problematic because .NET devs are not willing to stop using C#, so you have to talk about IronRuby more as a tool than as a full programming language. As a tool, I think your bullets plus mine make a lot of sense. And in my opinion, it makes a very very powerful tool. – Zavala

Answer 2

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.

Contagion

Answer 3

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?

Hauler