Thorsten Kampe <[EMAIL PROTECTED]> writes:
> Speed considerations and benchmarking should come in after you wrote
> the program. "Premature optimisation is the root of all evil" and
> "first make it work, then make it right, then make it fast" (but only
> if it's not already fast enough) - common quotes not only with Python
> developers.
Just a minor note: regarding quote
"first make it work, then make it right, then make it fast"
Shouldn't one avoid doing it the wrong way from the very beginning? If you
make it "just work" the first time, you'll probably use the old code later on
because "functionality is already there" and temptatation to build on probably
relatively bad architecture can be too strong.
How about
First make it work (but avoid ad-hoc designs), then make it right, then make
it fast
Of course, such emphasis doesn't go well with classic idioms..
(yeah, programmer's block at the moment: I should clean up a 120+ -line
if-elif-elif-elif... else -block which tests a single variable and calls
different methods with variable number of parameters depending on the value of
the variable - guess I should apply command pattern or similar...)
--
# Edvard Majakari Software Engineer
# PGP PUBLIC KEY available Soli Deo Gloria!
$_ = '456476617264204d616a616b6172692c20612043687269737469616e20'; print
join('',map{chr hex}(split/(\w{2})/)),uc substr(crypt(60281449,'es'),2,4),"\n";
--
http://mail.python.org/mailman/listinfo/python-list
