A fair analogy, given how much money I have made as someone who is willing to deal with metaphorical asbestos.

The question is, were you the one cleaning up the metaphorical asbestos or creating it? :)

There's plenty of money to be made in both.

Y'all just have bias against the string system.

Writing decent code in bash is just as possible as any other language.

I stick to POSIX sh but same difference.

Why POSIX sh? Bash is everywhere. I once in my career had access to and needed jobs performed on a mainframe with AIX running. It had bash, it had ruby, it had day, it had fish shell. I couldn't and can't understand why people insist on asceticism (Korn shell, POSIX sh) when nicer options are available.

Eh, I simply don't need bash.

Every few dozen scripts or so I'll change the shebang to bash to have more than 1 array, but other than that I seldom pine anything that it has to offer. I believe it's a bloated mess along with most GNU utils, so avoiding it is partially out of spite, but I wouldn't impair my code to do so.

*zsh ... Not "day"

dash is 10% of the size of bash. You don't need the interactive features when running shell scripts, and the few "extra" features are pretty crap anyway (arrays? yeah right).

"Thirteen Incorrect Ways and Two Awkward Ways to Use Arrays"

http://www.oilshell.org/blog/2016/11/06.html

Yeah I should clarify; I think it's well past the time of sh.

Still, sh is unrivaled for portability and brevity/velocity; I wouldn't swap virtually any the shell scripts I've written for python scripts. I think sh is a decent and often well-suited tool if you can manage to wield it properly (not a straightforward endeavor).

I look forward to checking out oilshell though, so thank you~

Edit: FWIW for arrays in POSIX sh I generally only use:

  set -- a b c
  echo $#
  echo "$1"
  shift
  echo "$@"

Once in a blue moon "$*" or maybe an unquoted $@. See 2.5.2 of https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V... (My go-to reference)

In config management, I often think to myself as I'm trying to figure out how to express in the DSL some simple thing, that I'd rather just write the bash. Why should I learn each new fashionable DSL just to have it translate back to the shell commands I spent so long translating into the DSL? It's a game of telephone.

This is a cool/fun project, but I've got to say, if I'm troubleshooting a production issue I'd so rather be dealing with the (shorter) generated bash equivalent than the bashable DSL in the example they have there.

My answer: so that other people can actually work with the scripts you write.

Some DSLs are definitely a waste of time (hello Jenkins!), but in the anecdotal experience of myself and literally everyone I’ve talked to, Ansible is massively easier to learn than Bash. I’ve had junior devs (who don’t even know Python!) writing and maintaining useful tasks within minutes, and that’s not even an exaggeration.

Shell scripts, IME, work great until you need a certain amount of logic, and then they become a collapsing Death Star of edge cases and tribal-knowledge pitfalls.

Not only Bash but everything that is not compiled. The amount of grief interpreted languages introduced is outrageous.

> everything that is not compiled.

Agreed. I see fixes like this in bashible that would have never happened in a compiled language with static types:

https://github.com/mig1984/bashible/commit/63fcc766d0244a6fb...

Compilation does not guarantee neither readability nor ease of maintenance.

Interpreted languages typically give you a very quick feedback loop; they're great fit with scripts and utilities that you won't ever write UT for.

And I did not claim any of those. Btw. a typical feedback loop for many of the compiled languages is 100ms (for example ReasonML).

My main problem with interpreted languages is the duality of their implementation. Especially Python suffers from this, the high-performance part of the language is in C, C++, Fortran. When you install a package you get all of the problems of those languages on the top the Python problems (versions, environments, installed libraries, etc.).

What I would like to have is the Rust way, compile the code on any platform and target any other platform, configuring even the libc that you want to use. OcaML also works very nicely, compiling the code to native or byte code.

I think the detour to interpreted languages set us back in the long run.

if Bash is asbestos, what are Windows Batch-scripts?

Dry mud