I feel all this. :)

Incidentally a lot of my recent work is basically glorified Bash scripts (Nix takes care of portability issues for us, but the language is still Bash), and then we've recently created a tool in Python that we invoke as a command-line application.

I try to write my Bash in a tasteful style: I embrace bash features (since my scripts ship with with a precise version of bash anyway) where they make things clearer or more concise (for instance, associative arrays). I do use bash parameter expansion, mostly to avoid nesting conditionals or long lines that read like

  test ... && declare ...

but I usually include a link to the bash manual page on parameter expansion in a comment next to them as a courtesy. I favor long flags and split most commands with multiple args out across multiple lines.

I do use one bash option via `shopt`, namely `lastpipe`. It lets you assign variables from pipelines, like:

  cat someConfig.toml \
    yj -tj \
    jq -r '.someField.nestedField' \
    read VAR

instead of using a subshell on the right-hand side of an assignment. Almost all of my assignments take that form, and there are no unnecessary intermediate assignments, virtually no mutation of variables, and very few ifs or case statements. I think and hope that it's possible to read any chunk of these scripts, then, with very little context: you can focus on a single pipeline at a time without regard for the rest of the program or any variable assignments.

I also just don't do any parsing or validation of arguments in bash. Once I feel I need those, I use something else. Those scripts aren't things I present to outside teams as interfaces.

I find it easier to read my bash scripts than our Python code, but I don't have much history with Python, and I'm also partial to those kinds of pipelines— they're basically the same as method chaining with `.` to do basic FP stuff in OOP languages like Scala and Java and Ruby.

But I also wonder where the line is and what business my team even has writing Python when none of us has much Python experience at all. We've succumbed to the standard argument that we should use Python because it's easy to hire for, which I think is probably a bad one. As the program gets larger and more complex, does anything come after Python for us? How do we know when it's time or if a given program should (from the start) go there?

I don't know yet, but as I try to level up my Python skills, I'm also starting to learn Rust with writing CLI tools in mind, with the book Command-Line Rust. I'm hoping that after that, the upcoming Refactoring to Rust will help me devise a way to decide when switching to Rust is actually a good vs. bad idea, as well as how to do it.