[CLUE-Tech] Optimizing Code [was KISS Session]

[Jed S. Baer]

On Tue, 13 Nov 2001 09:42:12 -0700
Grant Johnson <grant at amadensor.com> wrote:

> >The bottom line is that hardware is fast and cheap, so optimizing isn't
> as
> >important as it used to be.
> >
> It's that attitude that makes my job hard.  Optimizing is ALWAYS 
> important.  
> 1)  Optimizing, even on fast hardware means you can do more things at 
> once for more people at once.
> 2)  Optimizing for speed usually means finding a simpler way of doing 
> things, which in the long run is more maintainable.
> 3)  Those who take the time to optimize are usually those who care about
> their code and how it works, and usually the ones who actually take to 
> do other little things like debugging.
> 
> This attitude is why we have what we do today, where my 300 Mhz AMD 
> running Excel takes longer to recalc a spreadsheet than a 1Mhz CBM 8032 
> running Busicalc, and why my 366 AMD laptop with 96 M or memory and an 
> EIDE drive running Postgres outperforms a dual 933 with a gig of memory 
> and RAID 5 Ultra 3 SCSI running SQL Server 2000.
> 
> Stay away from the dark side.  Write good code.
> 
> This is not meant to be a personal attack.  Many people have this 
> attitude, it is even the prevailing theory taught in schools now.  That 
> doesn't make it right.

Well said Grant. But the biggest issues these days are programmer time vs.
machine time, and function creep. Function creep is seen primarily in
commercial products (or I should say "for distribution" as I include Gnome
and KDE in there), whereas programmer time becomes more important in
custom code.

The reason I include Gnome is that Miguel has said that one of the goals
of the Gnome project is to provide an environment which will make an easy
transition for M$ users. That means duplicating functionality. Whether
animated slide-out menu drawers are really necessary for this, I'll leave
to others, because some clearly think they should be there. I don't use
KDE, but I imagine there are some of the same elements there. The other
issue in function creep is that many new users just don't understand the
concept of why some things are bad, and their OS lets them do them anyway.
I imagine the day when the computer will say "I see no formulas here, only
text. Are you certain you need to use a spreadsheet for this information?
It looks like an event schedule." But of course, that too, would be
function creep -- albeit of a different kind.

The programmer time vs. machine time is a much more tricky debate. Throw
in the expectations of RAD and XP, and you can wind up with an environment
where there isn't time to find the most optimal algorithm, nor time to
mentor junior developers in the ways of elegant coding. Sure, you do the
best you can to attain those goals within boundaries you have. So, I agree
100%. Too bad it isn't always possible.

Well, I'm always happy for an opporunity to throw out a good rant. Thanks
Grant!

Cheers,
jed
-- 
  If R is the set of all sets which don't contain themselves,
  does R contain itself?