I browsed the code shipped in the IronRuby repository and I have two concerns about this code:
- Currently there are some hard links in the code to IronPython, IronRuby, and JScript. I think these should be deleted in favor of a more generic approach, to allow any scripting language implementation to take advantage of the DLR.
- There are compilation directives looking for Silverlight everywhere in the code, which I consider shameful, because what is achieved by compiling against Silverlight is not clear. Also having to use two very different runtimes, one for a regular .NET application, and another for Silverlight, is not very good IMHO. It reminds me of the old times of C pragma hell... Also what are the constrainsts for the hosting scripting language implementation ? As Silverlight is not open-sourced or standardized, what will become of the DLR API when Silverlight will change, a thing which will surely happen ?
Of course, the DLR is still under development, and things will evolve and maybe change in the course of time. But it reminds me of the old Microsoft attitude: propose new tools and libraries, with heavy advertising, declare them as open for everyone, and then tweak them heavily for working with Microsoft implementations only (I don't think that this is a conscious attitude)... This is not a problem for now, but it could become one after the first "official" release, when people will start to use it in their own scripting languages.
4 comments:
Hi, Mithrandir.
I work on the DLR. Any refs you see to the langs from the DLR are absolutely being cleaned out; that is the essence our are architectural layering effort. The DLR will be a pure layer over the CLR for porting general dyn langs.
I can't speak to your perception of heavy advertising on the DLR. Aside from some blog posts (most from teh community) and a couple of press releases around IPy v1, I'm not aware of any big push. We think the DLR should speak for itself, and fortunately many people are finding it pretty interesting.
Since our sources are open, and there's no plan to change that, if anyone did feel we over-slighted towards the languages we have time to port to .NET, anyone can tweak the DLR to help with their language. We don't think anyone will need to do that since our goal is to be a general purpose layer to make it easy to port general dyn langs to .NET.
I'll let the folks building the DLR for Silverlight (so that dyn langs are not constrained to the desktop) speak to why they think having the DLR on Silverlight is cool.
Thanks for taking a look at the DLR.
Cheers,
Billchi
> what is achieved by compiling
> against Silverlight is not clear
The DLR compiles against Silverlight so you can write Silverlight applications in DLR langauge, be it IronRuby, IronPython, or Managed JScript, or another language built on the DLR. Here's the SDK which lets you do this: http://codeplex.com/sdlsdk.
Seems pretty clear to me :)
> There are compilation directives
> looking for Silverlight
> everywhere in the code, which I
> consider shameful
It doesn't make sense to have two different codebases, one for Silverlight and one for the Desktop. However, the platform is different, so the DLR needs to tweak itself depending on what platform it is compiled against.
> Also having to use two very
> different runtimes, one for a
> regular .NET application, and
> another for Silverlight, is not
> very good IMHO
Two different runtimes? DLRs? No, the source code is the same whether you run it on the Desktop or Silverlight. It's just the binaries that are different. This NEEDS to be the case because the .NET binaries in Silverlight are different than on the Desktop. How would you propose doing it?
> Also what are the constrainsts
> for the hosting scripting
> language implementation?
Any language hosted by the DLR can have access to all the runtime functionality of .NET. Is that your question?
> As Silverlight is not open
> sourced or standardized, what
> will become of the DLR API
> when Silverlight will change,
> a thing which will surely
> happen?
Isn't that concern backwards? Silverlight will be publically changing much less often than the DLR, so we need to make sure the DLR always works with the public version of Silverlight.
The DLR is actually part of the daily Silverlight build process, so any build breaks are caught that way; aka the Silverlight team can't break the DLR's build. Also, we run tests on each checkin of the DLR to make sure the Silverlight integration doesn't break.
So, we make sure the DLR always works with the public Silverlight bits, and Silverlight always makes sure their daily builds work with the DLR. Seems pretty fool-proof to me :)
> But it reminds me of the old
> Microsoft attitude: propose new
> tools and libraries, with heavy
> advertising, declare them as
> open for everyone, and then
> tweak them heavily for working
> with Microsoft implementations
> only.
Absolutely not the case here. There is no hidden agenda with the DLR; simply a framework to build languages on .NET. The code will stay open-source, and any language implementation is as important as enabling Microsoft implementations.
This benefits others drastically as well. The DLR is a great test cases for Mono, the open-source .NET Framework implementation. Also, they will be able to just redistribute our binaries with their distribution, which is a huge deal, as Mono had to reimplement the .NET Libraries from scratch because they didn't have the same luxury of redistribution.
That being said, the DLR will always be a framework for building languages on .NET. IronPython/IronRuby are just examples of those languages that you could build using the DLR. The DLR would have been much worse off if we didn't try to build real things with it.
I'd suggest not trying to read into the code searching for human intent, especially since it's not finishied to match any real intent! =P If you have a question about the DLR or the languages, there are plenty of blogs/mailing lists to read, and sending me, John Lam, Bill Chiles, or anyone else email will always be more effective then guessing at what the DLR will be from it's code today.
@billchi: I'm glad that the refs to JRuby or IronPython will be cleaned out. As I said, this comment was based on the actual state of the code.
@billchi and Jimmy Schementi: Of course I know that the directives are there so that apps that use the DLR can work on Silverlight ;-)
What annoys me is that:
1) the directives are everywhere in the code, they should have been in a specific package I think, it would ease maintenance of the software and comprehension of the code IMHO.
2) What exactly is required for DLR apps to work on Silverlight? I know that you will say "nothing in particular", all is handled by the DLR under the hood", but as I saw so many of these directives (pardon me to go back there), I think (or thought) that there maybe more than that. It(s the reason of my comment "what is achieved by compiling against Silverlight is not clear".
Post a Comment