My biggest complaint with PowerShell is that it's unnecessarily inscrutable -- filled with Bash-like and Perl-like syntax and semantics without the legacy to justify it. I wish writing in PowerShell was as easy as writing C# but instead it's almost as bad as writing Bash scripts.

It's not good for programming or scripting. There are so many good ideas in PowerShell but it's wrapped in a weird body.

As a Syasdmin, Powershell is a scripting dream: it has tab completion for the commands and the switches. I don't feel like I have to guess or look at man pages to figure out why there's a -s and an -S. The help pages are usually written for human consumption by comparison. Saying that it is 'unnecessarily inscrutable' is quite hilarious - have you seen some Linux commands & the lack of output they give? Powershell, if anything, ins extremely verbose & is clear in when something goes wrong.

At least, it doesn't insult you like Ansible tooling with the ^ YOU MADE A MISTAKE HERE BUT WE CAN'T BE CLEAR WHAT IT IS

You're comparing PowerShell to Bash -- I'm comparing it to any language written in the last 20 years.

Well bash has (can have) all of that as well.. Those are features of the code editor.. Not the language.

I think it's a good thing to have in the language to specify which switches require some options and which exclude some other ones.

It is a bit differnt because windows is bundled with Windows PowerShell ISE which is the IDE I think he is talking about.

We have all of that in C# without the rediculously bad syntax.

It's such a shame powershell didn't come 2 years later, I feel like they'd have had no choice but to use C# instead of inventing a new language.

We thought about that but the reality is that it does not work well for interactive experiences.

When you look at how admins get their job done, it starts in the interactive shell and then when the do things frequently, they put it into a simple script and when then need it to be more formal, they invest in making it production quality.

That is the flow that PowerShell was designed to support.

Jeffrey Snover [MSFT]

Could you just allow interaction with objects in a shell while just using c#? There are interactive c# interpreters that already do great.

I still feel it was a massive waste, the millions of programmers who could be using scripting C# right now, it would have been awesome.

I realise this is a bit of a cop out, but it's fairly easy to mix and match PowerShell and C# code, even without needing to precompile C# code, by using Add-Type.

It's worth noting that all code in .NET is enclosed within a type (at a fundamental level .NET code is either contained within a value type or reference type, but knowing those names isn't important when you're starting out), so this doesn't limit you to creating/importing data types, you can use it to write inline C# functions too.

It's also interesting to note that the .NET Framework comes with its own .NET compiler, so you don't need to install any dev tools on Windows to code in C#, it's possible to do so with the tools that are available out of the box.

If you want to try out referencing C# code using Add-Type, the following article is a good introduction:

https://blogs.technet.microsoft.com/stefan_gossner/2010/05/0...

You know you can write PowerShell cmdlets in C# right? It's super easy.

I love it for both programming and scripting. It's probably not the best option a lot of the time, but I still find myself going back to write things in PowerShell. I don't find myself running into any of the issues you bring up in my experiences. Everyone has something specific they prefer, though. I find coming back to and reading foreign PowerShell to be quite natural, and rarely taxing if formatted well.

I can't pinpoint what I like so much about it either... It just draws me in well. It does devolve in readability when trying to squeeze out every drop of speed, though.

IPC is what I find to be the most challenging for me in PoSH, but I'm not sure if that's due to incompetence.

Syntax is like ice cream. Some people like vanilla. Others like chocolate.

Jeffrey Snover [MSFT]

Syntax is supposed to be composible and intuitive. One shouldn’t have to keep looking docs to find out how to do X. PowerShell has pretty bad, unimaginative and non-intuitive syntax. I was actually chosen many times to keep scripting in old dos syntax because that was more intuitive. Go look in to stackoverflow and forums where people struggle every day on how to do simple things.

I can easily program in C#, Java, C, C++, Swift, Python, etc, etc. There are subtle differences, sure, but generally the differences are minor. If they have difference in one area, they have plenty of similarities in others.

If these are flavors of ice cream, they're all pretty similar and taste good. Where is Powershell in this? It's certainly not vanilla or chocolate... it's more like pepperoni. It's like C# and Perl had a really ugly baby. Even simple things like using -eq and -ne for comparisons seems 40 years out of date.

Come on. Could you please try to be constructive with your feedback?

I use powershell a lot to automate a lot of things and I find it great for scripting. However the syntax is a little weird.

I just to comment on this by saying

That whatever space powershell fills on windows its not a niche .. not a niche at all

I agree with you, powershell is powerful and I guess benefit from being new .. it has amazing uniformity and amazing discover-ability

Anyway, I was saying, powershell fills automation on windows, it is THE automation tool on windows and has been for a while, there is hundreds of commands that you can you to manage and deploy and update almost anything important on windows

This is not a niche, not a niche at all .. it is as far from niche as i can think of

And now that it is being ported to other systems, it had the potential to be THE automation tool for many organization that have mixed environments

So you see, when it was primarily windows, it was not a nice, again because automation on windows is not a niche .. now imagine it beyond even windows

Powershell is about automation, not scripting, and not just the command line ... it is really about automation

Instead of following steps, you automated with one script ..or possibly a small GUI app

I think you and I merely disagree on the meaning of "niche" in this context, rather than on facts about usage of PowerShell.

I was simply saying that PowerShell doesn't serve a unique purpose in my environment that isn't better served by other languages or shells. "Niche" was short-hand for, "This language is particularly well-suited for this task or set of tasks", and I wasn't (intentionally) saying anything about its popularity.

All programming languages have a niche where they are strong. It is not a way of saying, "This language is obscure or not used a lot." It's a way of saying, "For the things I do, I can rule it out, because I don't need to do the things this language does better than others." From what I can tell, scripting (or, "automating", if you prefer that term) Windows is PowerShell's niche. I don't need to script Windows, so I don't need PowerShell.

In short: Saying PowerShell doesn't fill a niche I need to fill is not an insult to PowerShell or a statement about how popular it is. It's merely saying I don't find it suits my needs in my environment (which contains no Windows servers).

As a programmer who knows powershell to an extent, I still make cruddy little console apps rather than piss around with powershell.

That's where powershell failed abysmally.

Programming is automation though. Scripting is a (loosely defined) form of programming. I'm really not sure what the distinction is. You could just as easily say bash "is really about automation", because it would also be true. Water is wet, etc.

PowerShell is useful on Windows because it does something that could not be done easily or at all before, that being automation without using GUI's. It does this by providing hooks into the Windows infrastructure to change settings and perform tasks without fragile registry edits and GUI manipulation. But UNIX systems have no need for this by virtue of it's command-line first design. If MS was still using DOS and ini files the situation would be similar.

So what does PowerShell really offer in UNIX land? Configuring and automating nix systems is drastically different than doing the same on Windows systems, so having a common scripting language probably does not help much.

I guess a better question would be what does PowerShell offer in the way of "automation" that is so much superior to bash and *nix command line programs.

"what does PowerShell offer in the way of "automation" that is so much superior to bash and *nix command line program?"

1- it runs on both unix and windows .. and hopefully more in the future

2- uniformity, all command have the same form, verb-noun

3- discover-ability, you dont need google to find the cmdlet, you can glob search the help system

4- support, there are cmdlets for many systems that bash will never, ever, ever, ever approach or support

5- GUI, you can create a GUI in powershell

> 5- GUI, you can create a GUI in powershell

More than that, it has the entire CLR at its disposal, including the C FFI.

PowerShell was designed to provide a very wide dynamic range of capabilities from interactive actions to simple ad hoc scripts to more formal programming. The goal was to have a single tool that admins and programmers could share to create and manage systems where they could pick how formal they needed to be to solve the problem at hand and can simply modify (vs replace) it as the solution need to be by more people or more production scenarios.

Jeffrey Snover [MSFT]

Powershell has short aliases (and you can define your own too) for the most frequently used commands, and I find the process of reformatting text output between commands to get them to pipe to each other and not choke on formatting differences more cumbersome and time consuming than any extra verbiage added by powershell.

But this can cause other problems. An example would be the way that Powershell for a long time aliased the Invoke-WebRequest cmdlet to both 'curl' and 'wget'. This was supposed to be a convenience feature, but it broke all sorts of scripts that were written to use "real" curl or wget because Invoke-WebRequest didn't accept curl or wget option parameters (oops).

They've fixed this in recent versions by shipping actual curl binaries, but it's a useful illustration of how just aliasing popular shell commands to their Powershell alternatives isn't necessarily helpful.

invoke-webrequest has a "native" short alias too: iwr. I like these native aliases because they use a consistent pattern of abbreviations for verbs and nouns, e.g., the same "i" for invoke is used in icm = invoke-command, iex = invoke-expression, ihy = invoke-history, etc.; then if you look at the nouns in one of those others (since invoke-webrequest is the only "webrequest" cmdlet), they're also consistent, e.g., gcm = get-command, shcm = show-command, trcm = trace-command.

Most of the aliases use a consistent naming pattern too, which I appreciate.

Sometimes I just want to open a shell and run an exe. With powershell you need to run a command which runs the application. I gave up after that. https://stackoverflow.com/questions/1673967/how-to-run-an-ex...

What's wrong with .\example.exe? Or .example.exe, .$exampleWithPath for PS1 files? Just examples that I see in the wild

Didn't work for me, I think you have to prepend with a & so

& notepad.exe

Which isn't complicated I agree but annoyed me.

What version of Powershell are you using?

Just typing "notepad" is enough to launch it. The problems with powershell and executables only really come in to play when argument passing, where some escaping is necessary.

3, we still have win7 at work.

You can download and install PowerShell Core 6 completely side-by-side with Windows PowerShell 3.0. We even have a portable ZIP you can drop down wherever: https://github.com/powershell/powershell/releases

The only reason to use iex is if the thing you're trying to execute is not directly the name of the process. So you need & for `&'notepad'` and `&$string_variable` but not `notepad`

That's not quite correct (and neither is that StackOverflow answer).

If you want to execute the EXE stored in a variable or whatnot, then yes, you need `&`, which I think is borrowed from Perl. But otherwise, the rules in PowerShell are the same as a Unix shell: if it's in the PATH, just type the command name (with or without the .exe); otherwise, use the full path.

>That's not quite correct (and neither is that StackOverflow answer).

The SO answer isn't wrong. The EXE there has a space in the path. The answer uses a string literal for it and thus needs &. It could of course escape the spaces with ` instead; then it wouldn't need a string literal and thus not need &.

I concur. For me personally, PowerShell's dependency on the .Net Framework just makes me write what I need in C# and then deploy to clients using GP. In my environment the client computers don't have a consistent .Net version which follows that they don't have a consistent PS version installed either. For a recent data collection program it was faster and easier to write it in C# and target .Net V2 then to fiddle with PS, and its execution policy https://stackoverflow.com/questions/4037939/powershell-says-...

What kind of C# are you writing, is it a compiled exe you're distributing or is there some way to run C# script on windows?

I've done almost nothing with PowerShell due to the brutal syntax, would love to use a nice language like C# or Python for the control structure (logic, looping, etc) and then just calling out to PowerShell when needing to execute a function. Seems like that should be a possibility, although passing data through may be problematic.

You don't need to 'shell' out to call PoSh. You can host it yourself, see https://msdn.microsoft.com/en-us/library/dn569260(v=vs.85).a... Passing data is quite easy, both ways, is just C# objects. This can be convenient when faced with one of those 'Powershell only API' features.

It's a compiled binary (PE). I've read through numerous books on PowerShell and I don't see its value in comparison to using any other .Net language. All namespaces in PowerShell are available in C#/VB/blah so why deal with the annoyance of ensuring that the client has not only the required version of .Net Framework/Core installed, but also the PowerShell interpreter version too? Perhaps it's because PowerShell doesn't require a compiled binary so it can be modified and run without an extra step, and it allows for easy add-ins with the cmdlet interface.

csi.exe runs C# interactively as a script.

You can run c# directly by using add-type in powershell