Real Old School Programming (was: Re: Where to buy a Selectric?)

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