Newsgroups: comp.lang.c Path: utzoo!henry From: henry@utzoo.uucp (Henry Spencer) Subject: Re: optimization (was Re: C vs. FORTRAN (efficiency)) Message-ID: <1989Aug20.024207.29079@utzoo.uucp> Organization: U of Toronto Zoology References: <3288@ohstpy.mps.ohio-state.edu> <225800204@uxe.cso.uiuc.edu> <14523@bfmny0.UUCP> <1613@mcgill-vision.UUCP> <14556@bfmny0.UUCP> <484@gistdev.UUCP> <1989Aug18.152547.10774@algor2.uu.net> Date: Sun, 20 Aug 89 02:42:07 GMT Flint Pellett (flint%gistdev@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@zoo.toronto.edu