begin quoting Andrew Lentvorski as of Tue, May 23, 2006 at 03:06:34PM -0700: > 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."
Heh. Avoid *anything* premature, eh? > 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. Indeed. But if the interface is the same, there's no need to abandon the interface to use the concrete implementation. > 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. It's the boundary between local code and standard libraries that seem to be the best place for this sort of thing. I've not found a problem with standard libraries this way, but I've found problems in code that was (mis-)using standard libraries. [snip] > >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.) [snip] > 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. So what's your opinion of antipatterns, then? > However, I find that if I'm doing that too often, I have probably chosen > the wrong language for the problem. Well, yes. Not all languages are suitable for all applications. :) I'm firmly behind you on _that_ one. -- _ |\_ \| -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
