Choosing a DLR language: IronPython or IronRuby?
.NET developers interested in dynamic languages but still wanting to stay within the .NET ecosystem have an interesting choice - IronPython or IronRuby?
Simon Segal, who has been adding scripting support to his Entity Framework profiler, has been pondering this question:
Simon Segal, who has been adding scripting support to his Entity Framework profiler, has been pondering this question:
For my part so far I have delved into IronRuby and started to employ it for scripting my C# applications. Why did I choose IronRuby over IronPython? It began with curiosity in the Ruby language in general and led inevitably to IronRuby. I quickly acquired a taste for Ruby but there is something nagging in the back of my mind and I can’t get to the bottom of it - “did I choose the right language” and really after all “does it matter which one I choose?”Shortly after he chose IronPython over IronRuby:
Given Pythons relationship to C and my emotional connection to the C family of languages, would IronPython have been a better choice? Certainly IronPython is further down the track and more mature than IronRuby at this stage, but what does that count for at this early stage? All these questions make me curious for some other opinions which I would leave to hear right here, so please tell me – what do you think? What criteria would you use to make a choice?
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.Prior to writing these blog entries Simon contacted me by email and asked me what I thought.
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.
I have been investing some time of late with IronRuby and have started several projects that incorporated scripting into applications written in C# and also have begun a project for a Entity Framework profiler that allows for scripting of my Repositories.My thoughtfully considered and entirely unbiased response...My question is regarding what I feel is a choice right now between IronPython and IronRuby. I am increasingly feeling a bit anxious that IR is slowing me down because of the projects maturity as compared to IP and I am also getting the impression that IP is somewhat preferred within Microsoft itself? I have no experience with Python but feel that if my chosen dynamic language in the .NET space needs to change it should be sooner and not later. I am not looking for a lengthy bullet point IR vs. IP evaluation, just a short high level opinion as to whether my concerns or any others should be heeded. If IP is the way to go I think I know of a good book!
I'm sure you don't expect an unbiased opinion from me, so I assume you have already made your decision and just need me to push you over the edge. ;-)
Actually IronRuby is approaching a 1.0 release soon, so it sounds like it is improving as regards maturity.
Despite this IronPython is more mature as regards .NET interop, performance and bugs. Version 2.6 will be a particularly good release (lots of work on performance) including features like __clrtype__ allowing the use of .NET attributes that I think will take a while before they show up in IronRuby.
Personally I think there are lots of reasons to prefer IronPython over IronRuby:
The Python object model is much closer to C# than Ruby. This means that it performs better and there are less issues around .NET interop - plus it is easier to learn for C# developers.
Python in general is a 'cleaner' language (a purely aesthetic judgement) with clearer namespacing, less use of sigils and no syntactic dependence on the casing of class / variable names. Although Ruby has anonymous blocks they are highly special cased in the language leading to various anomalies in the way they are handled. It is still annoying that Python can't have statements in its lambda functions but there is no clear way to add them to the language (due to using indentation for block structure which despite this disadvantage is still a stroke of genius).
Because Python is more widely used (still - despite all the publicity that Ruby has had through Rails in the last two years or so) there is wider community and more open source libraries available.
Having said all that, both Python and Ruby are great dynamic languages in which it is easy to be productive. They have different facilities for metaprogramming but as far as I can tell they are both equally powerful. Either choice would be a good one but naturally I think Python is the better choice...
Comments
Post a Comment