Jonathan Blow

Only a tiny minority of professional programmers have a clear picture in their minds of how fast modern computers are. 99.9% have next to no idea. How does this affect software that is even conceived? (Ignoring, for a moment, what is actually built, which we know is very slow).

How big of a problem is it that we have this crucial craft, on which we are knowingly staking the future, and almost none of its practitioners understand the fundamental tool they are using?

(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.