What is PowerShell? No Really, What is it?

What is PowerShell?

If you're a programmer or script writer (aka "scripter" aka "script kiddie"), you've probably heard a lot about Microsoft PowerShell.  You've probably sniffed out a ton of web sites that offer articles and code snippets and whatnot.  You may have seen online tutorials and webcasts that explain what it is and what it does and how incredibly powerful and useful it is.  It is.

But really: what is it?

When someone says they're "using PowerShell", or “doing PowerShell scripts”, what do they really mean?

Are they making PS1 scripts?
Are they making CMDlets?
Are they running script code at the PS command prompt?

The issue I see is that while these may seem like one thing, they're not.  Not technically.  Not even intrinsically. These are three distinct avenues.

I divide PowerShell scripting into three groups myself.  You may disagree, but this is how I see the world, and I'm the one writing this pile of rubbish of which you are reading (I'll save that for another day).  On with it then...

Script Writers - Stuff PowerShell statements into code files with a .PS1 extension on them and use them.  Maybe it’s just typing in raw statements and running them piecemeal.

CMDlet Users - These are folks that download CMDlets and use them.  Either directly from a command shell, or from within other script code statements.  In either case, these are not people who typically write their own CMDlets.  Oftentimes this is very much like downloading a traditional .exe utility and using it.

CMDLet Writers - These are folks who are typically more familiar with .NET programming languages than your average "System Administrator".  They prefer to wrap their statements and expressions with abundant error trapping and handling statements and then tape the box shut and put a nice, pretty label on the outside for you to get in the mail and use.

This latter group I do not consider "script writers".  They are actually programmers in the traditional, customary sense of that word.  "Scripting" as I've been programmed to understand it (pardon the pun) from my years at college, implies a sense of quick-and-dirty problem solving.  Less (if any) emphasis on efficiency or performance, and more on speed and effectively “quick” results.

Need to make a change on 5,000 computers "quick"?  Script it.  Need to make 100,000 user accounts - now?  Script it.  Need to change the name of 500 user groups and re-organized the users between them, and do it by 4:00 today?  Script it.  Need to build a system to automate the collection of detailed inventory with incredible granularity control and fine tuned to prevent client-side or network performance overhead problems?  Write an app and compile it.

This is not a “Windows thing” either.  Ask any UNIX admin when they consider writing a compiled C/C++ or Java application versus a script in any of a dozen languages.  You may be surprised by their answer.

The difference between writing a PowerShell script which does some sequential piping of object results, versus one that simply calls CMDlets with parameters, versus writing those CMDlets is enormously different, or most often is enormously different.  Does it "have" to be “enormously different”?  No.  Someone could write a CMDlet that does something extremely trivial, but why would they bother?  The idea of a CMDlet is efficiency.  Efficiency of reuse, performance and simplicity (to the user of the cmdlet)

Is a typical sys-admin going to bother with overriding classes and making public and private attributes for a given class instance?  NO.  Not unless that sys-admin has nothing else to do and is trying to learn how to "program".  In that case, either you have hired one too many sys-admins or everything has been sufficiently automated that he/she no longer has any IT challenges to conquer.

This is where I get a little frustrated at the generic reference to PowerShell development as if it is all "one thing".  It's not.  The way I see it, you're either a "PowerShell Programmer", a "PowerShell Scripter" or a "PowerShell User".  Maybe the blurred distinctions are a good thing, but it does have a confusing downside.  So before you start tossing out the generic one-size-fits-all references, maybe it's time to stop and consider more accurate references to make things clearer?  Just a thought.