Jonathan Blow

(For the record, I don’t place myself in the top tier re understanding of speed or anything else. I am somewhere in the middle of that gradient between the 99.9% and the People Who Really Know.)

We see all this bad rhetoric claiming “system X is only 2x slower than native code therefore it’s fast”... but one must ignore rationalizations and look at the actual output, which is several orders of magnitude inefficient. Few people are willing to put 2 and 2 together here.

The most common objection to these points is "we write slow software because it lets us make things faster and more easily". I agree this is the common belief, but it's wrong. If development is so much easier, why is productivity approaching 0 over time?

Replies seem to be rat-holing on the old well-understood concept that software is slow. Yeah, we know, I have said that many times (and said to ignore that this time). What I am highlighting here is a deeper issue: programmers don't really know what computers are any more.

Speed is one dimension of understanding that's lacking; the picture of speed in programmers' heads is 2-4 orders of magnitude too slow. It's easy to see and understand this, which is why I brought it up. But it's not the only dimension of missing understanding.

To make the speed point again, for an attempt at clarity: Programmers have a picture of their computer, in their minds, that they use to figure out what to do. For 99.9%+, that picture is inaccurate: the imagined computer is 100x-1000x slower than the real computer.

This will result in software that's too slow, obviously. But it also affects what one thinks is possible, what one dares to imagine to do. That is the more important part. Humans are very example-based, and if our examples are wrong, where they lead us will be wrong too.

By the same logic rockets wouldn’t work because people can’t walk fast enough on their hands. Sounds like TED talk fluffery