Comment by omnicognate | Hacker News Reader

Comment by omnicognate | Hacker News Reader

Parent Full thread

No expert in either but I've had to use both a fair amount. Powershell fell into a few traps that rendered it awful to use IMO:

* Trying to be a .NET language. I don't know why the one-runtime-many-languages promise of .NET withered on the vine while it flowered in Java-land without the promise even having been made, but it did. If you're writing .NET code, use C#. (And I say that having worked in one of the very few teams doing large scale development in F#.)

* Failing to get the basics of being a shell right. I can't remember the details as I've left it firmly in the past now, but its handling of redirection was just broken, to the extent that things that were trivial in bash were nigh on impossible in powershell. I got the impression its developers ignored the things bash etc. did well in their enthusiasm over building something new and powerful.

* Being fetishistic about stuff like requiring Verb-Object naming for everything. It's certainly subjective and has its defenders, but IMO it renders scripts ugly, is awkward to type and doesn't materially improve discoverability or memorability at all.

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 don't recall saying that it did. My judgement that Windows needed (and still needs) those ideas is based on heavily using both platforms.

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.

(downvotes only demonstrate my point)

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:

    (New-Object -ComObject InternetExplorer.Application).Visible = $true

As someone who really likes F#, I wonder sometimes if I should just jump ship to ocaml or Haskell. What made you feel like F# wasn’t ultimately worth it?

Reply on news.ycombinator.com