What I particularly dislike is how it automatically filters output, and you have to use arguments or other applets to give you fuller output. It just strikes me as being the exact opposite of how any particular command or script should work.
No, it is not the opposite. It's giving the information that is the most usable and easily read by a human. Even *nix utilities do this. Hell, type "ls" and you don't get the file sizes and dates; you have to add -l to get those details.
And objects, big fucking deal. I've been using Bourne variants for a quarter of a century and never thought "Boy, I wish I had classes".
That just shows that you are stuck in the mindset of manipulating text outputs of commands to find the information you need. It certainly shows a lack of imagination that there could be anything better. What it doesn't show is that there is anything wrong with the concept of PowerShell simply because you don't get it.
When you start writing scripts that make web requests that you can read the value you want without having to do clunky regular expressions, then directly updating specific cells in a spreadsheet (including with formatting) then you realise just how much easier this is with an object-based system. Or how about writing your own software as a .NET library so that the same code can be used for manual viewing in a .NET application or with powerful scripting with PowerShell with no additional effort.
No, it shows that you need to use the right tool for the job.
For example, if I'm writing a web request in a Bash script then either I'm calling out to wget/curl to handle it, or I'm writing a Python script (or another language) that will do the work elegantly and isolate it to just that script. I don't do web requests directly in Bash - I use the right tool. All of these combine together through the return value of the program and stderr/stdout/stdin to pass data back and forth using basic text - which is typically all you need. If more structured information is needed then it's really easy to dump it into a structured temp file and provide the path for that.
Again, debugging is very easy - just at "echo" where needed, capture outputs to text files, and keep temp files from destroying themselves to analyze their contents. It's all pretty basic stuff and no advanced computer science degree is required or even knowledge of some special IDE (f.e VisualStudios) required to analyze or debug the stuff.
And yes, I'm aware that you can use debuggers with PS, but then I have to load a debugger - which means yet another tool has to be installed and run - more memory required to figure out what is going wrong.
And yes, I get the desire for OO-based scripts - but then, if I wanted that I would go to Python, Scala, or one of many other OO-based languages.
Really, the only useful thing I found in PS was the ease with which one can access the Windows Registry since they treat it like another file path ("cd \\hklm\..."); this is not necessary on a non-Windows system since the Windows Registry doesn't exist.
