Tag Archives: dlr

Silverlight and the DLR

Microsoft has announced that it is embedding a version of the CLR into their Silverlight RIA technology. Blogging machine Ryan Stewart had some of the initial details, and Sam Gentile has a good pile of links. The CLR enabled version of Silverlight will run inside Firefox (both on Windows and OS X) and inside Safari. This is a good step at cross platform support, but the omission of Linux, while not surprising, reduces the reach of Silverlight versus Flash or regular AJAX. Also, it appears that there are no Mac development tools for Silverlight, although presumably there is always text editors.

DLR
The most interesting part of the whole business is the Dynamic Language Runtime, which is the project that Jim Huginin has been working on since he arrived at Microsoft. The DLR currently supports JavaScript, a dynamic version of Visual Basic, IronPython, and IronRuby. John Lam’s work at Microsoft also appears to be paying off. eWeek had three good articles on DLR technology, and all three articles include conversations with Jim and John. It’s nice / interesting to see that two people could have a large impact on Microsoft. The DLR is being made available under a BSD style license. While I have to give props to Microsoft for choosing an unrestrictive license, I’d point out that a license is not a governance system, and while the DLR might technically be open source, the “Core CLR” definitely is not, and neither is the XAML portion of the Silverlight runtime — no surprise there. I wonder if we will be seeing a port of the DLR on top of Mono. I also wonder if IronRuby can run Rails, although that seems like a weird thing to want to do inside of Silverlight.

Linq
Another part which I find interesting is the inclusion of Linq as part of the Core CLR. I like Linq, and if Microsoft is going to try to define a new platform for inside the browser, I’m happy that they’re including Linq as part of the core.

Impacts
Here are some of the potential impacts of this announcement:

Since Silverlight will include the CLR, it will benefit from the CLR JIT and garbage collector, which together with Mozilla’s Tamarin, will raise the bar for JavaScript performance in the browser. It’s unclear whether regular AJAX apps running in a Silverlight enhanced browser would beneft from CLR acceleration of Javascript. I’m in favor of the browser vendors getting into a Javascript performance race with each other.

Allowing people to write browser side applications in multiple languages fragments the technology on the browser side. You could argue that the benefits of either IronPython or IronRuby are sufficiently large over Javascript that such fragmentation is ok. I’m not as sure that this is a good thing.

If there is significant uptake of IronPython or IronRuby for Silverlight development, that could have interesting impacts on the Python and Ruby communities. The Ruby community is already dealing with a proliferation of different Ruby runtimes, so there probably isn’t much new there other than a change in the mix of adoption of the various runtimes. On the Python side, its less clear, since the CPython implementation is the most heavily used.

The inclusion of facilities like Linq will boost the semantic level of the platform running in the browser. Granted, it only does that for Silverlight, but I hope that this puts some pressure on the other players to provide more leverage in the platform. If we are going to be building much richer applications inside the browser, we are going to need all the help that we can get.

So what?
In the end, though, I probably won’t be doing much with Silverlight, for the same reasons that I’ve written about before. The technology has definitely gotten stronger, but the other issues haven’t really changed much: there are no tools for the Mac or Linux, and as far as influencing the technology, you’re just standing outside the Big House, pressing your nose up against the window.