I never really found the verb list to be entirely satisfactory. It's great that they gave boundaries but I find it too verbose. There are other kinds of syntactic ergonomics with concise vocabulary (lisp has ! xxx p$ for instance, they're a bit harder to swallow but I find the code a bit more poetic and easier to remember as a pattern).

About the objects vs strings, Kalman Reti (of Symbolics IIRC) talked [1] about how an OS passing pointers could enjoy a much easier time instead of serializing everything as strings then deserializing, especially when done ad-hoc through sed/grep/perl/whatever .. It pains me to see this. It pains me to see how linux basic utils are 30% --usage, 30% output formatting (and they all share this).

MS did a great thing with PS.

[1] https://www.youtube.com/watch?v=o4-YnLpLgtk

I like it. Nowadays CLIs got out of hand with verbs, every CLI assigns a very specific meaning to their verbs and it's not clear at all. Just look at kubectl: https://kubernetes.io/docs/reference/generated/kubectl/kubec... What is the difference between "get" and "describe"? It's totally not obvious what "drain", "cordon", "taint", "scale" or "expose" do. Something like Set-KubeReplicaCount describes way more accurately what scale actually does. Or New-KubeService for "expose".

Remember that you can always use and create aliases, so you could still use kube-scale or kube-expose in the terminal if you want. But for scripts readability is the most important thing. Any newcomer can look at any PowerShell script and know what it does. And any newcomer could type in New-Kube, hit tab, and see what new things you can create in Kubernetes, instead of having to google what the command for creating a service is.

You're right, these are completely obscure, and part of the friendly neologism fad we're seeing. Please note that the examples I showed about lisps aren't short sighted concepts but very generic ones (predicates, side effects, global variables), hence the limited scope of confusion here.

The verb list is, in practice, 90% Get-* and Set-* , so for most users that will cover the case where they need to read and modify some system state in a script.

It may not cover your particular use case (I want to foo this bar), but as restriction on the language it helps your users not have to discover esoteric commands.

I find PS tab complete to be sub par compared to fish. It’s too aggressive when there are multiple completions.

What do you mean by aggressive?

I don't know what they mean, but I know that I really dislike how PS's autocomplete works.

If the possible commands are (for the sake of discussion) `Get-AppLockerFileInformation` and `Get-AppLockerPolicy`.

If you type `Get-App` and hit Tab, it will autofill to `Get-AppLockerFileInformation` which I just really don't like, and I need to keep hitting tab to cycle through all other possible `Get-App*` commands.

What I want is some UI that when I hit tab it autocompletes as much as possible until there's a decision to make, and then shows me the options. So in my example case, it would look something like this:

Type `Get-App` -> hit tab -> shows `Get-AppLocker` -> type "P" -> hit tab -> `Get-AppLockerPolicy` is displayed

bash-ish systems nail this, and they even have the "double tab" to list all options from that point which is normally pretty nice.

The PS idea of "keep hitting tab or shift-tab while you cycle through all possible options" sucks in comparison. Especially with discoverability (There are about 20 commands on my windows system that start with "Get-App", and in order to figure them all out I just need to keep hitting tab until it cycles around)

With PSReadLine, you can change that:

  Set-PSReadLineOption -EditMode Emacs

Or

  Set-PSReadLineKeyHandler -Key Tab -Function Complete

The first one seems to change it how I want, but the second doesn't. And it doesn't stick around after closing the powershell prompt.

And while I'm sure there's a way to make it persist, a shell's power is in it's ubiquity. If i have to change settings on every machine I work with, i'm probably going to want to use that time to install a different shell.

I know that's an attitude that is pretty impossible for any new shell to solve for, but it's the truth. I'm not choosing the most powerful or "best" shell, i'm choosing the one that gets in my way the least. And for me, that's bash in 99% of cases. And until another comes along that really improves discoverability and makes it easy to learn and adjust to, i'm not going to switch.

I have a ton of knowledge built up over the years about bash and I'm not in a position where I'd be able to dump it all and painfully try to learn everything new from scratch by reading manuals, trying out syntaxes, searching around for if what I want to do is possible, figuring out the "right" way to do things, and more.

Even if it is better in the end, if I can't get over the initial hump, it's not very useful to me. Maybe this is just me getting old...

Making things like that persist is done through the powershell profile stored at $profile. It is the equivalent of a ~/.bashrc.

Actually, that isn't a PowerShell idea.

Firstly, that form of completion has existed in the Microsoft/IBM operating system world for significantly longer than PowerShell has, tabbing backwards and forwards around a list of matches being the way that one did filename completion with some MS/PC/DR-DOS tools back in the 1980s. Secondly, PowerShell ISE can do things differently, so this cannot be a PowerShell thing.

Crank up PowerShell ISE, enter "Get-App", then press Control+Space. For more, press Control+Space to complete an option after entering "-".

I didn't mean to imply that it was a PS creation, or that it was impossible to change, only that it's how PS handles tab completion, and that I dislike it.

Being able to change defaults is nice, but the power of PS or bash is that they are ubiquitous. So anything that has to change defaults to be usable makes it kind of pointless in a lot of ways (at least to me). Because if I need to change defaults on every system i'm on, then why not just use that time to install a different shell? (which is pretty much what I end up doing on windows machines)

Not sure what version you are using, but that is not how PowerShell does completion for me. If I type in `Get-Package` for example and hit tab, I get printed a grid of the possible completions. Then I keep typing until it's not ambiguous, at which point it will complete the whole command. If there are hundreds of suggestions, it will ask if I really want to see them all.

I am running PowerShell 6.1.0 (which I think uses PSReadline). PSReadline is also very customisable, but this is the default behaviour.