When powershell 1.0 came out I LOVED the concept of piping objects like so much streams. In my experience there were two camps of powershellers, the scripters a

When powershell 1.0 came out I LOVED the concept of piping objects like so much streams. In my experience there were two camps of powershellers, the scripters and the programmers. The scripters, probably the more experienced folks would use abbreviations, shorthand and all-lowercase. The programmers like myself would predominantly use powershell on less-frequent occasions to glue our apps together and PascalCase and verbosity has already been burnt into our brains. Powershell, like perl, took that philosophy that welcomed both parties to write code as they pleased. But then powershells 2 and 3 and 4 came out, and all that stuff I learned in v1 became deprecated. And I wanted a powershell script that would just reliably run on any, say, windows machine 2003 or beyond. But when I google for something like 'how do I invoke an osql.exe query command? how to escape the quotes?', or, 'how to load a dll and having an adjacent config file and run a method?' I get so many different answers ranging from woefully misguided to version-specific to syntax so wildly different to the untrained eye they look completely different yet being effectively equivalent. I inevitably spend hours crawling google and cobbling together the bits that work cross-platform, document heavily and sit in amazement at how much work it took to do something one would think was simple. It's a shame but my experiences with powershell as an occasional user have shifted from enthusiasm to seeing it as an arcance even punishing experience when I'm used to bash or python. I hope this doesnt sound mean in any way, its just that when youre talking with a computer, words like grep/sed/awk and regular expressions bear a learning curve but once you get past that barrier it is much easier to communicate succinctly with the computer with what you really want to do.