The one example I like is shared memory multi-processing (what you mean when you say "multi-core", because multi-core systems are older than C), because I do se

The one example I like is shared memory multi-processing (what you mean when you say "multi-core", because multi-core systems are older than C), because I do see it as a hack done to preserve compatibility with a more traditional programming style (or dare I say, with a more traditional "programmer"). As I said, I agree with this, but the argument is still value-less. If you don't do multiprocessing this way you'll find yourself handicapped because _all_ current machines are heavily optimized for it. There's very little point to a language that doesn't do it this way, because it would not be able to run as well on current machines! The other two examples are highly questionable. 0-terminated strings are not an artifact of the computer architecture, but a conscious trade-off, and in fact other languages already used Pascal strings (even on the PDP-11). Same as if you want your lists with a constant time size function or not. Sure your size() is now "much faster", but something else now becomes slower. In fact, you could argue x86 bends to supports _both_ string implementations, since the rep prefix does support (and update) a count. And the final example, "isdigit" is arguably not even a language issue, and definitely not a legacy of the PDP-11 nor x86 architecture. I'm rather sure no one in his right mind would even consider wasting 0.25KiB just for such function, not until well into the 90s at least. These types of code-bloat optimizations are more of the 2000s and even 2010s "performance" craze. You yourself even say on the other thread that glibc is doing this to facilitate locales, and not for performance reasons.