Automating the world one-liner at a time…
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.
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.
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 ArchitectVisit the Windows PowerShell Team blog at: http://blogs.msdn.com/PowerShellVisit the Windows PowerShell ScriptCenter at: http://www.microsoft.com/technet/scriptcenter/hubs/msh.mspx
PingBack from http://www.windows-vista.luiscorreia.com/powershell-and-wpf-wtf/
I for one think enabling GUI functionality PowerShell makes perfect sense. The lack of a standard for creating GUIs was something that I always thought that Windows Scripting Host was severely lacking. Kudos for recognizing the need.
OTOH, you could make it a little easier and less verbose to create a GUI than having to know essentially the same verbose syntax that a C# developer uses. How about implementing some shortcuts for the more common patterns?
I'm sure it is just a matter of time before someone does create these helper functions or libraries.
This sounds more like something the .NET Framework dev team would do versus the PoSH dev team though.
Bruce Payette's book offers the framework for such a library for the older Windows.Forms.
> OTOH, you could make it a little easier and less verbose to create a GUI than having to know essentially the same verbose syntax that a C# developer uses. How about implementing some shortcuts for the more common patterns?
I don't know if we have the time to do anything like this for V2 but I agree 100%.
It's Aaron, not Arron. :)
You know, it all starts with the naming.
PowerShell. Shell -- command line.
Again, unless I'm missing the point of the series, it feels like it's still backwards. A GUI can take advantage of a cmdlet (again, maybe not the best naming), but why is a cmdlet building in a GUI? I think of these cmdlets as being business logic, but now a user interface is being constructed inside?
None of the WPF designer or developer tools work out-of-the-box with the scripting language.
Still feels backwards to me.
@Marco: Thanks for the reply. But let me clarify, I was asking for shortcuts for common patterns to be included in the core, as opposed to having someone write them. Those in the core getting written about in books, on blogs, etc. and those that someone just writes are typically in the periphery. For them to exist is not so interesting to me; for them to exist AND be standard is what interests me.
@jps: I don't know if we have the time to do anything like this for V2 but I agree 100%.
That's all I was hoping to hear. You guys are the best (within MS)! :-)
@Aaron: I think of these cmdlets as being business logic, but now a user interface is being constructed inside?
Really, what's wrong with a GUI inside? It's not the best for enterprise architecture, but it's damn good for little tools to just get simple and repetitive things done all w/o having to invest more time into the development than the problem would take to solve manually.
@aaron: consider the problem of visualization. What if you created a set of cmdlets that allowed, say, a computer algebra system a la Maple or Mathematica?
Perhaps you need a way to visualize a data set, or maybe you're a sysadmin who wants to bring up a live diagram of the network.
Simply limiting scripting to business logic neglects that computers, from the beginning, also had to report their data, and scripting has long been involved in creating them.
The first thing that I thought of when I stumbled across the WPF series was Tcl/Tk. I recently looked at the Tile package, which removed the ugly stick Tk's been hauling around for a while:
Lately I've been thinking about using it to create a GUI to solve a particular problem at work. This series got me thinking: I'll bet I can do this a lot faster if I used XAML to define the GUI instead. Ship V2 so I can find out!