On 12/30/2005 at 10:26 AM Scott Stevens wrote:
Any _writer_ who can type at 110 wpm is either
extremely wealthy
because of all the money he can bring in from his prodigious
output, or writing an awful lot of bad prose. ...
This really brings the topic around to an aspect of "vintage" computing
that I suspect most folks don't remember much (or want to forget).
Programming before the days of widely-available online terminals looked
like this:
1. Think about what you want to do.
2. Chart it out (flowchart if you were a stickler, but otherwise draw some
boxes on a sheet of paper to remind you.
3. Code up your task using a no. 2 pencil on a pile of coding forms.
4. Send the coding form to keypunch (or keypunch it yourself if that was
allowed).
5. When the card deck comes back (usually within a day or two), get an
80-80 listing if one was not provided. Swear under your breath at the
%##$% keypunch operator who decided that a zero should sometimes be an
"oh", regardless of the way you wrote it. Mark and make your corrections
on one of the "10 minute limit" keypunches. Get a new 80-80 of the
corrected deck.
6. Batch the deck up with the necessary JCL and submit it with any other
tapes, etc. at the I/O desk.
7. Barring problems, a few hours later, your deck, etc. will be delivered
back to your desk with the abend dump that invariably seemed to result.
8. Scratch your head and try to figure out what went wrong--and restart
the process all over again.
Those steps 6, 7 and 8 are why I got into OS--you can't debug an operating
system on a timeshare basis. So you sign up for block time in the dead of
night, which pretty much absolved you from attending anything but
department meetings. You could go weeks without seeing your boss.
I remember when the first online terminals made their appearance--the
managers were shocked that you could just type in source code and run it.
The reaction was that quality would suffer horribly.
After all these years, I'm not sure. The old way, because of the huge cost
in time of mistakes, did tend to make one's approach far more deliberate.
There were lots of hours of "stare at the listing and think about what's
going to happen"--and I think that the deep understanding of what one's
code actually is doing (with all of the side effects) is the big
time-eater.
The same scenario applies to writing. One can bang out a
stream-of-consciousness prose and then go back many times to clean it up,
or one can form a prize paragraph of almost crystalline beauty in one's
mind and transcribe it fully-formed.
I'm not convinced that either way is more productive than the other--or is
any faster.
Cheers,
Chuck