Creating a package for IronRuby and IronPython

Question

I think everyone has already heard the news about some key developers leaving the Dynamic Languages ​​team because of what they perceive as impaired support for Dynamic Languages ​​at Microsoft.

I really love Python and try to use it often. So in addition, I take care of IronPython and would like it to continue to evolve. I am sure many people feel the same for IronRuby. But what I still can't understand is why .NET developers should take care of IronRuby and IronPython?

If you should write a letter to Microsoft asking you to continue supporting and developing DLR and iron languages, what arguments would you use?

If you convinced your employer to give developers time to participate in community-supported versions of IronPython or IronRuby, how would you rationalize it in terms of business value?

Here are some interesting use cases that I could come up with, but if I, where the manager reflected on the question above, I probably would not find them so convincing:

• Built-in scripting languages ​​in larger applications: A valid use case, but for most developers, it looks like a niche script.
• Testing and test automation. Ruby in particular has a rich set of tools and libraries for subtle testing, and it would be nice if they were useful in .NET through IronRuby. But the equivalent .NET libraries seem to fill this gap, for example SpecFlow and Selenium WebDriver .
• Launching existing frameworks in Microsoft Stack:. If IronRuby allows Ruby on Rails to run on Windows using IIS and MS SQL, this could encourage stores that are standardized on the Microsoft stack to adopt RoR.

Can anyone think of something better?

Answer 1

What you wrote there is correct, and I will add a few more bullets:

• Using an interactive console to quickly view / test methods.
• Since development in IronRuby / IronPython is faster, you can use it to write POC and then implement a real C # application or whatever you use.
• Embed DSL in IronRuby and use them from static languages.
• Adding dynamic capabilities (such as REPL consoles) to static language applications.
• Gestalt.
• For hacksters: writing WPF and Silverlight (possibly WP7 applications) in IronRuby.

Answer 2

I would not underestimate the value of embedding one of them in a large application. I used Ruby's meta-programming features to change the internal elements of the application on the fly to connect to things that are usually difficult to access (this is especially true for events, I can easily add a temporary external hook to manually raise the event for instead of the actual change and recompile source C #). This allowed me to hunt for mistakes and easier to reproduce complex scenarios. He also allowed me to prototype various code, which I will later do in unit test or new classes.

In addition, it may be useful for manual QA testers. Common tasks can be included in automated scripts that they can run.

Answer 3

Lightweight scripting is a very good reason to have dynamic, embedded languages ​​in your .Net toolbox.

My company is engaged in a scientific instrument. Data collection and analysis is performed using scripts within the application. This allows us to respond very quickly to the various needs of our customers.

We evaluated technologies for updating our software, so we do not need 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 the release of .Net4 and C # 4.

I think now I may have made the wrong decision and am considering returning to Qt / PyQt. How is this for good reason?