4 ms·

The author has a few good points. I want to love PS as well, but in practice it has too many gotchas and pitfalls that seem to pop up every time I write a scrip

The author has a few good points. I want to love PS as well, but in practice it has too many gotchas and pitfalls that seem to pop up every time I write a script more than a few lines. Sure, all languages have these, but the ones in PS feel nastier and more subtle than most, compounded by the fact that it's not a language I use more than once every few months and should be easy to pick up and put down. Basic stuff like parens, commas, function calls, casting, variable interpolation and arrays are frequently surprising. Many behaviors fail silently. For example, arrays with 1 element behave differently than arrays with 2+ elements. PS is "smart" and treats the 1-element array as a scalar. Why? I've wasted hours dealing with arrays in PowerShell. See this post for a sampling of the problems: https://stackoverflow.com/a/69644807/6243352 https://stackoverflow.com/a/69644807/6243352 Even without the gotchas, case insensitivity, optional abbreviations, optional parens, etc, make PS scripts harder to read and debug than they need to be. PS feels like a mashup of many of the most confusing parts of PHP and Perl and adds its own fresh mess on top. Adding parameters and resolving a few of Bash's failings isn't much of an achievement given ~20 years of time to design it properly. Neither language is as easy to work with as it should be.

Riverheart 4y ago
If I had a nickel for every time I had to debug some crazy Bashism. PowerShell can be finicky at times but is a walk in the park compared to the alternatives. For basic stuff like if/else comparisons I don’t need to lookup how many parens or square brackets to use for strings or arithmetic or recall if 0/1 is true false or reverse. Maybe I should just compare “false”/“true” strings or use true/false commands instead which have their own issues. PowerShell has real functions, not just exit codes and text streams so you can easily write maintainable scripts past 100 lines. It’s got a debugger. It’s got modules and a package gallery. It’s got autocomplete and help messages. It’s got try/catch/finally instead of traps. It’s got an optional type system so you can be as loose or strongly typed as you want. It’s cross platform so the Windows devs don’t get confused migrating to Linux. It’s got batteries included for everything between cmdlets and .net. Anything you can do in C# can be replicated. Sed/awk/Grep are nice but sometimes you just want structured data converted into an object to pass around functions instead of reinventing the wheel. Case sensitivity is a feature, $foo and $Foo should be the same and if they’re not you should call it something different or invoke it differently. “$foo = new [foo]” separates variables from types. “$env:foo” namespaces your env vars. In Bash is FOO a var, constant or env var? Good PowerShell is readable with little effort. Good Bash is readable with significant effort if you are familiar with Bash and the problem domain already.
- ggorlen 4y ago
  Case sensitivity isn't a major deal, but it's another example of the designers trying too hard to be clever and "user friendly". A good scripting language should try to reduce friction relative to other programming languages, most of which are case sensitive. I'd like to see a native OS scripting language that has a low bar of entry, isn't silent on undefined variables and other common mistakes, imposes syntactical consistency like Go or Python, has decent basic data structures and isn't riddled with pitfalls. PS isn't that language. If Bash and PS were good, it'd be so much easier to bring non-programmers into the command line so they can automate tasks and hack on their systems. Unfortunately, these languages aren't doing that, much less passing the usability test with most programmers who'd just assume script with Py, Perl, JS, or whatever their preferred language is.
  - Riverheart 4y ago
    Python/Perl/JS/Ruby aren’t shells so the busy sysadmin doesn’t need to ask themselves at what point they rewrite their script in a sane language and a Windows dev won’t typically use those languages, especially as you’d have to call the Win32 api for lots of behavior or bring in many external packages for things PowerShell includes for free. In terms of ease of use PowerShell and ISE is available on every PC, is more consistent than Bash and more powerful than a user friendly shell like Fish. I don’t know how you get easier than Get-Foo, Set-Foo. Bash doesn’t really offer anything out of the box except the ability to glue external commands together and most people use it because of its availability and portability rather than its virtues as a language. Zsh, Fish, Elvish, Xonsh haven’t managed to displace it and Xonsh is even written in Python. The only thing I can think of that could make automation more friendly to nontechnical users is something like autohotkey to mimic manual interaction.
    - ggorlen 4y ago
      The point is, if a developer is resorting to another language just to write a 20 line script with a data structure, a loop and control flow, that's a failure of the shell. I don't want to have to use anything other than PS to script on Windows, but I'm often forced to in order to be productive. It's not saying much for the language that Windows sysadmins use PS primarily. Like Bash, the reason people use it is availability, not language virtue. See last year's Stack Overflow developer survey, where Bash was more popular than PS (29% (Bash) to 12% (PS)[1]) and loved (57% (Bash) to 43% (PS)[2]). I don't like Bash. I'm using it as a yardstick to show how disappointing PS is. [1]: https://survey.stackoverflow.co/2022/#most-popular-technologies-language https://survey.stackoverflow.co/2022/#most-popular-technolog... [2]: https://survey.stackoverflow.co/2022/#technology-most-loved-dreaded-and-wanted https://survey.stackoverflow.co/2022/#technology-most-loved-...
psd1 4y ago
Look up strict mode. Array unrolling is a legitimate gripe. The design justification is that Powershell is pipeline-oriented. On occasions where you specifically need an array, either type your variable or use the array operator: [object[]]$foo = 42 $foo = @(42)
- ggorlen 4y ago
  Good point about strict mode. However, I've collected a few gotchas[1] that I don't think strict mode helps with (as seems to be the case with languages that offer strict mode, it's not enough). If you're curious and have time to take a look and let me know what I might have misunderstood, I'd appreciate it. I think I'm missing which problem your code solves. There are a few array issues in my gotcha journal. Adding types like [object[][]] doesn't seem to help with getting PS to understand nested arrays with 1 element, for example, and $foo = @(42) is the array declaration syntax I usually use. [1]: https://gist.github.com/ggorlen/1e337f211f508124321c8bc7c1d264ed https://gist.github.com/ggorlen/1e337f211f508124321c8bc7c1d2...

Riverheart 4y ago

If I had a nickel for every time I had to debug some crazy Bashism. PowerShell can be finicky at times but is a walk in the park compared to the alternatives. For basic stuff like if/else comparisons I don’t need to lookup how many parens or square brackets to use for strings or arithmetic or recall if 0/1 is true false or reverse. Maybe I should just compare “false”/“true” strings or use true/false commands instead which have their own issues. PowerShell has real functions, not just exit codes and text streams so you can easily write maintainable scripts past 100 lines. It’s got a debugger. It’s got modules and a package gallery. It’s got autocomplete and help messages. It’s got try/catch/finally instead of traps. It’s got an optional type system so you can be as loose or strongly typed as you want. It’s cross platform so the Windows devs don’t get confused migrating to Linux. It’s got batteries included for everything between cmdlets and .net. Anything you can do in C# can be replicated. Sed/awk/Grep are nice but sometimes you just want structured data converted into an object to pass around functions instead of reinventing the wheel. Case sensitivity is a feature, $foo and $Foo should be the same and if they’re not you should call it something different or invoke it differently. “$foo = new [foo]” separates variables from types. “$env:foo” namespaces your env vars. In Bash is FOO a var, constant or env var? Good PowerShell is readable with little effort. Good Bash is readable with significant effort if you are familiar with Bash and the problem domain already.

ggorlen 4y ago
Case sensitivity isn't a major deal, but it's another example of the designers trying too hard to be clever and "user friendly". A good scripting language should try to reduce friction relative to other programming languages, most of which are case sensitive. I'd like to see a native OS scripting language that has a low bar of entry, isn't silent on undefined variables and other common mistakes, imposes syntactical consistency like Go or Python, has decent basic data structures and isn't riddled with pitfalls. PS isn't that language. If Bash and PS were good, it'd be so much easier to bring non-programmers into the command line so they can automate tasks and hack on their systems. Unfortunately, these languages aren't doing that, much less passing the usability test with most programmers who'd just assume script with Py, Perl, JS, or whatever their preferred language is.
- Riverheart 4y ago
  Python/Perl/JS/Ruby aren’t shells so the busy sysadmin doesn’t need to ask themselves at what point they rewrite their script in a sane language and a Windows dev won’t typically use those languages, especially as you’d have to call the Win32 api for lots of behavior or bring in many external packages for things PowerShell includes for free. In terms of ease of use PowerShell and ISE is available on every PC, is more consistent than Bash and more powerful than a user friendly shell like Fish. I don’t know how you get easier than Get-Foo, Set-Foo. Bash doesn’t really offer anything out of the box except the ability to glue external commands together and most people use it because of its availability and portability rather than its virtues as a language. Zsh, Fish, Elvish, Xonsh haven’t managed to displace it and Xonsh is even written in Python. The only thing I can think of that could make automation more friendly to nontechnical users is something like autohotkey to mimic manual interaction.
  - ggorlen 4y ago
    The point is, if a developer is resorting to another language just to write a 20 line script with a data structure, a loop and control flow, that's a failure of the shell. I don't want to have to use anything other than PS to script on Windows, but I'm often forced to in order to be productive. It's not saying much for the language that Windows sysadmins use PS primarily. Like Bash, the reason people use it is availability, not language virtue. See last year's Stack Overflow developer survey, where Bash was more popular than PS (29% (Bash) to 12% (PS)[1]) and loved (57% (Bash) to 43% (PS)[2]). I don't like Bash. I'm using it as a yardstick to show how disappointing PS is. [1]: https://survey.stackoverflow.co/2022/#most-popular-technologies-language https://survey.stackoverflow.co/2022/#most-popular-technolog... [2]: https://survey.stackoverflow.co/2022/#technology-most-loved-dreaded-and-wanted https://survey.stackoverflow.co/2022/#technology-most-loved-...

psd1 4y ago

Look up strict mode. Array unrolling is a legitimate gripe. The design justification is that Powershell is pipeline-oriented. On occasions where you specifically need an array, either type your variable or use the array operator: [object[]]$foo = 42 $foo = @(42)

ggorlen 4y ago
Good point about strict mode. However, I've collected a few gotchas[1] that I don't think strict mode helps with (as seems to be the case with languages that offer strict mode, it's not enough). If you're curious and have time to take a look and let me know what I might have misunderstood, I'd appreciate it. I think I'm missing which problem your code solves. There are a few array issues in my gotcha journal. Adding types like [object[][]] doesn't seem to help with getting PS to understand nested arrays with 1 element, for example, and $foo = @(42) is the array declaration syntax I usually use. [1]: https://gist.github.com/ggorlen/1e337f211f508124321c8bc7c1d264ed https://gist.github.com/ggorlen/1e337f211f508124321c8bc7c1d2...