>Why?

Case insensitive, weird parameter passing, no Posix-like interface.

>Windows, macOS, and Linux

Yet it is still mostly suitable for Windows, where it makes sense with weird (read: mostly bad and outdated) platform-wide proprietary decisions.

>This is by design

Well, humans should not spend too much focus on verbosity, maybe I'm wrong, at least that's what I've learnt from a university HCI course.

> Case insensitive, weird parameter passing, no Posix-like interface

Parameters are passed like any other shell?

> Well, humans should not spend too much focus on verbosity, maybe I'm wrong, at least that's what I've learnt from a university HCI course.

While its by design everything comes aliased and arguments are fuzzy matched. As a human you don't need to spend time on verbosity if you don't want to.

For example:

   Remove-Item $directory -Recurse -Force

   rm $directory -r -fo

> > anti-semantic > Why? I can't speak to the other poster, but I found the PowerShell example to misleading because it required the presence of a variable that the Nushell did not. I had to read through the code three times to understand:

- Whether the code was modifying some fundamental environment variable that would affect the running of other programs? - If the variable would need to be accessed after the command was run? - Why the variable was named `os_list`? This was admittedly stupidity on my part, but it wasn't event a concern with Nushell.

> > non-portable > PowerShell 6 and later run on Windows, macOS, and Linux.

PowerShell is absolutely multi-platform and that should never be held against it. However, my personal experience has been that most PowerShell guides assume that you are running Windows and will attempt to call commands not available on other platforms (e.g. OS services, other applications). Granted, scripting tutorials for Linux and OSX also assume the presence of certain services, though it's easier to search my path for `7z` than figure out whether the Get-Acme-Version command is available. Nonetheless, the issue is more of documentation than implementation.

> > verbose > This is by design

As for the verbosity, I'll fully agree that PowerShell is highly verbose by design. However, that's a design decision that makes it inappropriate for some applications. An aircraft carrier is larger than a kayak "by design", but that doesn't make it any easier to strap to the top of your car.

> can't speak to the other poster, but I found the PowerShell example to misleading because it required the presence of a variable that the Nushell did not.

This was just a choice of OP and also isn’t a concern in PowerShell:

  gc ./some.yml | ConvertFrom-Yaml | ConvertTo-Json > some.json

Lol so what happens if I run 'curl' in my PS6 script? Asking for a friend with PTSD.

Assuming you have curl installed, it'll say

  curl: try 'curl --help' for more information

I assume you're thinking of the old Windows PowerShell that used to have curl/wget aliased to it's own commands, but that's not the case with the new cross-platform PowerShell.

Its not verbose. Its just that people that use it like to share verbose stuff as it is more helpful to others.

When I'm using PowerShell as a shell, I use all the aliases and shortcuts.

When I'm using PowerShell as a scripting environment, I use the full name for every command and parameter, and even include the names of positional parameters.

I love that it can do both.