PowerShell Runspace vs DLR

Question

With the .NET 4.0 beta now available, and thus the wider availability of the .NET Dynamic Language Runtime, I guess these kinds of topics are going to become "hotter".

I'm confused about the conceptual differences between the DLR and PowerShell. It seems to me that if I want to provide scripting capabilities in my .NET app, I can use the DLR (and so enable scripting in IronPython or IronRuby, or whatever other Iron* languages are available for the DLR), or host a PowerShell Runspace.

What are the pros and cons of each method? Why might I choose one over the other? As a dynamic language itself, and a first-class .NET language at that, why doesn't PowerShell also target the DLR?

Answer 1

I agree, the DLR has and will continue to generate lots of good discussion. PowerShell is not targeted for the DLR. I don’t know why though.

Hosting PowerShell in a .NET app enables the PowerShell object pipeline in the scripting solution which I believe is one key benefit.

There are examples of calling PowerShell from IronPython.

You can also embed IronPython in PowerShell.

IronPython and IronRuby don’t have the same integration to Windows as does PowerShell. It would be great if PowerShell were DLR enabled out of the box.

Answer 2

Doug's answer hits a few key points, but I think the primary reason to use PowerShell as the scripting engine in a .NET application is the fact that PowerShell is becoming the primary management surface across Microsoft applications and will enjoy a greater familiarity among systems administrators who are maintaining your application.

IronPython and IronRuby (as well as anything other language targeted for the DLR) will likely remain more familiar to the developer audience.

Answer 3

In .NET 4.0 the DLR consists of what you can consider "DLR v1.0". This includes the call site caching mechanism, the cross-language interop featuers, and the improvements to the existing LINQ expression trees. These are all features which are very useful for implementing a langauge but not hosting a language.

And that's the missing piece in DLR 1.0 - a shared hosting story for all languages. But we do have a start on that in the form of the hosting APIs we ship on CodePlex w/ DLR and IronPython projects and also w/ IronRuby over on github. Unfortunately we didn't think that we could drive these APIs to being ship quality in the .NET 4.0 timeframe so we didn't include them. In particular we want to get more feedback from other languages like Powershell and even VB and C# to make sure we have the right APIs.

Therefore every language more or less has it's own hosting story except for IronPython and IronRuby right now. But we'd love to see all of this get unified in the future so your users can choose what language to use. But right now there's just not something in the box for Powershell to target.

Answer 4

My take on this is, Microsoft should have developed their Backoffice management interfaces based on the DLR, so that top-notch and already proven languages like Python and Ruby in .NET (or any other language built on the DLR) could be leveraged, as opposed to what I think they did in reinventing the wheel with Powershell. Other than its use to manage infrastructure applications, e.g. Exchange, I don't have an incentive to learn Powershell when there are excellent languages already out there. My .02 cents.