Python for the CLR: Jim Hugunin’s IronPython paper at PyCON

Jim Hugunin just gave a great paper on writing his IronPython implementation on top of the CLR at PyCON.  In particular Jim says (referring to previous comments by folks indicating the CLR does not handle dynamic languages well):

“I wanted to pinpoint the fatal flaw in the design of the CLR that made it so bad at implementing dynamic languages. My plan was to write a short pithy article called, “Why .NET is a terrible platform for dynamic languages”.

Unfortunately, as I carried out my experiments I found the CLR to be a surprisingly good target for dynamic languages, or at least for the highly dynamic specific case of Python. This was unfortunate because it meant that instead of writing a short pithy paper I had to build a full Python implementation for this new platform to see if there would be any hidden traps along the way.”

Jim’s results are against the v1.1 version of the CLR and show IronPython winning at the PyStone benchmark.  I will beat you to the caveat by saying that of course this is a benchmark and mileage can and will vary.  I strongly recommend you give it a try before posting back speculation on all the ways a benchmark can distort your reality <g>. 

I’m happy to see great results here that show a good implementation can do very well on the CLR.  But even with that start, there is more we can do here.  For example in Whidbey (v2.0), we actually added more dynamic language support in the form of lightweight code generation (LCG).  This support is being used internally by Yukon for SQL/CLR support.

I am interested in hearing from the community about the value of truly dynamic languages (not talking about late bound VB here) to your everyday life.  It helps us figure out how much additional investment we should make in the technology.  I personally think it is valuable investment.  What’s your opinion?  Are you using these languages today in your work?

Comments (23)

  1. It is my belief that this is an important development and that improving support for "scripting" languages is an important benefit for the .NET platform. On Java projects that I’ve worked on in the past, I’ve used scripting languages such as Jython, JavaScript, and Ruby to add extensibility support to my applications. I’d like to see the ability to do this on the .NET platform and the same rich languages made available through scripting engines to .NET applications.

  2. RJ says:

    Where can we find more info on LCG in Whidbey? Has this info been made public?

  3. Larry Wright says:

    I’m confortable in a lot of languages. VB, C#, C++, Python. When I need to find a solution to a problem I often find myself reaching for Python, particularly if this isn’t a GUI sort of thing. Python is quick to develop in, elegent, and has a ton of libraries available that can handle just about anything I might need to do. C# is a nice language, and if you’re coding GUI’s, it’s great. I think MS is missing the boat though by not including a really good dynamic language in the mix (no, I don’t count Jscript).

  4. "no, I don’t count Jscript"

    Just curious – why not? I rather like JScript (the old implementation, not the JScript.Net one) and I understood it to support about the same feature set as python.

    I use it constantly as a sort of super batch processing language – I’ve got a text editor setup usually in the background so that I can write a script, press ctrl+1 and it will run and output the results to a window. Great for quick code-gen, moving files around, whatever.

    The company I work for tried to use JScript.Net as a scripting language for a workflow engine we’re building, but it’s memory characteristics were too unbearable and we had to give it up. We tried working around it by using Eval() for fully dynamic execution, but then things like closures, the Function() constructor, and anonymous functions stopped working.

    Personally, I would love to see something like Python or Ruby on .Net, but I would settle for a fully conformant version of JavaScript.

  5. Check out System.Reflection.Emit.DynamicMethod {} for more detail on LCG. It is very similar to Reflection Emit API wise…

  6. Joel Pobar says:

    I’ve cooked up a brief overview of the feature, and a small chunk of code:

  7. Jason Zander, PUM for the CLR, asked our opinions about dynamic languages and the CLR. Maybe I’m showing myself as a rube by saying this, but I just want to be able to use the language as a tool, not a philosophy.

  8. Jason Zander says:

    Looks like the url for Jim’s paper was busted on the site. Here is the one from PyCon:

  9. Luis says:

    I’m not a professional programmer but a "serious" amateur…

    I use scripting languages (php, python) for everyday tasks as well as VBA within Access.

    I am sure that having a good implementation of Python in .NET would be a very good thing for everybody, including Microsoft.

    With .NET, we gained a lot, but we also missed the simplicity of VB. It offers too much for the professional developer, but the occasional user is forced to learn complex language features in order to keep on doing what he used to do with older technologies.

    We need a simple tool to get hings done with the least delay.

    C# is too complex. Python can be learned in just a few hours. And programming with it is simple, fast and fun.

    We need Python in .NET!!

  10. ????????:














  11. Don't forget IDE support! says:

    I would really like to see IronPython as a first class member of Visual Studio. People have had a lot of trouble implementing intellisense features into Python IDEs due to it’s dynamic nature. I wouldn’t mind sacrificing some dynamism for type inference (optionally perhaps?) as in Boo. But I must have intellisense when dealing with a large framework such as .NET.

    It would be great to leverage the large community code available for Python. It is not that C# does not have equivalent libraries. Dynamic languages often tend to have higher level libraries and this is very convenient for most programming tasks.

    Ravi Teja.

  12. Jason Zander says:

    I agree having first class VS support would be great here. Once you’ve used intellisense you don’t want to go back. I know that Jim has spent some time thinking about that space so it’ll be interesting to see what we can do there.

    wrt the libraries, one thing that would be great is to make the .NET FX and other "built-in" managed libraries easily accessible to dynamic langauges. One of our goals with the .NET FX was to allow better leverage of common code bases (eg: one Forms package instead of four, one common set of collections instead of one per langauge, etc). I’d love to see a world where we could continue doing that, but in a way consistent with dynamic languages (the "higher level" attribute). Ideally it would not involve having to wrap everything. We’ll see. Some of that may involve working on our design guidelines. I see lots of interesting problems to solve here.