Hacker News Reader

Comment by petilon | Hacker News Reader

PowerShell as a scripting language is a major PITA. On one project I had to maintain a PowerShell script for provisioning. The provisioning takes 2 to 3 hours. After 2 hours the script would abruptly quit because of some syntax error. 2 hours wasted.

A lot of Microsoft plugins have PowerShell plugins. This is what makes PowerShell valuable, not some attribute of PowerShell itself.

Really what Microsoft should have done is to make those plugins available to C#. Then make C# usable for scripting purposes -- C# is as easy as most scripting languages in any case, and now with "top-level statements" you don't have to write classes. Make C# usable like Dino for TypeScript (i.e., transparent compilation). Then any syntax errors in the script can be caught ahead of time, instead of after 2 hours of running.

View on HN

I disagree with pretty much your entire comment.

> PowerShell as a scripting language is a major PITA.

Well, except this part.

> After 2 hours the script would abruptly quit because of some syntax error. 2 hours wasted.

As mentioned by another commenter, the PowerShell script is parsed up front, so it probably wasn't a syntax error. My guess is the script lacked error handling and some query or connection to a remote server failed.

> A lot of Microsoft plugins have PowerShell plugins. This is what makes PowerShell valuable, not some attribute of PowerShell itself.

There we go agreeing again. Although, PowerShell is effectively self-documenting, which is good for busy sysadmins.

> Really what Microsoft should have done is to make those plugins available to C#

A lot of them effectively are available to C#, such as System.DirectoryServices.*. In the early days of Active Directory, before PowerShell, this is how we did things. While fun for us programming nerds, it took a hell of a lot more time to write usable tools.

> C# is as easy as most scripting languages in any case

Hard disagree.

> Make C# usable like Dino for TypeScript (i.e., transparent compilation).

A more C#-like scripting language? I'm all for that, but why not just use TypeScript at that point (ala the JScript days).

> Then any syntax errors in the script can be caught ahead of time, instead of after 2 hours of running.

No, you run into the exact same challenges, whether it's PowerShell or C#.

IMHO, while I'd rather be doing C# programming any day of the week, PowerShell is more approachable for the vast majority of Windows sysadmins out there. Additionally, due to the command... verboseness of PowerShell, it is effectively self-documenting.

Edit: Snover's original Monad Manifesto paper is worth a read for his reasonings about what is now PowerShell: https://www.jsnover.com/Docs/MonadManifesto.pdf

It might be best summarized by this partial quote: "PowerShell replaces fragile, prayer-based text parsing with pipelines of objects (structured data)"

You're implying sysadmins aren't smart enough to use C#.

You shouldnt speak down to a whole group of very intelligent people like that.

I think the idea is more that they have less time to spend worrying about compiling or deploying C# applications.

His exact words are, "IMHO, while I'd rather be doing C# programming any day of the week, PowerShell is more approachable for the vast majority of Windows sysadmins out there."

IE, the vast majority of SYS admins aren't capable of approaching C#. Fully unsubstantiated heresay. If they can learn the cryptic nightmare that is power shell, they can certainly learn C#.

That's an extremely uncharitable interpretation of the quoted sentence. Just because X is more approachable than Y to a person doesn't mean they're incapable of approaching Y. The sentence makes no claims in regards to a sysadmin's capability.

Uncharitable? Read his follow up that starts with:

"A lot of sysadmins:

1. Aren't "very intelligent"."

A spade is a spade.

I don’t want to write C#, I want something that can be that powerful when I need it, and be fast when I just want to get something done. Powershell is where I go in the Windows/M$ world, Python is where I go in the nix world.

There’s very few times that I need to write a Powershell script that runs like a daemon. I’m typically using it in a notebook in VSCode, but I do* have Kubernetes jobs that are written in Powershell that run periodically. They were quick and effortless to write, run fast (dotnet core,) and are easy for my team to understand if they want to modify them or someone needs to maintain them.

None of my team would willingly learn C#, nor would the business support them writing C#. A powershell script though? Fair game for anyone who wants to look at something new and innovative, it requires nothing if they use ISE, and if they want to, VSCode is already an approved app. Need a hosting platform? You can deploy on Kubernetes if you really want.

It’s a really big barrier to entry to force someone to use C#.

A lot of sysadmins:

1. Aren't "very intelligent".

2. Aren't smart enough to learn C#, let alone well enough to do systems programming to replace PowerShell.

3. Don't have the time/desire to learn C#, even if they are capable.

4. Don't have the time to write systems management code in C#, as opposed to PowerShell.

Back when I started UNIX system administration, pretty much all sysadmins knew C and could write arbitrary system management utilities in C.

This is no longer the case, for better or worse, the world needs more sysadmins and Microsoft has released server software that can be managed by relatively minimally-skilled people who know how to Google and copy/paste code from websites.

>> Really what Microsoft should have done is to make those plugins available to C#

>A lot of them effectively are available to C#

True, though some of them aren't. I ran into one recently...setting the metric value for an ip interface (not a route, an interface). Powershell has that, C# does not, in any way that I can find.

> I ran into one recently...setting the metric value for an ip interface (not a route, an interface). Powershell has that, C# does not, in any way that I can find.

It can be done in C# via WMI (System.Management), but that's a strange old world if you're not used to it. But it's more convenient in Powershell because MS provide modules such as NetTCPIP so you don't need to touch WMI directly.

> Although, PowerShell is effectively self-documenting, which is good for busy sysadmins.

Oh no it isn't. Very basic stuff like Get-Something piped into a Remove-Something is, but beyond that, it gets complex quick. Add aliases, weird logic and limitations ( do you know you can't break out of a Foreach-Object?), and it quickly becomes an illegible mess that needs parsing, the same way Python might.

Furthermore, a lot depends on the cmdlet provider, and for instance the VMware ones are steaming piles of horseshit with inconsistent naming of parameters, broken async, and useless error management ( e.g. you get an error which says to check the inner exception, but it's empty and there's no way to get any detail whatsoever).

I would still take that over the cryptic -fHxC magic incantations of unix tools. Especially that you get unified help for all of them, readily available.

And I say that as someone who really doesn’t like windows (and thinks it is not fit for development at all) — but powershell is really a gem, if one gets over the at first strange syntax and actually looks into it.

The first paragraph is just sloppy coding practices which can render any scripting language, not solely Powershell, illegible.

> do you know you can't break out of a Foreach-Object?

I don't because you can.

> Furthermore, a lot depends on the cmdlet provider,

WTF, bash is unusable unless grep, sed, awk and friends are present .

> WTF, bash is unusable unless grep, sed, awk and friends are present.

No one is calling bash self documenting, so that comparison doesn't mean anything.

When you run a PowerShell script, the entire thing gets loaded and parsed up front, so any syntax errors are going to happen immediately. Not saying you didn't see an error, but it probably wasn't a syntax error. (Beyond that, what language are you thinking of that doesn't stop when it hits errors in your program, and is that a good thing?)

Calling out to another script/dynamic powershell, or maybe is referring calling a cmdlet(is that what they were called) with the wrong arguments, goes power-shell check for that? It’s been almost a decade since I used it but I echo the sentiment. It was a difficult overly verbrose language that I avoided at all costs even going so far to install cygwin so I could use bash as a command line and scripting language

> Calling out to another script/dynamic powershell, or maybe is referring calling a cmdlet(is that what they were called) with the wrong arguments, goes power-shell check for that?

Can any scripting language check for that? It is beyond the scope of what an interpreter has available to it.

PowerShell as a _shell_ language though is really cool. Yes, scripting large scripts can be cumbersome, but actually having a PowerShell prompt beats having a cmd.exe prompt any day hands down!

Some of the things are not... ideal. And there's a bunch of legacy stuff in modern powershell that we could do without, but a REPL scripting language with pipe semantics is really useful on a day-to-day basis.

I'm not sure C# would work as a shell language at all.

I could never get used to verbrosesess of powershell and even when I worked with windows would always install cygwin for bash.

Why do people keep complaining about PowerShell verbosity? There are default aliases for common commands, tab completion of everything, and user-defined aliases. PowerShell is only idiomatically verbose so people can actually read it, unlike your average unix shell command.

Because they start at the conclusion and work backwards.

"It isn't what I'm used to, therefore bad, now let me figure out why." After that the length of commands is an easy target, in particular if you don't know enough about it to criticize it for anything substantive.

It's a shell, I don't want to write a novel to get something done. bash is a bunch of small composable binaries that chain together easily. powershell is, was? not. length of commands IS important imho for a shell as I want to be able to quickly type out what I need to do and then move on

I can code-golf in powershell. You could too, if you tried.

Powershell is based on small composable commands that are easy to chain together - as you would know if you've used it at all.

Valid criticisms exist of powershell. It baffles me why Linux refuseniks trot out such easily-discounted objections. My belief is that it's a figleaf over a political position: "I will never use a Microsoft product". We're on HN; that's an acceptable position. Why bullshit?

I blame everybody: https://news.ycombinator.com/item?id=29488422

Because it's painful. The tab completion works in a weird way by filling the first available option when there are many, instead of proposing them all, meaning it's outright harmful in 90% of the cases, and is completely different than the established norms in *nix land. Aliases aren't recommended because they remove the main advantage of the verbosity, readability.

A) Tab completion behavior in PowerShell is configurable

2) You just keep hitting tab until you get the one you want. This is the tab completion behavior of the Windows command line since it added tab completion.

C) Did I mention it's configurable? https://stackoverflow.com/questions/8264655/how-to-make-powe...

PSReadline makes Powershell tab completion basically behave like zsh or bash.

https://github.com/lukeschlather/dotfiles/blob/master/src/Wi...

You can set Tab Completion to Menu Complete and it will show you all the options.

For many years, the aliases were worse than the problem. Aliasing `curl` to `Invoke-WebRequest` without also aliasing the flags was a crime against usability.

That said, tab completion works, and I used PowerShell on macOS for a long time with no complaints.

Oh I totally agree about the unix-mimic alias names, they're terribly misleading.

Having Invoke-WebRequest originally use the IE engine for parsing by default was also a terrible idea, but at least they reversed that one.

because when I am in a shell I don't want to spend days typing out and tabbing forever trying to write some quick one liner command I'll never look at again. I just want a bunch of quick and easy to compose functions to just do what I want, and then move on. I don't need it to be readable, just quick and functional which bash is.

for scripting I'd personally use neither.

> because when I am in a shell I don't want to spend days typing out and tabbing forever trying to write some quick one liner command I'll never look at again.

Even without the hyperbole you have a comically exaggerated idea of how long it takes to write quick one-liners in PowerShell. For me personally, it helps a lot that I don't have to look up cryptic three-letter command names, obtuse switches, or the precise sed incantation to glue things together.

They have a lot of shorthands for common commands, and the verboseness is on purpose, so you can guess commands and by correct 9/10.

- They have a list of standard verbs: https://docs.microsoft.com/en-us/powershell/scripting/develo...

- Every command is verb-noun. So get-[whatever], remove-[whatever], set-[whatever] etc.

Therefore, you can guess get-process would be a command as is stop-process or start-process.

Also, every parameter is fuzzy-matcheable.

I’m sorry, maybe it’s just my experience at work where I have to use it, but I really honestly hate these bash emulations on windows. Like, I honestly don’t get the point. It will die with the stupidest errors due to mismatches between the underlying abstractions, it is slow and not even its terminal emulation is on point.

I can only speak to cygwin, 10ish years ago, but it worked flawlessly for me at that point.

>PowerShell prompt beats having a cmd.exe prompt any day hands down!

That's not a very high bar to exceed. A glass of water seems like champagne to someone in the desert.

Other than familiarity, it does beat bash as well, hands-down.

I will absolutely agree here. As a heavy Linux user, I always reach for PS over cmd when I need to work on a windows system

The main reason for this though, is that I can use some familiar Linux commands and I don't need to google how to list files in the current dir (PS and bash both have ls, among others)

I always enjoyed using it in reverse: when you build a .NET app it is very easy to add a CLI by exposing .NET code as cmdlets. This gives you documentation, completions and arg parsing for free while you stay in your application language. This is super useful.

Think of it as the .NET and PS equivalent of a manage.py script.

I agree that PS as a language is quite unusual (e.g. how it returns results) but on the other hand it’s concept of structured data also makes it powerful in ways that old-school Windows scripting or bash are not.

never made big system scripts but I wrote a funky mouse automation with powershell 5 and it was pleasant

it's not ideal but tapping into the whole system with a coherent syntax / object network is cool and you have blocks / classes to clean up your logic

you can even tap directly into .net (for some reason there's a shortcut to load and compile a god damn source code string)

It seems you're comparing it to ruby or python, am I right ? because IIUC powershell was more a MS OBash for Windows (without bash eternal fingercuts)

So you blame bad developers for stuff ? Amazing.

> The provisioning takes 2 to 3 hours. After 2 hours the script would abruptly quit because of some syntax error. 2 hours wasted

Anybody who designed such thing is bad. If stuff fail after 2 hours, you should be able to repeat it in idempotent way to just continue or you skip sections with parameters. Your syntax error problem is the same in any other shell, and in all dynamic languages.

> A lot of Microsoft plugins have PowerShell plugins. This is what makes PowerShell valuable, not some attribute of PowerShell itself.

Nonsense. I almost never use any of the "plugins". PowerShell on its own is game changer. Like the first dude already said, I have yet to see a problem that can't be done in 2-5 lines of code that is joy to read even in shorthand form, unlike countless magic chars, something that is known to be bad pattern in OOP.

> Really what Microsoft should have done is to make those plugins available to C#.

That is really NOT what Microsoft should have done instead of PowerShell, maybe alongside it. But since you have PowerShell, you don't need it that much. Besides, it already exists for almost decade.

> Then any syntax errors in the script can be caught ahead of time, instead of after 2 hours of running.

You can do this today.

But you can create PowerShell cmdlets using C#. If you're doing something that would really needs compile-time checks, simply extract the logic into a C# class inheriting from Cmdlet, and use that cmdlet in your scripts as needed:

https://docs.microsoft.com/en-us/powershell/scripting/develo...

Yes! It's maddening trying to get the C# Powershell integration to use, Get-VM, for example. Especially in a way where it would work on somebody's else's computer.

Reply on news.ycombinator.com