Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!ll-xn!mit-eddie!uw-beaver!uw-june!pattis
From: pattis@june.cs.washington.edu (Richard Pattis)
Newsgroups: comp.edu
Subject: Re: a point to ponder
Summary: There is such a thing as a "too fast" compiler.
Message-ID: <5241@june.cs.washington.edu>
Date: 8 Jul 88 00:55:51 GMT
References: <82400008@p.cs.uiuc.edu> <2103@boulder.Colorado.EDU> <781@cunixc.columbia.edu>
Organization: U of Washington, Computer Science, Seattle
Lines: 24

When I'm trying to understand some programming feature, the faster I can
compile, and test my hypotheses, the better.

But I believe that when a student (meaning me too) is trying to write a well
designed piece of software, sometimes a "too fast" compiler can be an
impediment.  I've seen too many students with 90% correct programs turn them
into 50% correct programs by fiddling around with them; it is so easy to make
a quick change, recompile the program, and see if it works.  It's much easier
than thinking about what is really wrong with the program and determining if
the proposed fix works.  Each little, not-well-thought-out change takes the
program farther away from the correct one.

The fast turnaround time, unless we are well disciplined, induces us to act
first (since it's so cheap) and think later.  There was a study done a long
time ago (FJCC 1972?) that showed that students with a much faster turnaround
(on a time shared system) took more time to solve a particular problem than
their classmates using a slower batch system!  The technical solution (quick
turnaround) can exacerbate the psychological problem (laziness).  Harlan
Mills, I believe, has taught classes where extensive desk checking reduced
the net time spent on a project.

Yes, the machine can and should catch our syntax errors; but it is very easy
to take the next logical step and rely on it (via fast recompilation) to fix
our semantic errors too.  The end result is that programs take longer to
produce, and often they are not as well written.