Re: Who is a Good Programmer?

From: Robert Wessel (robertwessel2_at_yahoo.com)
Date: 04/30/04 

Date: 29 Apr 2004 18:11:26 -0700

CBFalconer <cbfalconer@yahoo.com> wrote in message news:<4091300C.F773BC7B@yahoo.com>...
> Robert Wessel wrote:
> >
> ... snip ...
> >
> > The problem is that many of the goals conflict. Fast code is
> > almost always less reusable, maintainable, and clear, and is
> > usually slower to develop. Reusability tends to slow down
> > development considerably as well. Input validation conflicts
> > with fast and small, and useful error messages assumes some
> > method of handling error messages.
>
> Splutter. Hogwash. Clean, compact code is usually close to
> optimum for speed and maintainability, for some definition of
> clean.

So reading random records from a sequential file via a sequential scan
is going to be faster than a (vastly more complex) B-Tree? Quicksort
faster than insertion sort? Schoolbook multiplication faster than
Karatsuba or FFT? Package Wrapping faster than Gharam scan?

Not to mention that most of the low-level optimization techniques tend
to obfuscate the algorithms pretty badly.

> Unvalidated input is useless, and unhandled errors lead to
> stochastic processes. Look to your algorithms.

Input validation can have considerable overhead, in execution time,
code size, and source code. If you have some guarantees about the
performance of the user, omitting it may make sense. For example, if
I know my sqrt(x) function will only be called from a program that
generates only positive x's, it's not unreasonable to omit the range
checks in a critical path.

Relevant Pages

  • Re: Who is a Good Programmer?
    ... > The problem is that many of the goals conflict. ... Fast code is ... Reusability tends to slow down ... optimum for speed and maintainability, ...
    (comp.programming)
  • Re: Refactoring: Extract method revisited
    ... written code. ... I'm always interested in how many people think fast code is more ... so why not worry more about maintainability and readability? ...
    (borland.public.delphi.non-technical)