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.