用Iron-*语言来探索.NET

刚才写代码的时候又是在不停查文档，甚是心烦。一怒，拿出IronPython，类似这样：

IronPython 2.6 Beta DEBUG (2.6.0.1) on .NET 2.0.50727.3082
Type "help", "copyright", "credits" or "license" for more information.
>>> import clr
>>> clr.AddReference('System')
>>> import System
>>> System
<module 'System' (CLS module, 2 assemblies loaded)>
>>> R = System.Text.RegularExpressions.Regex
>>> r = R('abc')
>>> s = '123abcd456'
>>> dir(r)
['CacheSize', 'CompileToAssembly', 'Equals', 'Escape', 'GetGroupNames', 'GetGroupNumbers', 'GetHashCode', 'GetObjectData', 'GetType', 'GroupNameFromNumber', 'GroupNumberFromName', 'InitializeReferences', 'IsMatch', 'Match', 'Matches', 'MemberwiseClone', 'Options', 'ReferenceEquals', 'Replace', 'RightToLeft', 'Split', 'ToString', 'Unescape', 'UseOptionC', 'UseOptionR', '__class__', '__delattr__', '__doc__', '__format__', '__getattribute__', '__hash__', '__init__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__str__', '__subclasshook__', 'capnames', 'caps', 'capsize', 'capslist', 'factory', 'pattern', 'roptions']
>>> m = r.Match(s)
>>> dir(m)
['Captures', 'Empty', 'Equals', 'GetHashCode', 'GetType', 'Groups', 'Index', 'Length', 'MemberwiseClone', 'NextMatch', 'ReferenceEquals', 'Result', 'Success', 'Synchronized', 'ToString', 'Value', '__class__', '__delattr__', '__doc__', '__format__', '__getattribute__', '__hash__', '__init__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__str__', '__subclasshook__']
>>> m.Success
True
>>> m.Index
3
>>> m.ToString()
'abc'
>>>

我可不想为了印证记忆中对.NET的正则表达式的模糊印象而去写C#代码->编译->运行->发现错误->修改->再编译->……这种时候用IronPython正顺手。

使用IronPython时，打开.NET大门的方法就是神奇的import clr。接下来通过clr对象来添加.NET程序集的引用，就可以开始用.NET的类库了（mscorlib是默认引入的）。整个使用体验相当流畅，刚启动解释器的时候比较卡的时间也减少了（虽然还是比CPython刚启动时慢，没办法）。

=====================================================================

我这IronPython是从CodePlex的DLR项目编译出来的，同一个Debug目录下还有IronRuby 0.4.0.0，于是干脆用IronRuby也试一次：

IronRuby 0.4.0.0 on .NET 2.0.50727.3082
Copyright (c) Microsoft Corporation. All rights reserved.

>>> require 'mscorlib'
=> true
>>> System::Text::RegularExpressions
=> System::Text::RegularExpressions
>>> R = System::Text::RegularExpressions::Regex
=> System::Text::RegularExpressions::Regex
>>> r = R.new 'abc'
=> abc
>>> s = '123abcd456'
=> "123abcd456"
>>> r.methods.sort
=> ["==", "===", "=~", "__id__", "__send__", "class", "clone", "display", "dup", "eql?", "equal?", "extend", "freeze", "frozen?", "hash", "id", "inspect", "instance_eval", "instance_of?", "instance_variable_defined?", "instance_variable_get", "instance_variable_set", "instance_variables", "is_a?", "kind_of?", "method", "methods", "nil?", "object_id", "private_methods", "protected_methods", "public_methods", "respond_to?", "send", "singleton_methods", "taint", "tainted?", "to_a", "to_s", "type", "untaint"]
>>> r.class
=> System::Text::RegularExpressions::Regex
>>> m = r.match s
=> abc
>>> m.class
=> System::Text::RegularExpressions::Match
>>> m.methods.sort
=> ["==", "===", "=~", "__id__", "__send__", "class", "clone", "display", "dup", "eql?", "equal?", "extend", "freeze", "frozen?", "hash", "id", "inspect", "instance_eval", "instance_of?", "instance_variable_defined?", "instance_variable_get", "instance_variable_set", "instance_variables", "is_a?", "kind_of?", "method", "methods", "nil?", "object_id", "private_methods", "protected_methods", "public_methods", "respond_to?", "send", "singleton_methods", "taint", "tainted?", "to_a", "to_s", "type", "untaint"]
>>> m.index
=> 3
>>> m.length
=> 3
>>> m.success
=> true
>>> m.to_s
=> "abc"
>>>

Well……看来不太对劲。虽然程序集也正确引入了，类型和方法也都正确加载执行了，但methods返回的方法列表里没有.NET的方法。这真够郁闷的，以前的版本明明可以的啊。好一段时间没玩IronRuby，这.NET interop怎么好像退化了 OTL

Anyway。使用IronRuby时，打开.NET大门的神奇方法是require 'mscorlib'。然后可以用强名称来引入别的.NET程序集，而标准库里的一些程序集是默认引入的，例如System.dll，所以上面我没有显式引入这个程序集。然后.NET命名空间要跟随Ruby代码习惯用::来分隔，基本上没别的大问题了。需要使用.NET的可变长度参数的方法时，可以对Ruby数组调用to_clr_array方法，跟JRuby非常类似。

=====================================================================

就目前而言，IronPython的完成度远在IronRuby之上。如果你也想现在就用Iron-*语言来探索.NET的话，我会推荐IronPython。不过IronPython 2.6现在还是暂时别用，bug多多……过不久等2.6出正式版之后再用吧～现在用IronPython 2.0.1稳定。
至于一个不是出自微软的Iron-*语言，IronScheme，它使用的DLR是非常老的版本，性能肯定是比不过微软的两个Iron-*语言。不过就其对R6RS的实现来说，它还是值得一试的，毕竟“实现了什么语义”比起“如何实现”更值得一般程序员所关注。

用 mono shell如何，可以用来跑linq

这和我用jython，差不多，大多数时候就是用那个 dir的

需要LINQ的时候用Mono的CSharpRepl确实美妙，外加还可以绘图啊什么的，Miguel真是高啊～
不过单纯是想查看类库的API，确认其行为时，还是Python（和Ruby）方便些。这些语言的语法，特别是做反射的时候很方便。.GetType().GetMethods()还是嫌麻烦了 =v=


嗯嗯，dir美啊 T T
最近Jython的项目维护者Frank Wierzbicki在Lang.NET 2009上介绍了项目状况。现在Jython还是采用只编译，不解释的执行方式，总是把Python源码编译为JVM字节码后才执行。这种方式影响到启动速度，近期IronPython已经转用解释到编译的渐变过程；Jython还在等DVM的成果出来……

说到linq，今天在想如何从交错数组里选出包含输入数组的那一行，同样心烦

呵呵，这就是一家公司做的好处，决策的过程要远好于开源社区。唯一的问题，就是公司的战略方向是否正确了。至少，看起来微软的战略方向还是比较偏向于动态语言的。

Da Vinci Machine/JDK7（注意我不是说Java7）也是在“一家公司”，也就是Sun的控制下。
我觉得Jython在许多方面进度落后是受到关注它并且向其贡献代码的人不够多，长时间只有一两个人在维护，现在还活着就已经不简单了。这是Colin老大说到的一方面。但我们可以看到，就Jython现在还活着的部分看，其前端ANTLR、后端ASM、底下的执行引擎JVM、与外部交互用的JNA，都是开源的（JVM至少“有开源的选择”）。没有开源社区的间接支持，Jython现在肯定已经挂了。
另一方面，Jython其实是受到Java/JVM的原始设计拖累而使得许多事情不好办。DVM正是解决这种“拖累”的实验项目。现在可以肯定的说，MethodHandle进入到JDK7了，而它与.NET一直有的delegate是如此的相似……呵呵，不看不知道，一看吓一跳。
当JVM变得更容易接受Java以外的其它语言时，JVM平台上的这些语言项目肯定会得到更好的发展的。

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


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

如果说integration is innovation的话，那Java的innovation还没死。点子的来源也不是.NET一个，而是众多主流语言实现。
例如DVM里还有immediate wrappers types，这就是LISP、Ruby等都有的fixnum，其实就是tagged pointer的一种应用。这玩儿在CLR里还没有，也有很多人怨念着呢。
DVM里的runtime support for multimethods，也就是方法的多重分发，也是CLR还不支持的东西。VS2010 CTP里的C# 4通过dynamic特性支持了multimethod，但后来又决定缩回去了，采用更静态的绑定方式。
Continuation支持也是……这个我很是怨念，CLR没有内建的continuation支持。

当然，DVM里可以算得上借鉴.NET的东西也不少：MethodHandle（delegate）、invokedynamic（calli）、AnonymousClass（DynamicMethod）、TailCall（.tail），之类的。现在语言发展的大趋势就是互相借鉴，这是好事～

有人很有爱的在.NET上实现了一个叫Tycho的东东，基本上是一个Perl 6的实现。
Iron-*嘛，没足够的资源所以只能把关注点集中在最热的几个上面了。结果就是IronPython、IronRuby、VBx（已死）、Managed JScript（生死未卜）。