That is a great example, but for different reasons. I think PowerShell is amazing, but it never feels like something I want to work in as a shell. Writing scripts in an IDE, sure. But to convert some yaml to json I’d much rather type open/file.yml | to json
This is where I’m at with PS as well. It’s stuck in this no man’s land between bash and python. It’s a better scripting language than bash and a better shell than python. But when compared to their main purposes it’s a worse shell than bash and a worse scripting language than python.
The caveat of course is Windows system administration. I’m sure it’s excellent in that domain.
OP here wrote this the most verbose way I could think possible. Most commands are pre-aliased in PowerShell and arguments are fuzzy matched as long as they're not ambiguous.
This... yq eats yaml. And this is all I need to know (really). I don't know yaml. I don't WANT to know yaml.
Two letter command which I can remember, in the same way that I know jq. And, as a short-form jo. I would not use jo to eat json. I do think that yq is "misnamed" slightly, in that there is no yo command.
(note that I do have yq installed, but not nushell or PowerShell).
shell is glue, not oop -- json is an object notation, converted to stringyness. Which makes for oop->shell. Since "objects" are programmer-think, this should not be the primary command interface. People (not programmers) recognize this, and thus PowerShell is not used by "non-programmers". Ok, you want something above bash (sh, shell), for more programming structure? This is why the #! construct is exec() is so important. That lets you use... um awk, sh, (and should support PowerShell -- not sure). Even C (with tiny-c). I would go with javascript, myself, because it fits with json, and thus jq and jo in the eco-system.
Now, for a criticism of yq -- jq is 30K for a front-end and 350K (or so) for a library. jo is 120K, yq is (gulp) 12MB. Ok, I have the disk space. And it is GO, so ok. Compared with the other GO programs I use commonly: minio (100MB), mcli (mc, 20MB), doctl (20MB), it isn't bad at all. But, I guess that is what GO demands...
Can I teach "functional shell"? Frankly, no. I can get through simple shell in a semester.
I mean, yeah? As much as I hate to admit it (and believe me, I hate to admit it), PowerShell is better than bash at composing tools made by all sorts of people on the fly in easy to write pipelines. I have my issues with it as a language, but it's not like I'm thrilled to write bash. Nushell is an attempt at making a scripting language which builds on bash, rather than supplanting it. PowerShell is much less nice on Linux, especially when you'd have to translate every existing resource.
Yeah, PowerShell eliminated the output parsing overhead which was the significant portion of any composed shell operation. That's where all shells need to be heading I believe.
> 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.
> > 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:
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.
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.
>open dev/home-impermanence/tests/impermanence.yml | to json
I can do it with PowerShell:
$os_list = (Get-Content -Path "C:\temp\operating-systems.yml" | ConvertFrom-Yaml)
Set-Content -Path "C:\temp\PowerShell_operating-systems.json" -Value ($os_list | ConvertTo-Json)