> sometimes the fastest code deliberately introduces coupling, hardware specific cache shenanigans or unreadable hand written asm and/or inlined SIMD. >> this

> sometimes the fastest code deliberately introduces coupling, hardware specific cache shenanigans or unreadable hand written asm and/or inlined SIMD. >> this is a perfect example of how simpler code should be preferred _by default_ over complex code. Extra emphasis on *by default*. You are both on the same side of the coin. This is the essence of "premature optimization is the root of all evil". Simplicity should be the default. Once you know your implementation is solid, then you can go back and optimize. TFA is quite contrived, but imagine a much more complex process. You see some code: for i in loop: foo[i] = myfunc(foo[i], bar[i]) You have to go in and dig into why exactly foo is being fed back in at every step. But if instead you saw: for i in loop: foo[i] = myfunc(bar[i]) You immediately know you have more options at your disposal to optimize that loop. Further, the compiler immediately knows it has more options. Maybe this is a good option for automatic unrolling or Duff's device. Maybe you wanna send this to a gpu shader, or use a macro to parallelize the loop. But it's a lot harder to get to that point if your starting point is the complected, stateful one.