I disagree that bash needs to be cryptic, but I've also written perl code, so maybe any resemblance of a sane perspective was beaten out of me.

> It's practically impossible to write correct Bash without shellcheck.

I agree with this, since I've never seen a bash script, in the wild, that passed the important bits of shellcheck, without already being passed through spellcheck. I challenge anyone that thinks they've written good bash, with any significant level of complexity, to run that script through shellcheck. Each time I've done this, when starting at a new company, the response has usually been "Will not fix. That's why you don't use spaces in filenames/paths".

> I disagree that bash needs to be cryptic

But it's not a developer's choice - Bash's syntax is cryptic itself. Here's a random sampling of common patterns:

Arrays:

  - `${#myvar[@]}`: unreadable

  - `mapfile myvar < <(grep pattern file)`: "mapfile" is not exactly a clear term (there's the synonym
    "readarray", but "mapfile" is the reference; worse, you may find both used inconsistently); the
    command as I wrote it also has two problems

Strings:

  - `${myvar##.*}`: unreadable

  - `echo $(IFS=,; echo "${myvar[*]}")`: unreadable; most also don't know the difference between `[@]`
    and `[\*]`; this doesn't also work for two-char join operations

  - `[[ $myvar =~ $(echo '\bpattern\b') ]]`: unreadable, and most don't know why command substitution
    is needed

Redirections:

  - `3>&2 2>&1 1>&3`: most don't know what this means

One can certainly get an idea of what's going on; but one gets an idea of what's going on also when reading assembly with labels.