\nmtnwestruby: RubyCLR and Ruby.NET by John Lam
\n17 March 2007\n<\/p>\n
\nJohn works for Microsoft. Before coming to Microsoft, he built the bridge for running Ruby on the CLR (common language runtime).<\/p>\n
\nWhy would anyone want to run Ruby on someone else’s virtual machine? To answer
\nthat, we look at the overlap between what we want to do and what we actually
\ndo at work. It would be nice to maximize that overlap. Many of us want to use
\ndynamic languages, by many of us have to use .NET or Java. Running dynamic
\nlanguages on the one of these VMs helps maximize the overlap.<\/p>\n
\nThe interop layer for Python is going to be fundamentally different than that
\nfor Ruby so that when you write a Python program using .NET libraries, it still
\nfeels like Python code, and when you write Ruby code, using .NET libraries, it
\nstill feels like writing Ruby code.<\/p>\n
\nLutz is an MS employee that worked on Intentional Programming<\/a>, which never went \nDynamic methods are an interesting feature of the CLR in version 2.0. If they’re not going to be used, they get garbage collected. Before 2.0, once you load code, it stays loaded for the lifetime of the VM.<\/p>\n \nInteresting: The CLR supports polymorphic methods based on the return<\/em> type, not jus the arguments. This isn’t a feature that C# supports.<\/p>\n \nThe Ruby to .NET interop is extremely fast — millions of operations per \nJohn used Vim on Windows when he edited code.<\/p>\n
\nanywhere at MS. He created an editor that would parse the AST (abstract syntax
\ntree) and display it in different ways. This idea lives on in the .NET
\nReflector<\/a>, which will decompile .NET assemblies into IL, Visual Basic, C#,
\nDelphi, etc. It’s interesting to use Iron Python to compile code, and use the
\n.NET Reflector to look at the IL.<\/p>\n
\nsecond.<\/p>\n