用Iron-*语言来探索.NET

http://dynalang.sourceforge.net/ 这个有点意思。

大部分还是proto,priority放的都是med，未来会不会出现在JDK还不得而知。

Runtime support for closures 这个可能根本就不会实现吧？

那个叫JDK7而不是Java7。我承认我是在咬文嚼字，不过Sun至今并没有提交Java7的JSR，所以……
DVM就是块实验田而已，里面的idea不保证会得到实现，实现的东西不保证会进入未来的JDK。但至少还是有这么块实验田，让人多少能感受到希望（=v=


这就是JVM上的MOP（meta-object protocol），跟DLR的MOP对应。
一直在整理一份资料，现有JVM+invokedynamic相关+dynalang（+ASM？） = 现有CLI+DLR。需要整理的头绪很多，一时半会儿是出不来了 T T

Microsoft的试验田不知道在哪里...我转了好几圈想找C# 4.0的Spec和CLR 4.0的Spec.

微软的实验田有很多在MSR和与各大学合作的项目里，sigh。
C# 4的spec还没定稿，VS10 beta前都没指望看到草稿。但传闻这周就有希望看到beta了，一起等吧～
CLR 4...这玩儿会有spec么？CLR 2之后微软都没更新过ECMA-335，好长时间了。当然这期间CLR的表面没多少变化也是事实。CLR 4不知道会不会是更新ECMA-335的契机呢。

DLR的spec倒是公开了草稿，在这里：http://dlr.codeplex.com/Wiki/View.aspx?title=Docs%20and%20specs

实际用起来，我倒是觉的jython源代码的兼容程度更高，导入和启动都比ironpython 快

ironpython只要启用site.py后，启动就会比较慢，导入模块，也是比较慢的，今天编译2.6感觉有些许改善，但还是不如人意。 2.6现在的代码居然将collections改成_collections了，frame的支持倒是有了，但__slot__的兼容性还是存在，跑sqlalchemy时，还是有许多的错误。 jython表现就好多了


ironruby 现在也能跑rails，但实际感觉很慢，错误也比较多，基本没有可用性

总体来说，感觉ms对兼容这些存在应用兴趣不大，只是将其作为演示的考虑,花点时间hack一下，同jruby,jython的不遗余力保持兼容的做法还是有很大不同的

兼容性是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的现有库的支持看来是被忽视的内容。

对了，刚才看到了一篇blog：Dismal performance with IronPython
这篇blog中作者提到他的代码在IronPython上运行甚至会比CPython慢到100x的级别。有兴趣的话可以看看。

Microbenchmark与实际代码果然还是甚有差距。

C#代码->编译->运行->发现错误->修改->再编译->...

IronPython->运行->发现错误->修改->运行->发现错误->修改

是这个区别吗？

不尽然……让我模拟一次这过程：

C#：

using System.Text.RegularExpressions;
class Test {
    static void Main(string[] args) {
        var regex = new Regex(@"^c");
        var str = "abcdefg";
        Console.WriteLine(regex.Match(str).Value); // 注意这行
    }
}

这里写错了一点，因为我没有写using System;所以会找不到Console这个类。保存文件，编译，发现错误，修改，再编译。假设编译过了，但运行发现结果不对，判断是正则表达式写错了，那么再打开文件，编译，保存，编译，运行来看结果。

IronPython：
一上来先打开ipy，一个交互式解释器环境。

IronPython 2.6 Beta DEBUG (2.6.0.1) on .NET 2.0.50727.3082
Type "help", "copyright", "credits" or "license" for more information.
>>> System.Text.RegularExpressions
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'System' is not defined
>>>

在ipy里输入System.Text.RegularExpressions，解释器报错，说'System'未定义。怎么办呢？
不用关掉ipy，还在刚才的同一个环境里，输入import clr：

IronPython 2.6 Beta DEBUG (2.6.0.1) on .NET 2.0.50727.3082
Type "help", "copyright", "credits" or "license" for more information.
>>> System.Text.RegularExpressions
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'System' is not defined
>>> import clr
>>> System.Text.RegularExpressions
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'System' is not defined
>>>

再试那个命名空间发现还没引入进来。然后继续在ipy里输入import System：

IronPython 2.6 Beta DEBUG (2.6.0.1) on .NET 2.0.50727.3082
Type "help", "copyright", "credits" or "license" for more information.
>>> System.Text.RegularExpressions
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'System' is not defined
>>> import clr
>>> System.Text.RegularExpressions
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'System' is not defined
>>> import System
>>> System.Text.RegularExpressions
<module 'RegularExpressions' (CLS module from System, Version=2.0.0.0, Culture=n
eutral, PublicKeyToken=b77a5c561934e089)>
>>>

现在试那个命名空间得到了正确的结果，于是就进一步把代码写下去：

IronPython 2.6 Beta DEBUG (2.6.0.1) on .NET 2.0.50727.3082
Type "help", "copyright", "credits" or "license" for more information.
>>> System.Text.RegularExpressions
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'System' is not defined
>>> import clr
>>> System.Text.RegularExpressions
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'System' is not defined
>>> import System
>>> System.Text.RegularExpressions
<module 'RegularExpressions' (CLS module from System, Version=2.0.0.0, Culture=n
eutral, PublicKeyToken=b77a5c561934e089)>
>>> R = System.Text.RegularExpressions.Regex
>>> r = R('^c')
>>> s = 'abcde'
>>> r.Match(s)
<System.Text.RegularExpressions.Match object at 0x000000000000002B>
>>> m = _
>>> m
<System.Text.RegularExpressions.Match object at 0x000000000000002B>
>>> m.Value
''
>>> m.Success
False
>>>

现在看到正则表达式匹配失败了。仍然在同一个ipy里，继续试：

IronPython 2.6 Beta DEBUG (2.6.0.1) on .NET 2.0.50727.3082
Type "help", "copyright", "credits" or "license" for more information.
>>> System.Text.RegularExpressions
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'System' is not defined
>>> import clr
>>> System.Text.RegularExpressions
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'System' is not defined
>>> import System
>>> System.Text.RegularExpressions
<module 'RegularExpressions' (CLS module from System, Version=2.0.0.0, Culture=n
eutral, PublicKeyToken=b77a5c561934e089)>
>>> R = System.Text.RegularExpressions.Regex
>>> r = R('^c')
>>> s = 'abcde'
>>> r.Match(s)
<System.Text.RegularExpressions.Match object at 0x000000000000002B>
>>> m = _
>>> m
<System.Text.RegularExpressions.Match object at 0x000000000000002B>
>>> m.Value
''
>>> m.Success
False
>>> m = r.Match(s, 2, 3)
>>> m.Success
True
>>> m.Value
'c'
>>>

好！匹配成功了。

于是所谓REPL就是像这样的过程：read-eval-print loop。整个过程都不用离开交互式解释器环境，想到啥就写啥，马上就能看到对不对。然后把整个buffer复制出来整理一下，代码就写好了。