kurt@fluke.UUCP (Kurt Guntheroth) (06/04/84)
.
I have always harbored the secret feeling that learning computing in an
online environment is dangerous. I cite the following 'evidence'.
1. If you have to prepare your program off-line (worse yet on punch cards),
you tend to think out the whole program in advance, because going back
and forth from the punch (or whatever input device) to the computer is
tedious, input devices are typically scarce, the wait for output is also
tedious.
By contrast, an on-line environment encourages incremental development
a.k.a. programming at the keyboard. This is obviously more comfortable
and friendly, but leads to laziness. You let the computer find all your
bugs by compiling/running the program a large number of tines. Not only
does this waste machine cycles (too bad) but it leads to reliance on
debugging to verify the correct operation of the program. This is quite
dangerous. It would be better to rely on designing correctness in.
2. The hassle of punching programs off-line causes you to look carefully at
your program after each run, to correct all possible bugs. This kind of
introspection also improves the quality of code and reduces the number
of runs.
3. You need to know a lot less of the operating system in systems that make
you program off-line. Typically a few fixed lines of JCL will get you
through your whole learning experience. You concentrate on programming,
not on learning stupid details of the OS.
I learned to program using punched cards. By the time I was a teaching
assistant, we had on-line systems. Now I am in industry and of course we
are on line. I would never trade my nice VT100 and unix for an 029 and
NOS/BE, but I am not a bit sorry I learned on an off-line system. I hope
educators will consider off-line systems for teaching.
--
Kurt Guntheroth
John Fluke Mfg. Co., Inc.
{uw-beaver,decvax!microsof,ucbvax!lbl-csam,allegra,ssc-vax}!fluke!kurtnessus@mit-eddie.UUCP (Doug Alan) (06/06/84)
> From: kurt@fluke.UUCP > 1. If you have to prepare your program off-line (worse yet on > punch cards), you tend to think out the whole program in > advance, because going back and forth from the punch (or > whatever input device) to the computer is tedious, input devices > are typically scarce, the wait for output is also tedious. That's right! And to make sure the students really get it right the first time, we should make them toggle it in in binary on the front console, and if they get it wrong the first time, they fail not only that course, but all their courses. If they get it wrong the second time, then they get a 30 million volt shock that makes sure they will never have the ability to deface a computer's memory so again. No thanks! I was able to learn how to think about my whole program in advance without cruel and unusual punishment and having my time wasted. The trick is to give problems difficult enough so that the students won't be able to succeed without thinking in advance how to structure their programs. -- -Doug Alan mit-eddie!nessus Nessus@MIT-MC "What does 'I' mean"?
steffen@ihu1h.UUCP (Joe Steffen) (06/06/84)
If you are homesick for the bad old days, why stop with keypunching? Why not go back to entering programs via front panel switches? This "Lets make it real hard to program so we do it right the first time." attitude really irritates me. I get a mental image of programmers sitting at terminals in a Roman galley with slavedrivers whipping those programmers that make a mistake, ala the movie Ben Hur. Where does this mistaken idea come from? I have programmed via switches, plug board, keypunch, paper terminal, screen terminal, and bit-mapped terminal. My programs have been of the same quality regardless of input device, but the time it takes to write and debug a program is much smaller with the advanced input devices. -- Joe Steffen, AT&T Bell Labs, Naperville, IL, (312) 979-5381
ken@ihuxq.UUCP (ken perlow) (06/08/84)
--
My first data structures course combined the worst of both
worlds--the U of Wisconsin had 5 Terak micros running UCSD
system for 40 of us + about 60 intro to programming students.
You got to play around on-line, but you had to reserve 2 hr
slots, often at 3 AM, always several days in advance. So
we came in there with a LOT of code written out, with
debugging hypotheses completely detailed, as there was no
time to stop and think--and who could think straight at 3 AM
anyway? (Remember, this was an intro course, long before any
of us got used to hackers' hours.) So we could experiment
on-line, but prepared for same off-line.
Well, 7 non-trivial assignments in a 7-week summer session
was a hell of a load. We were often working on two assignments
at the same time, finishing up the one--invariably late (and
late points were, of course, assessed) while starting the next.
But it broke me of most of my worst habits--poor modularity, too
few comments, variables called "x", a good night's sleep.
Thanks, Bill Cox, wherever you are, I needed that.
--
*** ***
JE MAINTIENDRAI ***** *****
****** ****** 08 Jun 84 [20 Prairial An CXCII]
ken perlow ***** *****
(312)979-7261 ** ** ** **
..ihnp4!ihuxq!ken *** ***