Hacker News new | ask | show | jobs
by chrisfinazzo 2953 days ago
Not to put too fine a point on it, but that's nonsense.

Historically, PowerShell was supposed to be a replacement for cmd.exe and roughly equivalent to bash, yet suitable for the Windows environment. They tried early on to port some of the UNIX & Linux tools to Windows and it didn't fly, so this is what we're left with.

Although parts of Powershell are open source now, I suspect the mere existence of WSL means that Microsoft understands it has more to gain from compatibility with the rest of the world (Bash is nigh-everywhere) than imposing their particular philosophy on people.

(See also, Apple's decision to adopt UNIX underpinnings)

I'm prepared to be wrong if PowerShell actually gets used outside of Windows, but I wouldn't bet on it.

4 comments

> Historically, PowerShell was supposed to be a replacement for cmd.exe and roughly equivalent to bash

What? PowerShell has radically different ideology. Plus it is super consistent (helps discover commands), extensible and works with objects rather plain strings, use .NET functions or call custom .dll functions...

> They tried early on to port some of the UNIX & Linux tools to Windows and it didn't fly

Actually they just use aliases to map well-known unix commands to powershell counterparts. It is not expected to have command switches work like that etc. Just a convenience for folks used to rm, ls, tee, wget, whatever. Maybe bad decision because of confusion, maybe a good one because helps people get started with PowerShell.

For me as a Windows admin, PowerShell is one of the best things within Windows Ecosystem.

There is an episode of the "To Be Continuous" podcast with Jeff Snover (PS's inventor) that gets into this a bit more. Because of the difference in philosophy, a straight port to Windows didn't work well.

Basically, text files (UNIX) v structured data from API's (Windows), thus PowerShell was born.

https://www.heavybit.com/library/podcasts/to-be-continuous/e...

Powershell's philosophy is the same as the one behind core-utils: Simple tools you can chain together to do complex tasks. Only it was made with 30 years of hindsight, so it actually does it much better.
Powershell on Windows is better than bash on Windows.
> Not to put too fine a point on it, but that's nonsense.

In PowerShell you pass structured data around instead of globs of text, which is much more maintainable. Using Bash on Windows is like going backwards, and it's sad that most developers don't even realize it.

> Historically, PowerShell was supposed to be a replacement for cmd.exe and roughly equivalent to bash, yet suitable for the Windows environment. They tried early on to port some of the UNIX & Linux tools to Windows and it didn't fly, so this is what we're left with.

Nonsense, Powershell is a fundamental improvement. It's not a "this is what's we're left with" situation.

> Although parts of Powershell are open source now, I suspect the mere existence of WSL means that Microsoft understands it has more to gain from compatibility with the rest of the world (Bash is nigh-everywhere) than imposing their particular philosophy on people.

Yeah, let's just drag everything down to the lowest common denominator.

> (See also, Apple's decision to adopt UNIX underpinnings)

Which is sad, since it could have been so much more. The Unix way of doing things, isn't the be all and all.

https://www.youtube.com/watch?v=rmsIZUuBoQs

https://news.ycombinator.com/item?id=16813796

I used Powershell extensively before I ever had experience with a linux or unix shell. I still have more experience with Powershell than bash or zsh, but I can't imaging going back. I'm already much more capable in a *nix shell.

There are advantages to having a pipe based on structured data, but that also means you have to know what structure to expect at ever step of the way and whether or not other tools can work with that structure. There are also tons of little quirks about Powershell; enough so that I eventually just started writing most stuff in C# and then just using the Powershell scripts as glue.

Passing text means that every single one of the thousands and thousands of unix cli tools that accept stdio will work in your pipeline.

I think this industry needs to get away from the terrible/horrible, absolute thinking. Most tools have positive and negative

Passing text means that every single one of the thousands and thousands of unix cli tools that accept stdio will work in your pipeline.

It also means every one of those thousands and thousands of Unix clip tools needs to have a parser to turn that text into some sort of structure to operate on.

Which allows them to determine exactly the best way to do that for their purposes. I just run the command and it magically works.

It'll be a long time before the Powershell ecosystem has a fraction of tools that are compatible with it's .NET object pipeline.

Which allows them to determine exactly the best way to do that for their purposes. I just run the command and it magically works.

Up until someone changes the text output of the program and it all goes bad. Never mind the maintenance headaches that basically get solved by people moving their command lines into databases where typing happens.

It'll be a long time before the Powershell ecosystem has a fraction of tools that are compatible with it's .NET object pipeline.

That's more a function of age and developers than the typing itself.

Sad to see this downvoted.

As a 20 year bash veteran: powershell is the first OS default shell that outputs structured data, and looking at objects and selecting the properties you want is a massive improvement than combining bash with sed/grep/awk to scrape text.

Someone bizarrely responds that cmd still exists on Windows for compatibility purposes (though even Win+X starts powershell now) doesn't change this at all.

The README for my powershell profile (which is written from a *nix PoV) has a little more info comparing the two: https://github.com/mikemaccana/powershell-profile

I'm always amused by these PowerShell threads on HN.

How is it that objects are an accepted thing for basically every programming environment in modern use, yet somehow controversial when it comes to the shell?

The prayer-based text parsing toolchain sucks. It has always sucked, regardless of platform. We put up with it because it was all that we had.

Jeffrey Snover came up with something better and thanks to PS Core we'll be able to use it everywhere!

Yeah - most people would agree that GraphQL is a better way to access data than, say headless Chrome via Puppeteer. Many folk here prefer TeX over Word because the former encourages seperating content from presentation. But when it comes to the shell, suddenly everyone hates the idea.
> How is it that objects are an accepted thing for basically every programming environment in modern use,

They aren't accepted for basically every programming environmental nment in modern use; peak OOP-all-the-things is well in the past, and it's no longer the one paradigm to rule them all, irrespective of use case.

Whether you have methods or functions, you still have hashmaps - bash you scrape values, pwsh you select keys. Pipelines can be considered quite functional too.
> Nonsense, Powershell is a fundamental improvement. It's not a "this is what's we're left with" situation.

It would be, if cmd.exe was long dead, PowerShell had stolen the good parts and continued on its way, but we're not there yet. Cmd.exe still exists on Win 10 and let's not even get into the fact that 64 bit only versions of Windows are not yet everywhere. Sure, Microsoft's ecosystem is larger and more complex, but at some point Win32 becomes a liability and unnecessary baggage.

> Which is sad, since it could have been so much more. The Unix way of doing things, isn't the be all and all.

Cultural compatibility matters - See C & C++. How else do you expect to get users and developers on board if you can't show them how your system is better in a few key ways, but isn't a giant leap from what they're currently using?

Tl;dr Change is scary, try to make it less so.