cdash@boulder.Colorado.EDU (Charles Shub) (07/07/88)
In article <82400008@p.cs.uiuc.edu>, gillies@p.cs.uiuc.edu writes: > Think back a mere 15 years -- > how was computer science taught at the major schools? People > submitted card decks to computer operators and picked up their > printouts [ much much ] later. And because of the turnaround, we wrote programs differently than we do now. We would find the errors instead of letting the compiler do it. Is the change in how we write and debug code for the better or the worse ? Why ? -- cdash aka cdash@boulder.Colorado.EDU -or- ..!{ncar|nbires}!boulder!cdash
fuat@cunixc.columbia.edu (Fuat C. Baran) (07/08/88)
In article <2103@boulder.Colorado.EDU> cdash@boulder.Colorado.EDU (Charles Shub) writes: >And because of the turnaround, we wrote programs differently than we do now. >We would find the errors instead of letting the compiler do it. Is the change >in how we write and debug code for the better or the worse ? Why ? For the better! We're not here to serve the computer (i.e. submit perfect morsels of code), but the other way around. The computer should serve us to the best of its ability. This involves letting the compiler find the errors and allowing us to fix them interactively. Why waste human time coding, pretending to be a compiler, having cards punched, verified, submitted, etc. when computer time is cheaper? --Fuat -- ARPANET: fuat@columbia.edu U.S. MAIL: Columbia University BITNET: fuat@cunixc.cc.columbia.edu Center for Computing Activities USENET: ...!rutgers!columbia!cunixc!fuat 712 Watson Labs, 612 W115th St. PHONE: (212) 280-5128 New York, NY 10025
mbk@hpsemc.HP.COM (Miles Kehoe) (07/08/88)
Neat topic by - hm, Jack Purdam I think, in one of his 'C' books from Que - about his CS classes now. He says he gives a class assignment, and 95% of the students head for the crt to get started. He says those students spend 5 minutes programming, and the rest of the hour 'debugging'. As I recall, he implies the better programmers are the ones who stay at their desk, analyse the problem for 10 minutes or so, go to the crt for another 10 minutes, and then go home having completed the assignmemt. An interesting point. Of course, it could be we old keypunch whizes are starting to feel envy at 'the new generation' and are trying to justify the way we did things! (-:+) mbk
pattis@june.cs.washington.edu (Richard Pattis) (07/08/88)
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.
g-rh@cca.CCA.COM (Richard Harter) (07/09/88)
In article <781@cunixc.columbia.edu> fuat@cunixc.cc.columbia.edu (Fuat C. Baran) writes: >In article <2103@boulder.Colorado.EDU> cdash@boulder.Colorado.EDU (Charles Shub) writes: >>And because of the turnaround, we wrote programs differently than we do now. >>We would find the errors instead of letting the compiler do it. Is the change >>in how we write and debug code for the better or the worse ? Why ? >For the better! We're not here to serve the computer (i.e. submit >perfect morsels of code), but the other way around. The computer >should serve us to the best of its ability. This involves letting the >compiler find the errors and allowing us to fix them interactively. >Why waste human time coding, pretending to be a compiler, having cards >punched, verified, submitted, etc. when computer time is cheaper? This is very much a two sided coin -- in the old system the human being had to be a diligent proof reader. Nowadays we let the computer do the dog work of proofreading. The trouble is that people let the machine take over the whole job, and the machine can't do it. Thus you get books written on word processors in which every word is spelled correctly -- with the wrong words being used. You get the same effect in software; people write slop and jiggle it interactively until it works. -- In the fields of Hell where the grass grows high Are the graves of dreams allowed to die. Richard Harter, SMDS Inc.
ns@maccs.McMaster.CA (Nicholas Solntseff) (07/09/88)
>In article <2103@boulder.Colorado.EDU> cdash@boulder.Colorado.EDU (Charles Shub) writes: >>In article <82400008@p.cs.uiuc.edu>, gillies@p.cs.uiuc.edu writes: >>> Think back a mere 15 years -- >>> how was computer science taught at the major schools? People >>> submitted card decks to computer operators and picked up their >>> printouts [ much much ] later. >> >>And because of the turnaround, we wrote programs differently than we do now. >>We would find the errors instead of letting the compiler do it. Is the change >>in how we write and debug code for the better or the worse ? Why ? >>-- Some seventeen years ago, when I was visiting a University in another country I observed students punching several alternative versions of their programs in order to beat a three- or four-hour turnaround with the batch system then in use. There must have been other places where the compiler took the place of human thinking! Plus ca change ...