But we're not making "bad code" run faster. We're making code run faster. The original counterpoint was that we shouldn't be, because improving the performanc

But we're not making "bad code" run faster. We're making code run faster. The original counterpoint was that we shouldn't be, because improving the performance just gives leeway for bad programmers to use it as a crutch. We don't prioritize bad code for optimization. See usage of 'with' in Javascript. We don't actively try to make it worse, but whenever a decision is presented which regresses 'with' performance for gains somewhere else, it'll probably be taken because we don't care about 'with' running fast. But the example I mentioned: histograms of max GC pause times on a particular website. Or particularly bad janks, or long amounts of time spent in JS which might be the result of poor JS execution.. None of these optimize "bad code". They're just standard platform performance optimizations that help all programs. That will include "bad" programs as well.