HC: Can you explain what the dynamic language runtime is? And what special features will it provide for developers?
John Allwright: The Dynamic Language Runtime (DLR) is a set of technologies in the .NET Framework that allow dynamic language interoperability. DLR provides interoperability by providing common infrastructure such as Common Hosting Mechanisms, Common Type System and Dynamic Method dispatch. DLR also makes language implementation on CLR much easier by providing the above common compiler infrastructure and allowing languages to focus on user needs.
HC: Microsoft has announced four languages that will ship with the DLR - Python, JavaScript, VB and Ruby. I gather only IronPython and JavaScript will be available initially. Can you give me any idea when the others will appear?
John Allwright: Microsoft is planning to release IronPython and Jscript targeting DLR and intend to release Ruby and Dynamic VB down the road. We don’t have any specific dates to share at this time.
HC: Is the version of VB that will ship later going to be a version of VB.NET, or is it going to be more like VB 6 or something different from both of those versions?
John Allwright: Dynamic VB will be based on VB.NET and both languages will share the same syntax and programming model.
HC: Of all the dynamic languages available, why has Microsoft decided to implement Ruby? After all, PHP has much more of a developer base. Why not IronPHP?
John Allwright: Microsoft is committed in providing a variety of technologies to meet customers’ needs and the Ruby language has proven to be a popular language in the last few years with the community. We are looking at customer demand and industry trends as we always have to provide for customers’ needs.
HC: In an interview on the Channel 9 site, John Lam has said that there is a project to import the existing C-language Ruby libraries into .NET. Does that mean that IronRuby will be 100% compatible with standard Ruby? Bearing in mind that new versions of Ruby are already in development (Ruby 1.9 and Ruby 2.0) and that these will introduce incompatibilities with current versions of Ruby, will IronRuby maintain compatibility over time or will it become a unique ‘dialect’ of the language?
John Allwright: Microsoft is committed to ensuring that we are compliant with standards. For example, with IronPython we worked hard to ensure that we are true to Python as a language while still bringing the benefits of .NET programming to Python user base. Similarly, we intend to respect any Ruby standards.
| John Lam is the creator the RubyCLR Ruby .NET bridge. He is a Program Manager on the Common Language Runtime team at Microsoft and works on the team creating IronRuby - a .NET implementation of the Ruby language. His blog can be found at: http://www.iunknown.com/. |
HC: John Lam also mentions a project to support Rails - something which he concedes is a significant challenge. Is there an actual commitment to support Rails development or is this a case more of “let’s see if this is possible’?
John Allwright: We don’t have anything to announce at this time.
HC: The dynamic language runtime seems to be closely linked with Microsoft’s interactive web graphics technology, Silverlight. Does that imply that it is mainly aimed at Silverlight development or are there ambitions to make it available for general purpose application development too?
John Allwright: While Microsoft is offering support for Silverlight, it isn’t the only intention for the technology. Microsoft will continue to invest in dynamic languages for “general purpose development.”
HC: Can you explain, briefly, how it will be possible to create Silverlight applications using a language such as Ruby or Python. Where, in short, will the programming code ‘live’? Does it run ‘in the browser’, on the server or where?
John Allwright: Today, the programming model involves setting a link between the XAML file and a Ruby or Python code-behind file. This happens via a <x:Code Source=”foo.rb” Type=”text/ruby” /> element in the XAML.
The code-behind file foo.rb is retrieved from the server by the Silverlight runtime. So while the file physically resides on the server (much like default.htm), it is delivered to and executes on the client.
HC: How would I go about writing a Ruby or Python program for Silverlight? What tools are there to help me?
John Allwright: Please visit: http://silverlight.net/QuickStarts/Other/ProgramDlr.aspx.
HC: Finally, what’s so special about dynamic languages anyhow? If I am programming desktop applications in C# or VB or developing for the web using ASP.NET, why should I care about dynamic languages? What features will they give that I don’t already have?
John Allwright: Microsoft’s goal and intent is not to move users from languages like C#, but to give customers options of a variety of languages. Rather as dynamic languages have proven popular with some users, our goal is to provide them the best possible choice on Microsoft platforms.
A dynamic language can inspect and change the structure of objects at runtime. This means that variable types, module names, new classes and functions can be introduced on the fly and leverage, what’s called “metaprogramming” or writing programs that reason about the state of what is executing. As a result, dynamic languages are incredibly flexible and productive, though not typically used for systems programming where the safety and performance of static types is an advantage.
See also:
Dynamic Languages and .NET
Dynamic Languages - Who Needs Them?
Microsoft’s Silverlight Site
Add
to del.icio.us