Early speed optimizations aren’t premature

I wouldn&#x27;t say using vectorized operations as opposed to for loops is such a good example. You&#x27;re simply using the right tool for the job. Is using a fork to eat soup suboptimal? Is switching to a spoon optimizing the way you eat?<p>But what about using a dict or a list or tuple? That kind of decision can make a performance difference down the road, and there are trade offs in ease of development.<p>Anyway, the whole thing feels a little contrived. Who would ever argue that you shouldn&#x27;t use numpy from the get-go? Who is the author arguing against?

This article would be more convincing if the NumPy version were actually vectorized. Replace the for-loop with<p><pre><code> result = (arr - min_val) &#x2F; (max_val - min_val) </code></pre> That should often run faster <i>and</i> removes the allocation and for-loop, so it&#x27;s easier to read.

Like most comtrarian articles, it is only meaningful if you haven&#x27;t read the original, which it isn&#x27;t actually contradicting.<p><a href="https:&#x2F;&#x2F;softwareengineering.stackexchange.com&#x2F;questions&#x2F;80084&#x2F;is-premature-optimization-really-the-root-of-all-evil&#x2F;80092#80092" rel="nofollow">https:&#x2F;&#x2F;softwareengineering.stackexchange.com&#x2F;questions&#x2F;8008...</a>

Of course. Just engage into mature speed optimizations from the beginning, as everyone else.