

The Fallacy of Premature Optimization (sometimes it's good) - smanek
http://www.acm.org/ubiquity/views/v7i24_fallacy.html

======
ced
I conjecture that the more low-level the language, the more premature
optimization is necessary.

As an example, an assembly language programmer has to make very early
decisions about whether to use a WORD (valuing speed), or a long (valuing
extensibility) to model a quantity. If he chooses wrong, he will have to
modify hundreds of lines of code. A C programmer, instead, can use a typedef
and then switch between the two representations at any time, but he might have
to choose between long and big-integer. Lisp programmers don't have that
choice to make.

In the perfect HLL (by that metric), every parameter or constraint of the
program is specified in just one place. Premature optimization is then always
a mistake.

(Lisp still has a way to go to get there)

------
DanielBMarkham
Seemed wordy and off-base. Are there really people out there who think all
optimization is evil?

~~~
olavk
Seems like a very longwinded attack on a "optimization is evil"-strawman.
However, he has one valid point: You should consider performance issues when
you design the overall architecture of a system, even though this is
prematurely in the sense that it is too early to actually measure where the
problems might be.

