Ruby in SilverLight
|
|
I have been reviewing the various sessions from MIX07 and watched the following session: “DEV02 – Just Glue It! Ruby and the DLR in Silverlight” Has anyone else seen this? Is this a reason to stick with .net? |
|
|
I’ve written a bit about this here: http://www.bitwisemag.com/2/Dynamic-Languages-and-NET As you might imagine, since we produce a Ruby IDE for Visual Studio, we are keeping a close eye on developments ;-) Currently MS IronRuby is in a very early stage of development and it’s not really possible to form a clear opinion on its future. Initial efforts are aimed at providing integration with Silverlight (MS’s new ‘Flash-killer’) as one of several scripting languages (though I suspect that VB might ultimately be promoted more heavily than Ruby). More interesting is the Dynamic Language Runtime (DLR) which will provide better support for dynamic languages in general under the CLR. I’m probably not giving away any secrets when I tell you that Ruby + .NET is of considerable interest to us whether or not IronRuby ever develops into a mature platform. In my view, Ruby (or something very similar) is likely to start to gain a presence on .NET within the next 2 to 3 years, just as it will (via JRuby) on Java. At any rate, the current (1.8x) Ruby interpreter is obviously nearing the end of its days and the ‘next generation’ of Ruby is likely to fragment over several platforms – in all probability giving rise to some platform-specific variants. It would be very surprising if .NET didn’t emerge as one of the principal platforms. best wishes Huw |
|
|
Personally, I would be surprised if Microsoft gets it right. The DLR seems exciting to everyone, but it’s slightly amazing it wasn’t part of .NET 1.1 – dynamically-typed languages have been around for a long time. If anything, Microsoft realized they’re going to lose a lot of money if people can’t develop Rails sites in Visual Studio, and that finally motivated them. Even then, they had to go out and bribe John Lam to join Microsoft so they could get the Ruby piece done. I expect Microsoft to “embrace and extend” Ruby as they do with everything else, adding in Microsoft-specific features to the language to try to keep people stuck on Microsoft products. That strategy has been a successful one for them in the past (witness all the IE-specific features that existed in IE 4.0 and IE 5.0, even 6.0). So I fear that Huw is right, the time is coming when Ruby will suffer a Java fate – a “standard” that has so many “flavors” that there ceases to be any standard. And the influence of the Java community on Ruby (e.g. jRuby, etc.) is getting scary. Ruby seems to be falling into the hands of Java and .NET. Here’s hoping Matz and company produce a Ruby 2.0 that will right the ship and provide a standard against which all others can be compared. As for SapphireSteel, it’s the best Ruby IDE for VS users, and I expect it will be for some time to come. As nice as VS seems to be, Microsoft moves too slowly to keep up with any third-party developer that’s serious about their customers. |
|
|
Jeff, I appreciate your thoughts but would also encourage the forum readers to look at what the implementers have to say about the Ruby support in the dynamic language runtime. Jim Hugunin and John Lam are both language purists and with the work done to ensure that Python stayed pure to the language, that mantra is followed in the Ruby support. In fact, one thing John showed in that MIX session was an implementation design they were working on—and he writes (http://www.iunknown.com/2007/05/modularity_ruby.html) about how they have already received feedback it wasn’t palatable. I think the right people are working on the right project…Microsoft expects the Ruby community to tell them what they are doing right/wrong. I’d comment to Jim (http://blogs.msdn.com/hugunin) and John (http://www.iunknown.com) to let them know your thoughts. |
|
|
I agree. I think John Lam seems to want to do a ‘pure’ Ruby implementation. In the medium-to-longterm, however, I think “one flavour Ruby” is doomed. If IronRuby and JRuby (and others) are ‘pure(ish)’ Ruby 1.8, is it really likely that when Matz changes the language (they are already calling Ruby 2.0 a ‘new language’) everyone with Ruby implementations on other platforms is going to rewrite from scratch to maintain 100% compatibility with Ruby 2.0 while simultaneously breaking compatibility with programs written for the previous implementation? I very much doubt that. |