The article fails to distinguish between hard real-time and soft real-time. If you're controlling a bandsaw, you've got a hard real-time application. You can't

The article fails to distinguish between hard real-time and soft real-time. If you're controlling a bandsaw, you've got a hard real-time application. You can't miss your window for the next instruction. Most user interfaces are soft real-time. Occasionally missing your window is fine. And so it is OK to do things like hash lookups whose average performance is O(1), and whose worst case performance is O(n). Ditto for dynamically resizing arrays. As long as you're back in time, most of the time, it can be OK. The problem isn't that we code UIs as soft real-time. It is that the soft bit gets squishier with each layer of abstraction. And there is a feedback loop where people get more and more used to slow applications, so nobody is concerned if their application is unnecessarily slow as well. Compounding this is the fact that we often measure performance in terms of throughput, instead of latency. Therefore, every single device and peripheral is willing to lose a bit of latency. It happens at all levels. The classic I like to quote is http://www.stuartcheshire.org/rants/latency.html http://www.stuartcheshire.org/rants/latency.html. And the result is that modern applications on modern hardware are less responsive than older applications on older hardware. Fixing it is a question of fixing a lot of little problems. And, as we used to joke about Microsoft, what's the point of developing fault-tolerant software when we've already developed fault-tolerant users?