Microsoft's
Dynamic Language Runtime shipped its first Beta a few days ago. For those who don't know, the DLR is Microsoft's effort to bring support for
Dynamic Languages on top of the
.NET Virtual Machine. Catch it ? Dynamic Languages are the rage today, and .NET and Java now want to catch the trend on their respective VMs. The DLR initially lived in the
IronPython codebase (IronPython is the .NET implementation of Python), but it now seems to live on its own.
I
expressed some concerns about the state of the ongoing work for the DLR some time ago, and some people from the DLR team tried to answer. These concerns were (in short):
- A lot of hard coded references to IronPython and IronRuby, the currently two Microsoft project heavily leveraging the DLR
- Compilation directives looking for Silverlight everywhere in the code
In short, my concern was that the DLR may be too tied to Microsoft implementations specificities, and not really language / or implementation agnostic. I know this is not what Microsoft folks want, but all this just adds complex interwoven ties between parts of Microsoft's offerings that should never meet explicitly ;-). People already
encounter repeated problems when trying to build IronRuby under
Mono, this can only make it worse.
And sadly, when looking through the code, I saw as many Silverlight directives as before. And now, some new
LINQ references that were not there before. My problem is not that there are dependencies, it's the fact that they seem to be everywhere in the code. I would greatly prefer to see them limited to a specific module in the code, and I'm worried about these new LINQ dependencies. Plus why compilation directives ? Why is it not possible to limit Silverlight specificities to a separated assembly (preferably implementing an interface with a default implementation), and link to this assembly at runtime ? And why Silverlight is so different from the core .NET runtime ?
Update 6/12/2008: Since Bill Chiles comment, I downloaded the code (before I just browsed in the codebase through the web access), and here is what I discovered:
- 139 files with ifdefs for SILVERLIGHT in the code (that makes roughly 25% of the files), mostly in the Core package (71 files in Core and its subpackages), but widespreaded in the codebase.
- 4 files referencing IronRuby, and 12 referencing IronPython !!! Again these are not limited to a particular package in the code, and I really wonder why there are more references to IronPython than IronRuby. In short, I don't know how anybody would be able to use the DLR for a new scripting language without changing the core DLR code
- 302 files using Linq specific libraries and/or functions.
I'm sorry to say that it does not look to me as a well-designed code IMHO (for the moment). I would very much like to see:
- ALL specific references to IronRuby and IronPython removed.
- If it's not possible to avoid ifdefs for SILVERLIGHT (I hate ifdefs in general) at all, then limit them to a specific package in the code, and access these by a neutral interface
- I really don't think that the idea to put Linq there was very good to begin with, but at least I would prefer to see Linq references limited to a Linq-specific package
Update 2 (7/12/2008): About references to IronRuby and IronPython, I maybe was a tad too fast to criticize (I still stick to my previous point with Silverlight references). There's only one file with a real hard reference to IronPython, IronRuby, and JScript. I really don't know why the
PlatformAdaptationLayer class needs to explicitly add assembly mappings for these implementations. Why not leaving it to each implementation to add its own mappings ? How a new scripting language will be able to add its own mappings without changing the
PlatformAdaptationLayer code ?
But there's still a lot of comments about IronPython in the code, which makes me think that some of the DLR code is still tied to this implementation. However, this should improve in the future. Except that... I now saw another file with an explicit new compilation directive (argghhh !!) referencing
IRONPYTHON_WINDOW. That looks bad to me.
And to show my point about the SILVERLIGHT references, let's use one simple example, again in the
PlatformAdaptationLayer class. The code is:
public virtual bool DirectoryExists(string path) {
#if !SILVERLIGHT
return Directory.Exists(path);
#else
throw new NotImplementedException();
#endif
}
OK I think its because Silverlight impose limitations on access to the File system (sandboxing), so you may not access directories at will. I have no problem with that limitation, but... It would have been very easy to access to a platform-specific assembly here, instead of using these dreadful compilation directives. The Windows platform assembly would simply return
Directory.Exists(path), the Silverlight assembly would return the
NotImplementedException. This would have been way better IMHO.
