On Tue, 12 Jul 2005 11:38:51 +0300, Edvard Majakari wrote:
> 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
Optimizing sometimes means refactoring your code. Sometimes it even means
throwing it away and starting again.
However, your point to bring us back to a discussion held on this
newsgroup not long ago, about whether or not it was good for computer
science students to learn how to program in low-level languages like C so
as to avoid silly mistakes like this:
result = ""
for s in really_big_list_of_strings:
result = result + s
return result
instead of just "".join(really_big_list_of_strings).
The first method is slow, but you might not know that unless you have some
understanding of the implementation details of string concatenation.
My opinion is, no, you don't need to be a C programmer, or an assembly
programmer, or a hardware level physicist who understands NAND gates, but
it is very useful to have some understanding of what is going on at the
low-level implementation.
The way I see it, programmers need to be somewhat aware of the eventual
optimization stage in their program, so as to avoid poor design choices
from the start. But you can't always recognise poor design up front, so
even more important is careful encapsulation and design, so you
can make significant implementation changes without needing to throw away
your work. (Well, that's the theory.)
--
Steven.
--
http://mail.python.org/mailman/listinfo/python-list
