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