Don't call it a (power)shell script

In the admin-tools space, my own language background centered around tcsh/csh/bash scripts (mainly calling the usual suspects of sed, awk, grep, cut, etc) and occasional C at first, then moving a lot into perl once perl5 was starting to take shape. 

Perl was a bit more "real" to me in that it had better and richer constructs, ability to define types, an OOP syntax (even if arguably not a great one), and (key, IMHO) the ability to pass around "real" data structures instead of things like lines of text, or temp files, or exit codes, or whatever.  Yeah, trying to grok a hash of arrays of hashes could make things tricky (and this is when I really started to grow a strong desire for compile-time checking), but if you "use strict" and -w, generally you could keep yourself sane.

Those *.pl files were considered to be "perl scripts".  While it was technically possible to use it as such, no one considered perl to be a shell, so it didn't make sense to call those things shell scripts.

A little later, Python and then Ruby come down the pipe - they go even further, with yet better constructs (I really like Ruby mixins as an alternative to multiple inheritance).  It was a more "real" OOP situation - "real" classes, inheritance, polymorphism, all the usual benefits of OO as you'd get from C++/Java/etc.  The programs weren't typically explicitly compiled, so calling them "python scripts" or "ruby scripts" was fine, but even with the existence of things like IRB, people still didn't consider either of them to be a shell.  They were programming languages that a couple of people on the planet were geeky enough to use as shells. 

No one called those programs shell scripts, either.

Months (years?) ago, we had a new entity on the stage - the "Monad script" - as a new language, engine, and yes, shell, based on .NET, emerged (sorry, I get paid per comma, you know).  It immediately felt like that same category of program as ruby and python (and these days, Boo).  You didn't need to pre-compile it with csc.exe or anything like that, but it still gave you more "real programming constructs" than things like "ordinary" shell scripts.  The strong typing and ability to pass around real objects over pipelines was amazing and a huge leap forward.

However, when The Rename happened, Monad became Windows PowerShell, and I became conflicted.

Sure, I recognize, accept, and applaud that the team's 1.0 target is absolutely the Windows admin.  That's exactly the right decision on their part, and the trickle-down effect on other ecosystems (like Exchange and IIS already, SQL and TFS in the future, etc) will have huge positive impacts across the entire set of customers (not to mention product teams :) for decades to come.

But now we don't have the "Monad script" any more.  The legal team would say we have "Windows PowerShell scripts" but realistically, "PowerShell scripts".  Somewhat thankfully, in the (admittedly unix-y side of the) admin world, "ps" already has a meaning as a tool to list processes, so the only further shortening I could see would be if PoSh catches on as an abbreviation (and I hope it doesn't :)

What's so bad about "PowerShell scripts"?  That's right - it's got "shell script" right in the name - and that's what makes me cringe.

I (admittedly somewhat pessimistically) see people walking into the PowerShell world and thinking of it as "oh, the Windows world finally got something like bash/tcsh/zsh/ksh/etc".  They'd potentially assume that the PowerShell scripts they hear about are on the order of those same beasts in terms of capability, robustness, programming constructs, manageability, etc.  Fortunately, nothing could be further from the truth :)

I'd even happily believe that my thoughts were just being pessimistic, but I've already had conversations with people that have come to the table with exactly that kind of impression - that if you wanted to do Real Code within PowerShell, it was writing a cmdlet in C# - if you just wrote a script, it was only going to be the equivalent of cmd.exe's for loop over dir /s /b or the like - lots of text-parsing and pain, checking things like %ERRORLEVEL% and trying to fake something that acted like a Real Program.

I really cringe to think that PowerShell scripts may "get off on the wrong foot" with a certain class of people just based on the moniker. 

Yes, cmdlets absolutely have their place, and they provide the ability to either create new functionality that didn't already exist, or take functionality that already existed, but in a developer-centric form (like an object model), and wrap it in a form that's more admin- and interactive-friendly.

Is this in any way going to have an actual negative effect on the uptake of PowerShell?  I don't believe so.  I just hope that people, admins/programmers/whoever included, don't shy away from PowerShell scripts as they don't seem "real".  If you were willing to write a program in Ruby/Python/Boo/etc., then for the most part, you should absolutely be willing to write it in PowerShell script(s).