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?

Amadou

Answer 1

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.

Caudex

Answer 2

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.

Susann

I don't really follow why you'd want to do either of those things (calling PowerShell from IronPython, or embed IronPython in PowerShell). I saw a demo of IronRuby calling PowerShell, and whilst it was pretty cool, I couldn't see much use for it. – Amadou

One reason I would call IronPython from PowerShell is to use complex routines already written in Python. Same way I would do it using .NET 4.0. Calling PoSh from Py when I want to leverage functions or system integration points I can't get at easily from IP. – Susann

Answer 3

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.

Godfry

So PowerShell would be the appropriate option for an app that has SysAdmin-type functionality, whilst the DLR languages would be better for aiding power-users in end-user apps? – Amadou

I think PowerShell is more appropriate for an enterprise application that is maintained by systems admins or "power users". Applications where developers will be doing more of the scripting could go either way. – Godfry

That doesn't sound like a good enough reason to me. VB and F# target very different audiences, but use the same runtime. Hopefully MS will follow this example and not artificially segment their technologies. Dino's answer gives us hope :) – Regardless

Don't get me wrong, I have no object to seeing PowerShell hosted on the DLR, but when looking to integrate a scripting language into an application, I think PowerShell should be the language of choice due to the growing base of familiarity with admins, devs, and others. – Godfry

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.

Gonroff

Monad was announced in 2003 and hit v1.0 in 2006. The DLR was announced in 2007 and hit v1.0 in 2010. Contrary to popular belief, the IIS/Exchange/etc teams do not have a time machine. – Regardless

Answer 5

I came to this thread while reading about Dynamic Language Runtime on Wikipedia

I'd like to clarify, but I'm not at 50 reputation yet, even though what I have to say will be of value to the reader soon.

In Doug Finke's comment (Jul 26 '09) there is a link to examples of calling PowerShell from IronPython.

That link is to through codeplex.com, which is already in archive mode, and will be going away on July 1st, 2021. Looking at the link today codeplex points the reader to the github repo for IronPython

Impellent