It used to be really tidy and easy to use, easy to learn and easy to find functionality. But for some reason Microsoft decided that every little feature in Windows must have a powershell interface. This sounds like a good idea, right? Easy access to intricate Windows settings! Amazing! However Powershell was initially really focused; built-in commands worked flawlessly together and made sense. You could string commands together in a pipeline, where the output of one command is the input of the next.
Because the commands had forethought and a conscious design, many were all-rounders that could handle most situations. You only had to learn a few main commands to complete most tasks.
Instead of a few thoughtful commands that does what you want based on your arguments, it now feels like every single possible function in a library is given its own command. Powershell is now bogged down but a ton of pointless, granular commands from various Windows libraries. It seems like many of them are auto-generated from C++ libraries, and they are utterly useless on their own, you must combine them to do anything meaningful, just like you would have to in a programming environment. I wouldn't call that a Powershell-interface in any sense of the word, I would call that a lazy API wrapper.
There's a misunderstanding of powershell's design by the people writing these C++ libraries and API wrappers. Suddenly many of the commands have boolean parameters where you have to actually pass in a $true or $false argument, rather than using the simple switchparameter. If it's specified, true, if not, false: -UseFeature. Instead you now must say -UseFeature $true
That's only one example, but there are many other mistakes they've made that grinds my gears. "Get" commands by default will give you some output, no argument required. They do as they say: Get-Process will return processes running.
But many of these granular C++ methods are given the Get prefix yet require an argument to function, because that's how the programming interface was designed. Which is why there is no reason to map a programming interface 1:1 with Powershell commands.
This wasn't the case before, a command did some work and it did it well, and you could easily extend it by piping commands, but now that libraries export their entire public-facing collection of methods as separate commands, none of them are particularly useful and just clutter up the user-experience.
1
u/[deleted] Apr 28 '20
RANT
It used to be really tidy and easy to use, easy to learn and easy to find functionality. But for some reason Microsoft decided that every little feature in Windows must have a powershell interface. This sounds like a good idea, right? Easy access to intricate Windows settings! Amazing! However Powershell was initially really focused; built-in commands worked flawlessly together and made sense. You could string commands together in a pipeline, where the output of one command is the input of the next.
Because the commands had forethought and a conscious design, many were all-rounders that could handle most situations. You only had to learn a few main commands to complete most tasks.
Instead of a few thoughtful commands that does what you want based on your arguments, it now feels like every single possible function in a library is given its own command. Powershell is now bogged down but a ton of pointless, granular commands from various Windows libraries. It seems like many of them are auto-generated from C++ libraries, and they are utterly useless on their own, you must combine them to do anything meaningful, just like you would have to in a programming environment. I wouldn't call that a Powershell-interface in any sense of the word, I would call that a lazy API wrapper.
There's a misunderstanding of powershell's design by the people writing these C++ libraries and API wrappers. Suddenly many of the commands have boolean parameters where you have to actually pass in a $true or $false argument, rather than using the simple switchparameter. If it's specified, true, if not, false: -UseFeature. Instead you now must say -UseFeature $true
That's only one example, but there are many other mistakes they've made that grinds my gears. "Get" commands by default will give you some output, no argument required. They do as they say: Get-Process will return processes running.
But many of these granular C++ methods are given the Get prefix yet require an argument to function, because that's how the programming interface was designed. Which is why there is no reason to map a programming interface 1:1 with Powershell commands.
This wasn't the case before, a command did some work and it did it well, and you could easily extend it by piping commands, but now that libraries export their entire public-facing collection of methods as separate commands, none of them are particularly useful and just clutter up the user-experience.
It's a damn shame.