A number of people are confused by the WPF/PowerShell series and are “asking WTF?”.  Aaron has a blog entry, WPF and PowerShell Series – I don’t get it.  Caywen left a comment on the first in posting saying, “Ugh, I could make a peanut butter and squid sandwich, but that doesn’t mean you should.” (I like the visual on that one!).

I thought I would take a couple of minutes to explain a couple of points and provide some context.

PowerShell is NOT a CLI

I bet that one took you by surprise.  Yup – it’s true PowerShell is not a CLI.  PowerShell is an AUTOMATION technology.  Cmdlets are units of automation.  Jim Truher recently reminded me that my original term for these were Functional Units (FUs) [No prizes for guess why that term got dropped].  The PowerShell engine is an automation engine that then get exposed through various ways:  CLI, API, GUI, late-bound Web Services and at some point – early bound Web Services.

Now clearly we believe that the CLI is a critical piece of this picture.  We’ve had a shockingly bad shell and pathetic command line coverage for decades and I was personally committed to fixing that.  That said, if we just transformed a click click click of the mouse to a click click click of the keyboard – we would not have moved IT forward all that much.  The point of CLIs is that you can AUTOMATE operations which can dramatically lower TOC costs while increasing IT quality through repeatability. 

One of the key turning points in the project came when Mark Brown convinced me that layering GUIs over the automation had to be a top priority in order to become the mainstream of Microsoft.  He pointed out that over the long term this might change but for now, we were a GUI dominated culture and that unless we could help people layer GUIs on top of PowerShell, automation would stay in the backwaters of the company.  From that point on, we really focused on ensuring that the CLI was merely one of many consumers of the API.  A number of groups starting with Exchange have decided that the PowerShell API is their developer story because it provides remoting, security, logging, etc.

TCL/TK

People like to talk about Unix’s influence on PowerShell.  That is absolutely true but I also try to point out the huge influence of unsung super engineers behind VMS/DCL and AS400/CL.  I used to talk about this a lot but for some reason I haven’t in a while but Tcl/TK had a huge influence on me and thus on PowerShell.  John Ousterhout invented Tcl which was an embeddable scripting language.  The first time I saw it, I fell in love.  The language was OK but the architecture just captured my imagination – it just made sense.  John also invented TK which provided a GUI toolkit for TCL.  TK made it simple to throw together quick and dirty GUIs using Tcl. 

Admins and ad hoc developers use Tcl/TK to produce some of the most god-awful looking GUIs and then absolutely LOVE them.  Why?  Because it allows them to easily produce a tool that exactly matches the problem that they have and they way they think about the problem.  WHEN the problem changes, they just edit the file and a couple minutes later, their tool is again perfectly suited to their needs.  Using these GUIs are like slipping on that baseball mitt you’ve been using for last 25 years, it feels like a perfect extension of your body and mind.  Gone are the hideously complex “professional” tools that try to solve everyone’s problems but have so many features that you can’t find the one you need when you need it.  Given the choice, I’ve seen a lot IT Pros choose ugly-but-useful.

PowerShell/WPF

While I love Tcl/TK, I also think we can do a lot better.  The clock has moved forward and we have new technologies available.  WPF is just a glorious UI surface.  It provides a simple surface with incredible compositional power and utility.  WPF’s use of XAML means that we can leverage experienced designers using professional tools to take our quick and dirty tools and put them on par with the best of best.  Because these are scripts, they are easy to share and customize to meet your specific needs.  Advanced scripters can produce PowerShell / WPF scripts for others and then when you get it and decide that you need to add an extra button or two, you have the source code to see how it does what it does and can easily tweak it to meet your needs.  The point I’m making is that with PowerShell/WPF the skill set required to TWEAK a GUI is very much lower than the skill set to CREATE the GUI. 

I predict that the early adopters will pick up PowerShell/WPF, love it, and start producing some amazingly cool (but maybe ugly) GUIs.  After a while, the next layer of people will start tweaking those scripts.  After they’ve done that a couple of times, they’ll have enough examples to start creating their own.  Once that happens, you are going to see an explosion of custom tools.  If you don’t like the tools that MSFT delivers to you, you could try to convince us to change them and then wait a couple years till we re-release them or you could take a couple of hours and write yourself a custom tool that exactly meets your needs.  THAT is going to be fun.

Jeffrey Snover [MSFT]
Windows Management Partner Architect
Visit the Windows PowerShell Team blog at:    http://blogs.msdn.com/PowerShell
Visit the Windows PowerShell ScriptCenter at:  http://www.microsoft.com/technet/scriptcenter/hubs/msh.mspx