4 ms·

I certainly hope the shell doesn't have a renaissance. Just today I was updating my dotfiles/customizing my OS, and I had to swap out several shell scripts for

I certainly hope the shell doesn't have a renaissance. Just today I was updating my dotfiles/customizing my OS, and I had to swap out several shell scripts for Python scripts because I couldn't edit shell. The scripts looked like arcane rituals, not editable code.

stephenr 6y ago
Shell scripts have some idiosyncrasies sure, but at least they don't rely on significant white space.
- yuribro 6y ago
  Not a pure shell, but Makefiles do rely on whitespace. I never understood why so many people care about that (not to mention that python uses the curly braces as a useful syntax element for dicts & sets)
  - stephenr 6y ago
    Makefiles don't gernally have anything more than one level of indentation that is significant. People care about significant whitespace because it's inferring heavy semantic meaning from something that's by default invisible, and even when shown visibly, may not actually be particularly obvious.
  - simias 6y ago
    I use Python a lot so it's not a deal breaker to me, but even after years of use significant whitespace is still firmly in the "bad ideas" category for me. It's form over function. When I code in C and move some code around I can just tell my editor "reindent this code" and it looks fine immediately. With Python I always have to double-check to make sure everything is in the right place. Similarly I almost never have to reindent anything manually in C. The editor always knows where I should be based on the number of open braces. In python I often have to readjust. A common situation where that's annoying is if I want to add code after and outside a block, in C I just tell vim to open a line after the closing bracket and I'm immediately at the right location, in Python doing this will have the cursor at the wrong level of indentation. It's not the end of the world and it's bikeshed territory but for me significant whitespace is in the same category as automatic semicolon insertion in JavaScript, I sorta get why somebody thought it was a good idea at some point but it's just more trouble than it's worth in practice. Python wanted to be the anti-perl and it went too far in some places. Pseudo-code is only "pseudo" for a reason.
    - yuribro 6y ago
      I get the point about moving code around, I guess it can be problematic with some tools. In my experience PyCharm gets it right, and when moving around code in vim I can just change the indent level on the whole block at once, but it is dangerous to miss a line at the end and move it by mistake one level up. Also I feel like changing the indent of the cursor (manually) when exiting a block is more or less the same work as typing }, and I got used to it to the point it becomes automatic. But I guess at the end of the day it's a matter of priority. Is that more important than having special syntax for dicts? I really like the fact that we have the tuple/list/dict distinction, and would be great if we had a different paren type for sets (which would have eliminated the {} vs set() issue). On the other hand, going with begin..end or if..fi blocks would be even more antagonizing than using whitespace.
jedevc 6y ago
As I read it, the article is more about the concept of scripting in general - and not about any specific language bash/zsh/powershell/etc. I definitely agree, I think that POSIX-shell scripts can often be completely unreadable and difficult to maintain. But I think the concept of scripting in itself is fine, even though the implementations we might use today are slightly outdated. At the moment there's a huge number of interactive shells like nushell and xonsh being built, but they don't really focus on scripting; I'd really love to see more competitors attempting to take on the mess of bash scripts.
- stephenr 6y ago
  > I think that POSIX-shell scripts can often be completely unreadable and difficult to maintain. The same could be said for any language, if you're not familiar with it.
  - lhoursquentin 6y ago
    The thing is when you restrict yourself to only what POSIX specifies you don't even have basic data structures, no array, no hash map not even local variables, and that often leads to code that relies on multiple hacks. For instance: you can't even slice "$@" which is the only array like construct specified by POSIX (excluding unsafe splitting), so you end up shifting and re-enqueuing with set -- "$@" "$1", which is unreadable. Want to read a single character? Impossible with the POSIX read, but you can workaround with dd etc. All those workarounds to POSIX limitations are fascinating, but it forces a lot of arcane constructs, that's for sure. And of course this is usually the point where you ask yourself if you've chosen the correct language for the task, but that's another debate.
    - stephenr 6y ago
      > so you end up shifting and re-enqueuing with set -- "$@" "$1", which is unreadable. How is that unreadable? Set all the positional arguments as is, then set the first one again, into new positional arguments. I'm not sure why you want the first arg twice, but thats your call. Either way, it's hardly unreadable. > And of course this is usually the point where you ask yourself if you've chosen the correct language for the task, but that's another debate. It isn't another debate though. It's all the same debate: do you know the language you're reading and/or writing? Do you know what it can do, what it can be pushed to do, and what it really shouldn't do? Those are all related to the same basic point: if you think Shell is unreadable, I'd suggest it's because you don't know shell. Remember readable means that you can read and understand it. Not that it's written out in words that someone with on page 1 of "how to program for dummies" can understand.
chubot 6y ago
I remember seeing shell for the first time ~15 years ago, and it certainly looked like an arcane ritual. Syntax like var=value and [ x -eq y ] was super weird coming from C and Python. My Oil project fixes many of these problems: http://www.oilshell.org/blog/2020/01/simplest-explanation.html http://www.oilshell.org/blog/2020/01/simplest-explanation.ht... (as well as fixing semantic problems; it's not just syntax)

stephenr 6y ago

Shell scripts have some idiosyncrasies sure, but at least they don't rely on significant white space.

yuribro 6y ago
Not a pure shell, but Makefiles do rely on whitespace. I never understood why so many people care about that (not to mention that python uses the curly braces as a useful syntax element for dicts & sets)
- stephenr 6y ago
  Makefiles don't gernally have anything more than one level of indentation that is significant. People care about significant whitespace because it's inferring heavy semantic meaning from something that's by default invisible, and even when shown visibly, may not actually be particularly obvious.
- simias 6y ago
  I use Python a lot so it's not a deal breaker to me, but even after years of use significant whitespace is still firmly in the "bad ideas" category for me. It's form over function. When I code in C and move some code around I can just tell my editor "reindent this code" and it looks fine immediately. With Python I always have to double-check to make sure everything is in the right place. Similarly I almost never have to reindent anything manually in C. The editor always knows where I should be based on the number of open braces. In python I often have to readjust. A common situation where that's annoying is if I want to add code after and outside a block, in C I just tell vim to open a line after the closing bracket and I'm immediately at the right location, in Python doing this will have the cursor at the wrong level of indentation. It's not the end of the world and it's bikeshed territory but for me significant whitespace is in the same category as automatic semicolon insertion in JavaScript, I sorta get why somebody thought it was a good idea at some point but it's just more trouble than it's worth in practice. Python wanted to be the anti-perl and it went too far in some places. Pseudo-code is only "pseudo" for a reason.
  - yuribro 6y ago
    I get the point about moving code around, I guess it can be problematic with some tools. In my experience PyCharm gets it right, and when moving around code in vim I can just change the indent level on the whole block at once, but it is dangerous to miss a line at the end and move it by mistake one level up. Also I feel like changing the indent of the cursor (manually) when exiting a block is more or less the same work as typing }, and I got used to it to the point it becomes automatic. But I guess at the end of the day it's a matter of priority. Is that more important than having special syntax for dicts? I really like the fact that we have the tuple/list/dict distinction, and would be great if we had a different paren type for sets (which would have eliminated the {} vs set() issue). On the other hand, going with begin..end or if..fi blocks would be even more antagonizing than using whitespace.

jedevc 6y ago

As I read it, the article is more about the concept of scripting in general - and not about any specific language bash/zsh/powershell/etc. I definitely agree, I think that POSIX-shell scripts can often be completely unreadable and difficult to maintain. But I think the concept of scripting in itself is fine, even though the implementations we might use today are slightly outdated. At the moment there's a huge number of interactive shells like nushell and xonsh being built, but they don't really focus on scripting; I'd really love to see more competitors attempting to take on the mess of bash scripts.

stephenr 6y ago
> I think that POSIX-shell scripts can often be completely unreadable and difficult to maintain. The same could be said for any language, if you're not familiar with it.
- lhoursquentin 6y ago
  The thing is when you restrict yourself to only what POSIX specifies you don't even have basic data structures, no array, no hash map not even local variables, and that often leads to code that relies on multiple hacks. For instance: you can't even slice "$@" which is the only array like construct specified by POSIX (excluding unsafe splitting), so you end up shifting and re-enqueuing with set -- "$@" "$1", which is unreadable. Want to read a single character? Impossible with the POSIX read, but you can workaround with dd etc. All those workarounds to POSIX limitations are fascinating, but it forces a lot of arcane constructs, that's for sure. And of course this is usually the point where you ask yourself if you've chosen the correct language for the task, but that's another debate.
  - stephenr 6y ago
    > so you end up shifting and re-enqueuing with set -- "$@" "$1", which is unreadable. How is that unreadable? Set all the positional arguments as is, then set the first one again, into new positional arguments. I'm not sure why you want the first arg twice, but thats your call. Either way, it's hardly unreadable. > And of course this is usually the point where you ask yourself if you've chosen the correct language for the task, but that's another debate. It isn't another debate though. It's all the same debate: do you know the language you're reading and/or writing? Do you know what it can do, what it can be pushed to do, and what it really shouldn't do? Those are all related to the same basic point: if you think Shell is unreadable, I'd suggest it's because you don't know shell. Remember readable means that you can read and understand it. Not that it's written out in words that someone with on page 1 of "how to program for dummies" can understand.

chubot 6y ago

I remember seeing shell for the first time ~15 years ago, and it certainly looked like an arcane ritual. Syntax like var=value and [ x -eq y ] was super weird coming from C and Python. My Oil project fixes many of these problems: http://www.oilshell.org/blog/2020/01/simplest-explanation.html http://www.oilshell.org/blog/2020/01/simplest-explanation.ht... (as well as fixing semantic problems; it's not just syntax)