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.
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.
Check out http://www.oilshell.org/ -- that is exactly its purpose. It runs your bash scripts, and then you can upgrade gradually to a better language.
It's also an interactive shell, but I concentrate on the language first.
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.
> 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.
> Remember readable means that you can read and understand it
Yes you are right, my usage of "readable" was probably wrong there.
Maybe the point I was trying to make was less about the individual constructs but more about how the lack of "common" features makes the whole program less "understandable", or maybe less easy to get familiar with, simply due to the amount of code needed to achieve a specific task.
The same way assembly is considered less "readable" than C. Not because assembly is less readable on a line by line basis, it's even simpler, but because of the number of lines and operations needed to achieve a simple task.
Basically it's easier to understand 10 lines than a 1000.
