用Iron-*语言来探索.NET

Java的创新思维似乎已死...总不能每次都看看.net就知道java下个版本会有什么，enum? foreach? auto-boxing? methodhanlder...


奇怪，为什么著名的perl竟然没有ironperl？ 当然因为Microsoft当activestate的后台老板。。。。也许不想砸他们的饭碗

兼容性是Jython 2.5关注的重点，外加来自JRuby的FFI支持，对使用了C extension的Python库的支持应该比IronPython好。
在启动速度上，Jython可以得益于JVM初段的解释执行，从而减缓刚开始的编译压力。但各JVM的实现策略不同，这种解释执行是得不到保证的。Jython 2.5自身并没有采取任何特别方法来提高启动速度，但以后的版本肯定会有这方面的工作。现在这个版本更多的是“Jython的复活”版本。
IronPython运行在CLI上，而现在桌面上两种主要的CLI实现，CLR和Mono都是直接JIT而不解释的，这层上IronPython的启动速度本来就吃了点亏。现在IronPython通过DLR的解释器来做自适应编译，可以看作是弥补启动速度慢的措施。2.6现在相当的不能行……只能等。
Jython与IronPython都达到稳定的运行状态时，还是后者的throughput比较大。不过许多时候脚本不太关注throughput，所以这算不算IronPython的优势也不好说。

IronRuby现在还在“早期”，还没进入“production ready”行列；JRuby则已经相当成熟了。这暂时还没法放在一个层次上来比。用生产要求来看现在的IronRuby的话那就是“不可用”。

微软到底是怎么看待对C extension支持的，我一直没看出所以然来。通过P/Invoke，在.NET上要做个合理的FFI出来应该比JVM那边要容易才对。但现在我们并没有看到DLR里有相关支持，却对COM有特别改进过的支持。对微软来说，对使用了C extension的现有库的支持看来是被忽视的内容。