I've been trying to making a coherent story out of the news too. The prior plugin had no logic engine of its own, and relied on each browser's JavaScript engine. This got a new beta yesterday. But there was also an alpha which had its own MS logic engine ("CLR" moniker), and which is above 5M on Win, 10M on Mac.

Additionally, there was mention of a future DRL which sits atop the CLR, which apparently does local parsing of instructions transmitted to the client in Python or Ruby (note to reporters: ya gotta say where "the runtime" runs!). Its addition to the download size is not yet determined. This DLR also had news of "being opensource", although I'm not sure how you'd get your changes installed on someone else's machines.

One other angle I haven't seen discussed is the object model you'd be programming against... it might be *possible* to take stock Ruby and run it in a future clientside browser plugin, but what would it do, unless it were written to control some specific elements in the Microsoft visual display? I haven't seen many people trying to ask these questions yet.

Overall, it's more announcements, more wait-and-see. Feels like last year's MIX event to me, everything's still off in the future.

jd/adobe

Posted by John Dowdell on May 01, 2007 at 09:59 AM UTC - 6 hrs

That's quite true - I had assumed the DLR would be part of the "tiny CLR" and that would be a plugin for the brower, like Flash is today. Then, I was thinking you could run write Ruby as Ruby but have access to whatever packages (or namespaces, in the .NET world I guess) were included in the "tiny CLR," as if they were in the core or standard APIs. Like you, I also assumed it would be manipulating elements in the MS visual display.

Of course, I have no basis to have made these assumptions, and I'm not as familiar with .NET as I might otherwise be.

Like you say, it is just a bunch of wait-and-see at the moment, and there's been so much news lately (some of it conflicting, from what I can tell) that its hard to tell what is going on exactly.

Posted by Sam on May 01, 2007 at 10:32 AM UTC - 6 hrs

Not to be the conspiracy theory nutjob, but if creating its own JVM proved an effective weapon against the threat of Java applets in the late 90's, couldn't this be seen as how Microsoft intends to take on Ruby, Python, and the growth of other languages?

"I wrote my domain objects in Ruby, so it worked with MSFT DLR Ruby 1.0, but then 1.1 came out, and some of the collections code requires MSFT specific tweaks, so it's broken elsewhere..."

Posted by Joe Rinehart on May 01, 2007 at 12:54 PM UTC - 6 hrs

Joe: I wouldn't doubt if they see dynamic languages to be the future, as many people are leaning in that direction (myself, at least). But, I don't know if its own VM was the threat to applets, or if applets were the threat to themselves. =)

As for writing in Ruby targeting the DLR, I can see that becoming a problem if it works how I envision it- mostly because I'm seeing using MS specific libraries in a Ruby context. But, I haven't seen it or how its done, so of course I can't speak to that. Maybe someone with IronPython experience can tell us how portable code is back and forth. Again, I would expect Python written for the original to work on DLR, but probably not the other way around.

And, here's some more info on the DLR from Jim Hugunin that might be worth a read: http://blogs.msdn.com/hugunin/archive/2007/04/30/a...

Posted by Sam on May 01, 2007 at 05:02 PM UTC - 6 hrs

A comment on the portability: The main thing you need to remember to do is not use platform-specific libraries. On the CPython side of things that means not using dll-extension libraries. CPython includes some of those that IronPython doesn't implement (bz2 probably the most egregious, tcl and tk, and several _* modules like _hashlib, _elementtree, _bsddb, etc...). We basically add these on-demand and occasionally someone in the community will implement their own.

From the IronPython side it has a "clr" module and allows you to import namespaces from assemblies. So if you stay away from either of those then you can write perfectly compatible code. After importing these into a module we'll also make it so the module has access to standard .NET methods. Before doing that we assume you want pure Python semantics so for example you can't call .Trim on a string until importing something from .NET.

You can also do the traditional Pythonism and wrap this in a module. Then you can check sys.platform == 'cli' and use .NET namespaces or other things on other platforms (e.g. you could also check for java for Jython or win32 for win32 CPython, etc...).

Finally we run a large number of tests from the standard library to ensure we conform in addition to our own test suite. Our goal is to have great compatibility all around - we've targetted core language semantics very closely and the modules have traditionally had more issues.

Posted by Dino Viehland on May 01, 2007 at 05:48 PM UTC - 6 hrs

Dino: Thanks for helping clarify how all that works.

You mentioned, "the main thing you need to remember to do is not use platform-specific libraries."

I had meant to make that more clear when I said "I would expect Python written for the original to work on DLR, but probably not the other way around." In general, programmers aren't known for not doing things they're not supposed to do when reaching for the goals they want to reach, such as doing as you suggested. =) I fully realize that's not the fault of IronPython for giving us the power to do it. The saying "with great power comes great responsibility" rings true here.

In any case, it sounds like you guys are doing some cool things. I'll have to give IronPython a shot sometime, and IronRuby as well. It sounds like with the DLR you've beat Sun to the punch, as I was just reading about how Sun plans to natively support dynamic languages, and to my knowledge, they have not released anything (though, I could be wrong).

One last question: can you speak to how any of that will change / has changed with it running on the DLR (my understanding is that 2.0 will be running on it, but currently it isn't -- is that even correct?)

I'm highly interested in this, so maybe its time for a .NET category on the blog. =)

Posted by Sam on May 02, 2007 at 06:50 AM UTC - 6 hrs