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?