Thinking about memory usage and optimization is the role of the compiler. The fact that some software necessitates the programmer thinking about it is just a consequence of current technology.

I don’t think that’s true.

There are some cases where novel memory layouts are necessary. Especially in graphics programming where you need to, at times, cleverly lay out memory to use the most of every available buffer to create arbitrary visual effects.

Compilers can’t automatically create novel layouts.

That's 0.00001% of the effort of programming.

You also need custom hardware sometimes, like TPUs. That doesn't make software unimportant.

We've been waiting for a "sufficiently advanced compiler" for a very long time. If you're going to write programs for real computers, using real compilers, sometimes you have to care about such things. (If you're going to write programs for hypothetical computers, using hypothetical compilers, such constraints don't apply to you. Have fun running them, though...)

That is absolutely and totally true, but 99.9999% of engineers are probably working on things like web apps or other high-level code.

The argument for FP was never that it was perfectly well-suited to every application-- merely that it was better-suited for your "typical" engineering tasks of writing business logic. FP, proof languages, and logic programming, are also all uniquely well-suited in situations that require correctness and formal verification (safety, aerospace, testing, etc).

To make a very broad, sweeping statement: if your project has a `node_modules` or a `venv`, then FP is the medicine you didn't know you needed. If you're writing low-level metal code / assembly, then you should already know you're not the target audience.

The software world is larger and more diverse than you think.

Maybe on HN 99% of people work on web.

In reality probably like 70%

Even if that's true, does it change anything about the point I made?

No, but I’m also not sure what your point has to do with what I was saying