A while back I went through the personal struggle of trying to decide which .NET dynamic language I was going to adopt. After some fairly lengthy consideration and with a bit of help from Michael Foord, I chose IronPython. Recently I posed this question to Michael: are .NET developers experiencing some *romantic* attraction to IronRuby? Michael I think was a little taken aback and not sure how to respond, most likely I didn’t frame the question eloquently nor clearly enough and so I will take another shot at it here.
Let me explain what I mean by “romantic”. I am noticing that people (I know) in the .NET development community are leaning more towards IronRuby when faced with the choice. Perhaps my perspective over the so-called community isn’t broad enough to make any sweeping generalisations here, I understand that, nonetheless, tucked away here in my small corner of the universe I get a sense that I am observing a kind of default (if not romantic and sometimes perhaps envy driven) choice of IronRuby over IronPython.
What are the contributing factors? Some very high profile .NET people have jumped the .NET ship in favour of developing with MRI in the recent past. The most obvious connection I guess may be that ASP.NET developers (who by far number the majority in the .NET employment pool) have an vested interest in the successes of ROR which may account for this perceived phenomenon. I also get the feeling the feeling that Ruby gets a better deal in the hype stakes and that could also be having some impact.
I wonder has anyone else noted this? Figment of my imagination? Way off the beam? One thing is for sure, neither seem to be playing a real part in the commercial world yet; a search on seek.com.au (a well known job market web site) for IronRuby or IronPython or DLR, will sadly produce no results. This is understandable as IronRuby in only just recently gone RC1, but IronPython has been around a little while and some people in some parts of the world do make a living with it already.
UPDATE:
Oh I did forget that perhaps people just think Ruby is the better of the two languages?
The choices facing any programmer wanting to start working with IronPython or IronRuby for that matter, contain some interesting questions. Working with Dynamic languages in .NET prompts us to consider whether to use Python / Ruby native standard library method and functions or directly work against the BCL? If your programming in a statically typed language on top of the CLR, then it’s just different syntax but the same platform libraries. If you want to try your hand with IronPython or IronRuby you need to consider that both these languages have evolved on different platforms. For example, should I consider using Python standard library functions to interpolate some strings or should I use the BCL? Consider these two approaches:
Classic Python Version
print “should I use python functions or .Net?“ +
“Ans = %(yes)s“ % {‘yes‘: ‘yes‘}
BCL Centric Version
print String.Format(“should I use python functions“ +
“or .NET? Ans = {0}“, “BCL Functions“)
So that was pretty trivial. What about File access?
Classic Python Version
rdrp = open(r”c:\Document1.txt“)
rdrp.read()
BCL Centric Version
rdr = StreamReader(r”c:\Document1.txt“)
print rdr.ReadToEnd()
Any clearer on a choice? The pragmatist in me says use the BCL and the purist says use the python standard libraries. So how heavy should our BCL wielding hand be? This leads me nicely to the next question, how exactly should we go about learning a Dynamic .NET Language? Surely this process will help us make up our minds about when to use the BCL and when not to? Something tells me that the answer lies pragmatically somewhere in the middle ground? The kind of meat and potato stuff like that demonstrated above is likely going to have me opt for the classic Python approach as my default position, however I am not going to put myself to the trouble of working with databases for example without the help of ADO.Net. To help myself form my own opinions I decided that the best learning path for me was as follows:
- Read the Python 2.5 (CPython) documentations PDF Tutorial and re-type it’s code examples and follow with my own experimenting.
- This allowed me to get a fairly good overall feeling for the language.
- Read IronPython in Action to get a good overall point of relevance to .NET and see how the power of .NET as a platform would impact the Python experience and visa versa.
- Read Python is a Nutshell and get a grasp on Python’s roots and how the language is best put to use on it’s original platform (the C implementation).
Some people will surely think that points 2 and 3 should be reversed? Perhaps, but my rationale for taking this approach is that Python is not likely to become a daily instrument in my work and I want to understand as much as possible about it in the .NET world first. I do believe however that to truly understand the power of Python I will need to learn deeply about its roots and oddly I suppose that step in the process will come last.
Initially when I made the decision that I would benefit from learning a new language that adhered to a different paradigm (dynamically typed), I selected IronRuby over IronPython simply because I had seen it first and perhaps got caught up a little in the industry hype and good PR going on.
After having spent a less than insignificant amount of time invested in IronRuby I decided to bite the bullet and invest the effort into IronPython instead and the reasons were entirely pragmatic. Microsoft seem to be putting more effort into IronPython, has already found it’s way into other stacks, such as Oslo’s Intellipad (which I plan to leverage) and it’s significantly more mature than IronRuby.

I am constantly finding uses for IronPython in my work and the list of problems that it’s going to help solve is growing quickly. As a side note, if you are looking to use IronPython and are ready to let the experience pass you by because of lack of IDE support then check out using NetBeans (for Python) and instead using IronPython. As previously detailed by Steven and David, you can use the NetBeans Tools menu and make the selection ‘Python Platforms’, then you can configure a new default platform setting and redirect the IDE to use IronPython (see above screenshot). I haven’t used this configuration for long but for now it seems to work nicely.