On Thursday 24 March 2005 01:33 am, Stewart Stremler wrote: > begin quoting boblq as of Thu, Mar 24, 2005 at 01:06:43AM -0800: > > On Thursday 24 March 2005 12:27 am, Stewart Stremler wrote: > > > begin quoting boblq as of Thu, Mar 24, 2005 at 12:06:14AM -0800: > > > > On Thursday 24 March 2005 12:01 am, Stewart Stremler wrote: > > > > > Shims, or thinking ahead in the design? > > > > > > > > Surely you joke. Or are you omniscent? > > > > > > Not at all. Omniscence isn't required. > > > > Bullshit. > > Right back at you.
Duh. > > If you don't know what will come you cannot > > forward design. And I assert you don't know > > what will come. > > I assert that it often doesn't matter. It's easier to tackle a problem > if you keep an eye out for it than if you let yourself get blindsided. And one often has ones eye out for the wrong problem hence is blindsided by a different problem, which is my point. The only problems you can predict are the trivial ones. I believe in being able toreact quickly rather than predict. > I personally don't like crisis-mode. Who does? That does not mean you know how to avoid it. So it is important to code so that you can react quickly in a crisis. Get it? > > Mostly the generalizations are powerful, but > > wrong. The next generation is stuck fixing the > > "brilliance" of their forebearers. > > There's a difference between thinking ahead and trying to be clever. That is not what I said. I did not say clever. I say you are incapable of thinking ahead. You (here you in general, not just SS) are simply not able to see very far ahead. It is the human condition. Sorry. It applies to software as well as all kinds of other situations. > Debugging is twice as hard as writing the code in the first place. > Therefore, if you write the code as cleverly as possible, you are, > by definition, not smart enough to debug it. -- Brian W. Kernighan > > Simplicity is thinking ahead. "I will have to maintain this code > someday." Using configuration files is thinking ahead. "The user might > want to change some of these values." Using constants is thinking ahead. > "You never know when the value of PI might change." Separating the UI > from the logic is thinking ahead. "I might want want an X version of > this program." Chuckle, and as often as not you pick the wrong thing to make a constant, configure the wrong variables, separate the UI from the logic in a way that hindsight proves to be inseparably coupled. Your X is more often wrong than right and hence wastes time and energy propagating a false generalization, which must them later be reeled back in and run off in another direction. In short you do not really know what you are doing when you try to predict the future of code. But arrogance, which especially the brightest among us succumb to, makes us want to think differently. > Not all generalizations are good, I agree. XML appears to be a > generalization for generalization's sake, for example. Many "frameworks" do > nothing but obscure the goal. Too much abstraction is a problem in and of > itself, equal to the problems of no abstractions. Right. You are beginning to get it. > > Duh, > > > boblq "not as smart as stewart" > > But twice as opinated, and only half the calories! What does that statement mean? boblq "no longer impressed by sound bytes" -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
