I haven't worked extensively in Bash alone but I did work extensively in Make for a while and I can say with confidence: the specialized old tooling languages are extremely good at what they do, Make goes out of its way to make building things extremely slick. These language tools were designed to tackle every problem in their realm because, for a lot of people, there wasn't an alternative - their structure shows clear and careful design intent.

Can you give some examples? I've personally found bash to be among the most difficult to work with. If I need to do something in bash I'd rather keep it as a lightweight wrapper around a ruby script or something, though I know that isn't always an option

For a pretty good example of a readable/fun program written in bash, the KISS package manager stands out: https://github.com/kisslinux/kiss/blob/master/kiss

Neofetch is also written in bash: https://github.com/dylanaraps/neofetch/blob/master/neofetch

For my own work, I once wrote a functional file system based irc client in ~50 lines of bash: https://github.com/retrohacker/irc-sh/blob/master/main.sh

To learn bash:

* https://tldp.org/LDP/abs/html/

* https://github.com/dylanaraps/pure-bash-bible

Bash is about pipelines which is a rather functional concept. If you can exploit these you can write succinct, readable and effective bash IMHO. If you're just stringing together a lot of conditionals it gets ugly fast.

There isn't such a thing as readable bash, as a significant amount of its syntax is symbolic (and cryptic, by the way), and it's full of warts and unintuitive quirks.

Writing very simple scripts is certainly simple, but anything even a bit functionally more advanced (arrays, but even strings cycling or splitting is quirky) is a pain. Heck, even something as simple as process substitution is horribly unsafe (I wonder how many devs know how/why).

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

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.

If you are manipulating files and processes, bash is a very natural and succint language to do so. Programs are much more elegant than a generic programming language.

I found that nobody actually works in "pure bash". There's always sed, awk, perl, something to do fractional math, etc.

Do you have a link to the deck? I want something like that.