“C is not how the computer works” can lead to inefficient code

For many people, "C" means C+{gcc/clang}+{x86/arm}, which has much more specific semantics than the C99 abstract machine.

They'll ask interview questions like "what's sizeof(int)" expecting a number, and will find "it depends on the compiler/architecture" evasive, unless you follow it up with "but it's always 4". To be fair, this is how 99% of people use C in practice, and x86/arm behave pretty similarly to each other in the scheme of things (vs, say, a LISP machine).

Taking into account ABI constraints, including x-{language,module} call safety, threading expectations, and more, a typical C programmer has to have a decent idea of how the machine works, relative to a Python/JS/Ruby programmer.

I don't love that someone "learning C to learn how the machine works" will think malloc()/free() are how the machine works, and will get have wrong expectations ideas about memory when using, say, V8's bump allocated nursery + compacting GC. But it's not a bad first step for someone who doesn't know what a pointer is to the machine.

It's unproductive to talk about a "C abstract machine" then go on to say how a hardware cache invalidates a program's correctness.

You see similar issues with e.g. Haskell or a lazy FP languages where certain idioms behave wildly different from each other.

Ultimately I'm not sure what his complaint is. He says "If it takes too long, or takes no time at all, that’s not the language’s concern, strictly speaking." Would you trade correctness for speed? Would you make programs maintain poor performance in the face of hardware upgrades?

What is the point of either?

I wonder if there is a typo in the title: '"C is how the computer works" can lead to inefficient code' makes more sense to me.