optimization (was Re: C vs. FORTRAN (efficiency))

[Henry Spencer]

Flint Pellett (flint%gistdev at uxc.cso.uiuc.edu) writes:
=> I haven't studied this myself, but my theory is that if you could
=> plot a graph of productivity vs time needed to compile, that curve
=> would be bell shaped for many people: toward the bottom where
=> compiles are instantaneous, productivity would be less because the
=> programmer would be charging ahead without ever stopping to think
=> about what they are doing, and would ending up wasting time doing
=> things that some pre-planning would have eliminated.

This same "making programming easier will make programmers sloppy"
argument has been used against everything from timesharing to high
baud rates on terminals.  It's been nonsense every time, and I think
it's nonsense this time too.  Giving programmers more powerful tools
lets bad programmers make bigger messes, but it also liberates good
ones from productivity-reducing hassles.  Fast compiles, in particular,
encourage bad programmers to be sloppy, but also encourage good ones
to get things *right* rather than saying "oh plotz, it works well enough
and I can't stomach compiling it again to fix the little blemishes".
A good programmer will stop to plan when it's desirable, but *doesn't*
need to do that every time.

Flint, have you ever used a punchcard-based batch environment with a
turnaround measured in hours?  I have.  I'll take timesharing, thank you.
And I'll take the fastest compiles I can get.
-- 
V7 /bin/mail source: 554 lines.|     Henry Spencer at U of Toronto Zoology
1989 X.400 specs: 2200+ pages. | uunet!attcan!utzoo!henry henry at zoo.toronto.edu