CODEWITHSUNDEEP
ironpythonironrubydynamic-language-runtimedynamic-languages
Mhmmd
Mhmmd

Reputation: 1484

Making the Case for IronRuby and IronPython

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?

Upvotes: 7

Views: 674

Answers (3)

Max Yaffe
Max Yaffe

Reputation: 1358

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?

Upvotes: 0

Matt H
Matt H

Reputation: 7389

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.

Upvotes: 2

Shay Friedman
Shay Friedman

Reputation: 4868

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.

Upvotes: 5

Related Questions