For interactive use, tab-completion essentially makes this a non-issue, because shells add escaping in the appropriate places.

For scripting, where spaces are harder to deal with, unfortunately there's just not much you can do; your two options are basically to learn all of your particular shell's patterns for dealing with whitespace in filenames, or only write scripts in something other than a POSIX shell.

I care about types not just because I like having stronger confidence in my own software, but because, as a user, bugs are really annoying, and yes, I'm confident that stronger type systems could have caught bugs I've seen in the wild as a user.

But how does the alternative solutions compare with regards to maintainability?

Which alternative solutions are you thinking of, and have you tried them?

Rust has been mentioned several times in the thread already, but Go also prohibits "standard" OOP in the sense that structs don't have inheritance. So have you used either Rust or Go on a large project?

You don't need to do any of those things with Go or Rust. Interfaces/traits provide the capability for dynamic dispatch.

It's not a strawman, though, because Martin's actual example code in the book is like this, including a full module he rewrites toward the end.

This "full on rage essay" is nine sentences, including the tl;dr and the sentence fragments. There's really not a big difference between telling your coworkers a story like this and posting about it on social media.

But in the browser. My complaint with JavaScript is that it was effectively the only choice for in-browser logic up until WebAssembly was stabilized, and even now it requires JS glue code.

It's simply not true that there "aren't really that many definitions of OOP", much less that the guide you've linked is "comprehensive" when it is specifically about Java.

This is a good, brief post about the different conflicting definitions: https://paulgraham.com/reesoo.html

This is a much more comprehensive but also less focused overview, with many links, from a site that is effectively both a wiki and a forum: https://wiki.c2.com/?ReesOnObjectOrientedFeatures

One problem with this is that C is in no way the "roots" of programming; it's older than most of the languages we use today, but Fortran, Lisp, and Cobol are all older and are also still in use. (And of course there are other languages that predate C but have mostly fallen out of use, such as Pascal.) It feels "low-level" because it closely reflects the hardware for which it was originally designed, the PDP-7 and later the PDP-11. But in fact it hasn't truly been "low-level" for a long time: I highly recommend the ACM article "C Is Not a Low-level Language; Your computer is not a fast PDP-11."

I very much understand thinking that Rust has too much hype, but the differences between C and Rust are so fundamental that "switching between" them just to "keep your interest fresh" seems ill-advised to me. To be honest, your statements about both C and Rust so far seem pretty superficial; have you actually used Rust for anything nontrivial?

C syntax is simple, yes, but C semantics are not; there have been numerous attempts to quantify what percentage of C and C++ software bugs and/or security vulnerabilities are due to the lack of memory safety in these languages, and although the results have varied widely, the most conservative estimate (this blog post about curl; see the section "C is unsafe and always will be") ended up with an estimate of 40%, or 50% if you only count critical bugs. If I recall correctly, Microsoft did a similar study on one of their projects and declared a rate closer to 70%.

This means that the choice of language is not just about personal preference. Bugs aren't just extra work for software developers; they affect all users of software, which means they affect pretty much everyone. And, crucially, they're not just annoyances; cyberattacks of various kinds are extremely prevalent and can have a huge impact on people. So if 50% or more of critical software vulnerabilities are due to the choice of language, then that is a very good reason to pick a safer language.

Rust is not the only choice for memory-safe languages. If you like the simplicity of C, you should definitely learn Go (it's explicitly designed to be as simple as possible to learn). But I would also strongly recommend looking into Zig, which hews much closer to C than Rust does; in fact, it has probably the best interoperability with C of any modern language.

It's still pretty bad that the normal equality operator is as bad as it is.

This is probably the most well-researched piece of writing on the matter: https://www.hillelwayne.com/post/are-we-really-engineers/