This also explains the shift in functional programming from languages with good reasoning about correctness (Haskell, but also SQL) to languages which additiona

This also explains the shift in functional programming from languages with good reasoning about correctness (Haskell, but also SQL) to languages which additionally allow of good reasoning of performance (OCaml, Rust, etc.). Moreover, this explains the NASA coding rule that all loops shall have an explicit upper bound. The deeper issue seems to be: If you write code in a fashion that you can reason easily about its performance, then you might not get the optimal performance in all cases, but you establish an minimum level of performance. So performance stability is more important than reaching optimal performance, because the latter may be easily destroyed accidentally in future versions of the software. The only exception are well-defined tasks with stable input/output definitions (e.g. numeric primitives like matrix multiplication, fourier transformation, etc.) where the whole point of newer versions is performance improvements and nothing else.