PowerShell isn't quite a .NET language, and you can't really write serious .NET software in PowerShell. But if you need to access the power of .NET (or heck, COM) from a script or an interactive shell, PowerShell lets you do that.
That's the point, though. It's a bad .NET language, but the desire to interact with .NET dictated much of its design. Windows didn't need a way to "access the power of .NET". It needed a decent shell, and sadly still lacks one
Edit: And that isn't to say .NET doesn't need a scripting language. It sorely needs that and the various relatively useless variants on "C# scripting" are testament to that. Powershell isn't, and doesn't even attempt to be, a solution to that lack, though.
To be fair, nothing in .NET required Powershell to make the choices it did (case in point: F#, ClojureCLR) for the integration. I wish to learn it but it being so...wordy definitely makes it an unattractive choice. A shell should be terser than F# or C#, not the other way around.
Yeah, "dictated by" is probably the wrong phrasing. A decent shell with those capabilities could probably have been made, but I do think the drive to make something fancy and new based on .NET was a big part of the reason they neglected decades of insights and successful idioms in the shell space, which were sorely needed on Windows.
>decades of history and successful idioms in the shell space
Just because something has persisted for a few decades does not make it good or worthy of being emulated on a platform different from the platform it started out on.
I just gave up on Windows. On every step it feels proactively user-hostile, with non-dismissable notifications, removal of UI customizations, constant reminders to change some settings to "recommended" despite my choice, accompanied by overall loss of reliability.
It feels like there is no more vision, desire and engineering excellence left in the teams responsible for it. I know that there are rare exceptions like Microsoft Store that, as an application, has started to work so much better because the person responsible for it cares, and it uses WinGet for updates and distribution, which is great. But these are droplets in the ocean.
At this point, setting up a Linux distro for a desktop yields incomparably better experience given equal amount of effort.
The only thing that makes me worried is that such a dismal state of affairs damages the image of .NET which is night and day compared to most other products made by MSFT in terms of quality and taste, it already needs help - note how much undeserved good will Go and Swift receive, despite former being much worse than everyone thinks once you look into the fine-print and implementation details, and latter having poor non-macOS support story and ecosystem outside of iOS development. And at the same time no matter the degree of improvement that happens to .NET, it is popular to bash it, even if the criticism is completely detached from reality.
The article is about exactly this. Powershell's job was not to be a decent shell, but to make server management work automatable. Unix style shells didn't solve this because windows was not file based, you need all these hooks into these various api to setup a user, or a network connection or a whatever.
Why it's .Net is also covered and its probably not what you expect.
The odd part is that, at its core, Windows still is file-based. Managing it isn't, but anyone who's gone digging around in NT's Object Manager will be familiar with using CreateFile() to get a handle for manipulating things there.
It's, in fact, pretty pervasive when interacting with Windows programmatically, just as it tends to be on Unix-alikes, and the fact that PowerShell doesn't do well to acknowledge that is frustrating. (Worse, Windows is a better Plan 9 of sorts with MIDL and COM everywhere, and PowerShell falls pretty flat here too compared to the experience of, say, slinging a dynamically generated command stream directly at fossilcons.)
Yes, I could break into C# or C++ for this, but that takes the tasks that rely on these operations firmly out of the hands of paraprogrammers.
Eh, I find PowerShell nicer than bash. And having a way to use .NET/COM stuff ad-hoc can be useful in scripts. For example, to talk to Windows Installer with reasonable performance over COM. Or to launch the best browser:
