The thing is, if you want to use Powershell you do need to spend a few days just learning Powershell and nothing else. I have the impression some people don't want to do the effort. It's a pity because it truly is vastly better than any other shell in existence.

It baffles me as well how many Windows people I work with ignore it almost.

In terms of specifics, PowerShell's strengths over C# for scripting are particularly in PowerShell's the ability to succinctly navigate hierarchies (folders, but also other folder-like trees) in a way reminiscent of shells from time immemorial, as well as to easily interleave native binary calls (and pipes/redirects/captures).

Some of it is the difference between grabbing C# binding for libgit off NuGet, LINQing my way through a the git DAG for the information I need versus running `git show xyz` or `git describe` directly in a shell and capturing that into a variable or piping that to whatever my next steps are. Depending on my level of abstraction and how often that script is called and if I'm paid to write that script or it is getting in the way of what I'm actually trying to work on, I use a different tool for the job.

I have observed the several seconds startup time last with PowerShell v2 or so and that was not the time needed for the CLR to start, but rather PowerShell which was slow to start. v5.1 starts instantly here and the only slow thing about it is my profile, which admittedly does a bunch of things that take time (it's not yet at a point where it's annoying me so much that I edit it, and I can start typing commands during that time anyway (considering that I often spend more time thinking about what to write that's okay)).

A way to execute programs. The parent is right, powershell is more like a REPL to execute .net code. It's still no where near as good as a unix environment.

Heck, running programs is even easier than in most other shells since there's a specific token that stops argument parsing completely which means you don't have to care about quoting at all (an ever-present nightmare at times).

I beg to differ, by the way. Different is not the same as »not useful«. It's not a traditional Unix shell and doesn't pretend or want to be. That doesn't make it useless, just different.

Except in the sense that it provides aliases for most popular Unix shell commands. They even made their aliases incompatible with other Unices, like every other traditional Unix shell.

Also, since PowerShell can work with WMI objects natively it's already close to what a cmdlet can provide.

A command shell is a shell that uses commands to interact with the operating system, whereas a GUI shell is a shell that uses a graphical user interface to let the user interact with the operating system core (services/tools/processes).

In Unix philosophy, a 'command' is almost synonymous with a 'program', except when it's not. Seems to me that you are stuck in the Unix mindset and refuse to entertain the idea that a "command" could be anything but a program. In fact, the Unix shell commands are already a hybrid concept: Commands can be magical built-in commands (like 'cd'), programs (like 'ls') or script files which will execute in a special surrogate process (a seperate shell process).

However, there is a problem with programs as commands: They are opaque. And because every program is started within it's own process, they are also limited when it comes to extending the shell features. This is why 'cd' is a special command that is not a program.

PowerShell is a fresh take on this: PowerShell commands are still used to interact with the operating system, but they need not be full-blown programs executing in their own process. Hence, PowerShell is in some ways even terser than the traditional sh shells. An example of this is the way that 'cd' is not a magic built-in command. In PowerShell 'Set-Location' (the command for which 'cd' is an alias) is implemented like any other command and packaged in module. Only this module is always distributed with PowerShell.

This approach also has several other advantages (not limited to):

* PowerShell "discovers" the parameters, types, positions of command parameters. It is the shell that performs parameter parsing, position matching and (most importantly) coerces values, e.g. parsing a string as a number when the parameter expects a number. This leads to much higher consistency.

* The shell can generate documentation from the command definition. Not possible with sh shells where you need authored documentation, because the parameter parsing is really the responsibility of each command.

* The shell can generate tab-completion and auto suggestions from the command. Not possible on sh shells where you need authored completion files to support completion. In PowerShell you get documentation and tab-completion even for scripts you write yourself!

* The commands may interact with the shell itself. This is important not just because you can implement commands like 'cd', but because the "shell" may actually be part of an application. A GUI administration tool can actually act as a shell, and commands can control the GUI. A very generic example of this is PowerShell ISE, where commands can actually open new windows/panes, change menus etc.

> The parent is right, powershell is more like a REPL to execute .net code.

Wrong. PowerShell is a REPL (i.e. a command shell) to execute PowerShell commands. PowerShell commands may be cmdlets but may also be programs. PowerShell may be implemented in .NET, but PowerShell scripts are not .NET code.

A GUI workstation using a REPL for scripting/automatic is so much powerful than a plain UNIX shell.

Fits the definition for me

The only problem with the tab-completing is that since everything has a standard verb prefix, you always have to type the beginning of the cmdlet name.

At least for me, if I'm opening the command line it's to get something done quicker and easier than I could with the GUI. Powershell wasn't that, at least on Windows 7.

I can hit Win-X-I and start typing commands as fast as possible and Powershell is up instantly and I've never missed initial characters on a command. For interactive use, it's always there and up quickly.

This is in contrast to the typical start menu search which takes about a second before it registers keystrokes and I'm always searching for something missing the first few letters of the file or executable name.

Side note: A terminal emulator is completely different from a shell (and on Windows (prior to 10 at least) there wasn't such a thing, but rather the console, which did not emulate a terminal).

Be sure to read the comments where PowerShell guru Jeffrey Snover politely addresses them.

I share many of these same frustrations that have prevented me from adopting it as a Windows scripting language. I use it when I have to, but I still will choose csharp compiled EXE's, vbscript, or even Py2Exe'd Python programs over PowerShell for sysadmin type tasks.

I was in the audience at MS TechEd 2005 in Orlando and watched as Jeffrey Snover presented Monad and highlighted it's Perl, awk, sed, and unix influences. I was immediately impressed.

However, PowerShell seems to best fit as a REPL shell, and for me, more mentally cumbersome than using csharp (which of course can technically do everything ps can).

My gripes with PS are kind of minor (a bit like my dislike of Python's whitespace enforcement), but it's kind of like a death by a thousand annoyances with PowerShell for me.

For example (stolen from Helge's article), these are some WTF's for me

* Testing for string equality: "abc" -eq "abc" ( why isn't this "abc" == "abc" )

* Greater than: 8 -gt 6 ( why isn't this 8 > 6 ?)

* Functions can only be used after being defined. Leading to scenarios where a script begins waaaay down at the bottom.

* dynamic scoping: http://ig2600.blogspot.de/2010/01/powershell-is-dynamically-...

* No way to syntax check a PS script before it's run

These aren't all major, but the last one is a show-stopper for me. If I'm running a script on a couple hundred thousand machines (and I have) I can't afford to have my script bail out on an unexpected code-path.

I really like the idea of PowerShell, and I am honestly glad it exists, but I think it would benefit from some changes outlined in Helge's article.

And this is why me, someone working professionally with Windows for over 15 years (sysadmin, developer, security) doesn't choose to use PowerShell very often.

Wouldn't that be ambiguous with ">" when used for redirecting IO?