Stewart Stremler wrote:
Performance issues based on implementations of an interface are best,
I thought, left until the profiler has been run. Trust the profiler.
(Then again, if you need guarantees, you're looking at realtime
programming, no?)
"Avoid premature pessimization."
There's no point in using an O(n^2) data structure if O(n) or O(n log n)
is available with the same interface.
I will grant you, though, that the ability to swap an implementation of
something which is not known to be stable and/or correct with another
implementation can be useful.
This normally doesn't apply to the standard library.
[snip]
"The usage of design patterns indicates a language failure."
I forget where I heard it, but I am now convinced of this. If I have to
use patterns, I am in the wrong language.
Hm.
Hmmmm.
I like design patterns in that they provide a vocabulary. I've always
been a bit leery about using 'em as recipes, or as a _guide_ to design.
(The most important feature of a design pattern, aside from the name,
is the list of tradeoffs: what you give up.)
Now the whole topic has been called into question. I'll want to mull
this one over for awhile, I think.
Yes. I like the fact that design patterns give me a common vocabulary.
When I hit a deficiency (and all languages have them), I can tell
someone, "I'm using pattern X in order to get around problem Y" and they
often get it right away.
However, I find that if I'm doing that too often, I have probably chosen
the wrong language for the problem.
-a
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
