X
Business

Microsoft to roll out dynamic-language layer for .Net

Microsoft is readying a new software layer designed to allow dynamic languages to integrate more easily and tightly with its .Net Framework, according to sources. Microsoft is aiming to unveil the new technology -- tentatively named "Dynamic Language Runtime" (DLR) -- at its Mix '07 conference, which kicks off on April 30 in Las Vegas.
Written by Mary Jo Foley, Senior Contributing Editor

Microsoft is readying a new software layer designed to allow dynamic languages to integrate more easily and tightly with its .Net Framework, according to sources. Microsoft is aiming to unveil the new technology -- which it may christen as the "Dynamic Language Runtime" (DLR) -- at its Mix '07 conference, which kicks off on April 30 in Las Vegas, sources added.

Implmentations of dynamic languages -- like Ruby, Perl, PHP and Python that already can plug into the .Net Framework exist. However, Microsoft has been working for months to find ways to make .Net more attractive to dynamic-language developers.

"There are Ruby CLR projects, but none of them are complete, and they are very different," said Dion Almaer, with Ajaxian.com. "The Ruby community should embrace a rock solid CLR implementation. Ruby is my favourite language. I love it. It is a dream to develop with. It is a pain to deploy, and embarrassing that the current Ruby implementation is so slow. JRuby is starting to work really well on the JVM (Java Virtual Machine), and having the same on the CLR will be fantastic.

"The key question will be 'can (Ruby on) Rails run on it'? If they ticked that box there will be even more hype," Almaer continued. "PHP? Not as much buzz. PHP runs ok already, and there isn't the same need as we have in the Ruby community."

In recent years, Microsoft hired two dynamic-language pioneers -- Jim Hugunin (of IronPython fame) and John Lam (the creator of RubyCLR). At last year's Lang.Net forum, sponsored by Microsoft, Hugunin, Lam and other Microsoft officials made no bones about Microsoft's interest in making .Net a better dynamic language platform.

Hugunin told Lang.Net attendees that Microsoft intended to ship a set of libraries on top of the CLR that would provide better dynamic-language compatibility. According to an eWEEK story from that event, Hugunin explained Microsoft's intentions this way:

"What we're going to try hard to do is, instead of doing a dynamic language specification, provide a dynamic language library and have guidance on how to use it, because I'm a firm believer in whenever you can capture something in code instead of text it's a far better way to capture it. So we're going to try to capture as much of these guidelines as we can in code."

eWEEK also quoted Lam from the same conference as saying he believed a "reasonably large" percentage of all dynamic languages are fairly similar. "So things like support for arbitrary length integer numbers is something that both Python and Ruby support," he said. "Yet those would be things that you would otherwise have to implement yourself."

Hugunin, who joined Microsoft in 2004, had to do a lot of the integration between Python and the Common Language Runtime (CLR) at the heart of .Net himself when developing IronPython. When Microsoft rolled out IronPython 1.0 last year, Hugunin reminisced:

"IronPython has also striven for deep integration with the CLR. For the implementation this is a great thing as it lets us take advantage of highly-tuned components developed for other languages such as the just-in-time compiler, garbage collector, debugging support, reflection, dynamic loading and more. This integration is also valuable to IronPython developers as it lets them easily use any and all libraries built for .NET from their Python code."

A Microsoft spokeswoman declined to comment on the timing or any other aspect of Microsoft's alleged DLR plans.

Any Ruby or other dynamic-language developers out there interested in seeing Microsoft provide this kind of .Net layer? Would the existence of such a layer make you more interested in developing for Windows -- and any other platforms Microsoft might be targeting with .Net?

Editorial standards