As for inferior, for what's wrong with it--well, let's start with the easy stuff. The language is not designed to be exploratory and is really hard to write off-the-cuff even when you know it cold. It inherits from .NET in ways that make it actively difficult to type on a REPL (as that's all a shell is). I like .NET, but the BCL is not the right tool for the job and none of the tooling built around PowerShell can compensate for just not being easily written out when I'm exploring a problem by hand. I know PowerShell probably better than most people who use it every day--I'm not an expert but I've studied it at length and used it on the regular for nontrivial tasks--and I can't think in it on the fly. It's a worse solution to a solved problem, for my money, and I'm fairly convinced it was designed to be an RPC layer for GUI apps rather than a way for a skilled and knowledgeable user to interface one's brain with the metal with as little trouble as possible. And that's fine, but that's worse with regards to the things that I care about.

As for substitutability: this should be obvious. I can't substitute it because it isn't interoperable with literally everything else in the stack. It is Microsoft for Microsoft's sake and incompatible with the rest of the non-Microsoft universe in ways that, it must be noted, Apple did not do; while they have proprietary tools in their environments I can still use it with the bog-standard tools that exist on every other Unix machine I ever touch.

PowerShell is supremely explorable. All you need to get started is knowledge about a few cmdlets. Get-Help, Get-Member, Get-Command and Get-Alias then you are in business.

There is nothing about PowerShell that cannot be discovered through those 4 cmdlets.

If you frequently need to dig down to .NET you are doing it wrong.

Contrary to your previous assertions, PowerShell was designed for REPL from the outset, and it achieves that much better than any Unix/Linux shell, bar perhaps fish.

PowerShells commands (cmdlets) are inherently rich on metadata. You cannot create a cmdlet without exposing metadata which is then used by the shell to drive automatic type coercion, syntax charts in help as well as tab completion.

It is so intrinsic to the concept, that you'll automatically get tab completion for your own functions, and even for your own script files.

PowerShell was definitively NOT designed as an RPC layer. You claim to "know PowerShell probably better than most people", and yet you are unaware that PowerShell was specifically designed as a hostable engine.

It is hostable precisely because Microsoft wanted to have reusable script engine which could be used in-process (!) in administrative GUIs.

Unlike traditional shells, PowerShells cmdlets share memory space with the host (the shell when used as REPL) because it SHOULD NOT use RPC to manipulate objects.

You frequently use "appeal to authority" arguments, but the substance of your posts gives you away. You are certainly no expert on PowerShell.

What does 'not designed to be exploratory' mean? How many scripting and shell languages have the introspection that comes with PowerShell, from .NET reflection to simple abstractions like 'Get-Member'? How common is a prescribed and thus simple to discover naming convention such as verb-noun?

I would love to see it in other ecosystems, and the prediction that PS could go open source, along with the recent open sourcing of .NET core and CoreCLR gives me hope.

Cheers!

You've given no actual information to why it's inferior, other the fact it's not "exploratory". I don't know what that means.

But personally I find working out command names in powershell much more sane, because of the Verb-Noun pair naming convention.

It's not about the commands. Names, whatever. I learned GNU and BSD command sets cold, names and obscura are not a problem. It's about the experience of using the thing. Everything is so insanely verbose, except when line-noise symbols are injected to break up the monotony, and the editing environment for actually using it is absolute garbage compared to either bash or zsh's emacs/vim modes. You are stuck writing long, complex (not complicated, but complex) commands that can't be easily factored down, with an interface that isn't doing much to help you (and isn't good at the little things besides, ISE is unacceptable compared to a decent terminal emulator like iTerm2). And so iterating--exploring your problem space is unreasonably difficult compared to everybody else in the same space.

A shell is a REPL. If your language makes actually writing things in that REPL hard, it is definitionally bad at Shell Stuff. I find it significantly easier to write code in C# and then transliterate it to PowerShell than to actually write PowerShell. That's a disastrously bad situation for a shell.

You were called upon to give some examples. Yet all you offer is more hyperbole. One is beginning to suspect that despite your assertion that you "know" Powershell better than most who use it daily, you are actually just a troll.

Yes, I am calling you out. I am challenging you to provide concrete examples where Powershell has less discoverability than bash or zsh. I am challenging you to explain why ISE - an environment designed specifically to combine REPL with script authoring - is "unacceptable".

And please, no more hyperbole or condescending remarks.

I'm not sure what he means by exploratory either.

I learned Powershell mostly from Get-Help. I can usually figure out where to look for a command based on the naming conventions - essentially (one of x verbs)-(one of x nouns). They aren't always fantastic, but for example, Select-String is a little more obvious than grep.

Are you really asking why you can't substitute PowerShell for a UNIX shell? There is basically no way in which they are compatible.

Even if you decided to re-invent all your UNIX scripts and tools on PowerShell, you'd be missing most of the composable tools that make UNIX what it is.

And PowerShell as a user interface is quite poor compared to, say, a 15-year-old version of GNOME Terminal.

    Even if you decided to re-invent all your UNIX scripts and tools
    on PowerShell, you'd be missing most of the composable tools
    that make UNIX what it is.

PowerShell's composability is based on piping objects rather than piping text.

Do you mean that PowerShell can't achieve the same composability that can be achieved on Unix, or that PowerShell lacks for example `cut`?

To be honest: no, PowerShell can't (practically) achieve the same composability that can be achieved on Windows. Both because of the aforementioned general malaise of writing it throwing up very real roadblocks, but also because not everything under the sun is a .NET application. You get "hack together a text pipeline and hope all your objects implement ToString in a meaningful way" or "break out Visual Studio and write some converters", which is, by my lights, significantly worse than just "hey, everything starts and ends as a stream of bytes, deal with it using the tools we know you have and work with every application you're going to use."

And this is especially egregious with the lack of a Swiss-army-chainsaw scripting language in .NET to begin with.

> To be honest: no, PowerShell can't (practically) achieve the same composability

PowerShell is much more composable. Just consider how all nix commands must pack insane numbers of output options. In PowerShell - just because of composability - output formatting is not the responsibility of each command - it has been delegated to a small set of general-purpose output format cmdlets.

This is like asking why you can't just run your PHP scripts in Python; they're different languages.

PS is interesting and powerful, but tends to fall at the last hurdle in annoying ways (eg truncate text to window even when diverted into file), and doesn't have the same user community.

Even the path separator is different.

Its just not. The problem is that experienced UNIX admins get frustrated when it doesn't work like UNIX. If you take the time to learn how it works it amazing.