Hacker News Reader

Comment by crabbone | Hacker News Reader

It's so bad that I'd actually take the decades of cruft over it.

It was made by people who don't know how to use existing tools and what the actual problems are. It's like people who keep creating "new" text editors, but they never learned well how to use existing ones. So they end up with crippled half-baked thing that's some concept from the 80s that was discovered to be a dead-end in the 90s, but with modern cosmetics.

PowerShell is just incompetence and hubris of people working for a large company which can push their random garbage software on a lot of users and developers due to having huge market presence.

View on HN

This is the single worst take I have ever read on Hackernews. You didn't actually give a single concrete reason why PowerShell is bad. I will give a major reason why it is AWESOME:

objects are piped instead of text. This single change makes a ridiculously huge improvement. You are no longer forced to perform incredibly tedious and fragile text manipulation. This also enables filtering on property names and the ConvertTo-JSON command which is amazingly useful.

What are your specific criticisms of PowerShell?

Not the OP, but everything requires tons of case sensitive typing. It's easier to just write python script instead of typing this

(curl http://localhost:5555/log | grep -o -E "2025[0-9-]+")

    (Invoke-WebRequest -Uri "http://localhost:5555/log" -UseBasicParsing).Content | Select-String -Pattern "2025[0-9-]+" -AllMatches | ForEach-Object { $_.Matches.Value }

or this (ps ax | grep ffmpeg)

    Get-Process | Where-Object { $_.ProcessName -match "ffmpeg" }

Maybe it's good for scripting (why not python then?) but really sucks when you need to get things done in terminal.

I agree. I use SetAlias ss Select-String or gm / Get-Member but you’re right the language is too verbose.

Auto complete is quite good though.

PowerShell is mostly case insensitive, `get-process` works as well as `Get-Process` or `GET-PROCESS`

`ps ax | grep ffmpeg` sometimes will match grep itself, so either prevent the match from matching itself, or maybe instead use pgrep(1).

  $ ps ax | grep ffmpeg
  66898 pe  S+p      0:00.01 grep ffmpeg
  $ ps ax | grep '[f]fmpeg'
  $ pgrep ffmpeg
  $

As for PowerShell, it does not seem useful, but then again I live mostly on OpenBSD and in the terminal.

Powershell has very good tab completion. It isn't a problem. And it is case insensitive.

> or this (ps ax | grep ffmpeg) > > Get-Process | Where-Object { $_.ProcessName -match "ffmpeg" }

The way to write that on the command line Powershell would be:

    ps ffmpeg

Whereas your longer example is what you put in the PS1 file.

curl and ps are both aliases in powershell for their respective posh equivalents. For some reason grep isn't though, I'll give you that.

It also has positional parameters meaning you don't have to specify parameter names, though you might as well because tab completion is a thing. And if you're really keen on not using tab completion, it autocompletes parameter names for you meaning "get-help man -e" is equivalent to "get-help man -examples".

Here are less verbose posh commands for your examples.

  (curl http://localhost:555/log -useb | select content | sls "2025[0-9-]+" -a).select.matches

Still arguably a mess. Select-string not having a -o equivalent parameter is a big gripe of mine.

  (gps ffmpeg) or (ps ffmpeg)

Get-Process has a name parameter. Why not use it?

Edit:

I should have added, curl ships with Windows now so a farer comparison would be a select-string on curl.exe.

The criticism of Unix shell coming from the authors of PowerShell and those who like it says something to the effect:

We want modern (and by that they mean C#-like) programming language in shell. We want user types, type checking, structured, modular code.

And they forget that the reason Unix shell is easy in some respects is precisely because it has none of that. Since everything is text, serialization is trivial. But serialization is vital if you need to work remotely between different shells.

Structure will require a lot more operations for composing and decomposing it in order to transmit messages. Equality and identity become a problem.

Custom types are similar to structure, but on top of it present a problem with serialization (somehow both shells need to have same type definitions, and what happens if they inevitably don't).

The problems above not being addressed... what you get is another "scripting" language, of which there are already dozens, with no special benefits when it comes to it being used as shell, but with some problems. Just not worth it and illustrates lack of research and understanding of the problem space on the part of the authors.

" Since everything is text, serialization is trivial. But serialization is vital if you need to work remotely between different shells."

Serialization is trivial in PowerShell but also much more powerful because you can pipe the output of any command to ConvertTo-JSON or ConvertTo-CliXML which gives you very nice STRUCTURED serialization that is much easier to consume.

> Serialization is trivial in PowerShell

There isn't really. For a lot of PowerShell objects, there's no way of converting them to JSON or XML. Imagine what happens if you convert a closure to JSON? It doesn't matter what language you use, it's always going to be a problem.

You are simply too inexperienced with the subject to be able to have a judgement on how (well) it works.

Trust me, it's anything but "trivial".

Reply on news.ycombinator.com