Comment by antoncohen | Hacker News Reader

Comment by antoncohen | Hacker News Reader

PowerShell is kind of bizarre. I totally get why is has taken off with Windows sysadmins, compared to the previous built-in alternatives it is amazing.

I think a lot of the bizarreness comes from trying to be multiple things, an interactive shell and systems automation language. It is case-insensitive, with seemingly no consensus on what case to use for things. Kinda makes sense for a shell environment with a case-insensitive file system, but very odd when writing automation. It can be written to look like any modern C-like language; set variables, pass variables to functions, etc. But idiomatic PowerShell seems to be (at least in some circles) piping one function to the next in very long chains. Again, that makes sense in a shell, but becomes somewhat unreadable in an application.

Most of what I've seen PowerShell used for is automation, from small 1000 line scripts to seriously large applications with libraries and databases. And I can't help but think that Python would have been so much nicer, if only it was built-in to Windows. Python has libraries for working with the Win32 API and COM objects, there is even IronPython which runs on the CRL and can integrate with .NET.

I don't think anyone was asking for an interactive shell and a serious programming language to be combined, and it would have been nice if they were separate. Instead they have an awful terminal console, an oddly verbose shell language, and a slow case-insensitive programming language.

> "It is case-insensitive, with seemingly no consensus on what case to use for things."

There are naming conventions in PowerShell, but you don't need to know about them when you start out. For example, it's common practice to use camel case for variable names, such as $myVariableName.

> "But idiomatic PowerShell seems to be (at least in some circles) piping one function to the next in very long chains."

For the code I've seen and written, it's rare to see pipes longer than 4 commands long. If you get any longer than that, it's easy to store the output object in a variable and continue to work with this variable as a shorthand.

Regarding case-insensitivity, I'm not referring to user picked names, I'm referring to the whole language.

Is it ForEach, Foreach, foreach, or ForEach-Object? Official documentation[1][2][3][4][5] has all four variations. Same for True/False, While, Write-Output, etc. Everything is case-insensitive and the docs can't decide which to use. Again, it kind of makes sense for a shell language when your users are used to case-insensitivity, but I much prefer stricter consistency in programming languages.

[1] https://docs.microsoft.com/en-us/powershell/module/microsoft...

[2] https://docs.microsoft.com/en-us/powershell/module/psworkflo...

[3] https://docs.microsoft.com/en-us/previous-versions/windows/i...

[4] https://technet.microsoft.com/en-us/library/hh551144.aspx

[5] https://docs.microsoft.com/en-us/powershell/module/microsoft...

ForEach is an unusual statement. Depending on the context in which it's used, sometimes it's an alias of ForEach-Object, but sometimes it is not. The following article has more details on this, but one thing that I'd like to highlight now is that one way that ForEach and ForEach-Object can differ from each other is in memory use, as ForEach will load all objects that it's iterating over into memory first before starting the loop, whereas ForEach-Object will not. As suggested before, more details can be found here:

https://blogs.technet.microsoft.com/heyscriptingguy/2014/07/...

Going back to the naming conventions, the conventional way to write ForEach is in PascalCase. The variations slip into code as it's also an alias, and aliases tend to be in all lower case, and also because naming convention guidelines are just suggestions, not something that is strongly enforced (Foreach does seem to be commonly used, even if it's not necessarily in the standard styles).

Generally speaking, PowerShell coding style is similar to .NET coding style. You can read a discussion about it here:

https://github.com/PoshCode/PowerShellPracticeAndStyle/issue...

By the way, I respect your right to use whatever language you like best, I'm just clarifying that whilst PowerShell may not have it's "PEP-8" or gofmt, there are still conventions that PowerShell coders follow.

> Instead they have an awful terminal console, an oddly verbose shell language, and a slow case-insensitive programming language.

The terminal is absolutely horrible. If you are going to use powershell, try ConEmu. I also agree with you on the language drawbacks, but it's object-oriented nature makes up for it in my opinion. Whereas on linux/unix you are generally passing and processing text to and fro, the ability to deal with objects can make things a bit easier and more robust.

But considering that the windows world had to live with cmd/ms-dos forever, anything else seems like a god send.

TL;DR: Yes, I see there is potential. But as always, MS botched it.

Edit:

As an example where they did object-based scripting better, I'd look to F#, which also is a vastly better language. But it doesn't have good on-the-fly capabilities (you have to set up a project each time and need VS), and it doesn't come built in.

<rant>

> [...] the ability to deal with objects can make things a bit easier and more robust.

There are drawbacks to that too, though. As a heavily object-based scripting language, PS would depend even more on tooling than scripting languages do anyway. But that in turn means that the tooling we get just isn't good enough. Windows is notorious for its bad CLI windows, which hasn't changed much even with Win10. Discovering objects in PS is a usability nightmare. The little tab completion there is might be fine for one-off commands, but for anything interesting, it'll fall flat on its face.

If you have heavily state-dependent task, ISE contains more friction than value. Until today, I haven't found a simple and fast way to wipe the shell window clean, for example. If you still have things like sockets lying around (which means you'll have to restart the process for a clean state, it seems you're SOL).

Which brings me to

> If you are going to use powershell, try ConEmu.

I'd love to. I can't. In many business environments where you're not in control, "just installing independent tool X" is not an option. Yes, organizational BS is a separate problem, but you're not getting anything done fighting it. And honestly: It's about effing time MS distributes actually usable tools with their OS. I really don't get why that's the particular thing they fail so gloriously at.

The same problem extends to all sort of things. For example: Why the hell aren't the Sysinternals tools built-in already? It's been what? A decade? And there still is no decent Task manager in Windows? Gimme a break!

</rant>

Edit: Added a quote for clarity

Reply on news.ycombinator.com