So How About Those Computers?

You can be sure that I believe we collectively lost a lot in terms of skills when we went from slide rules to pocket calculators. Years later, I was amazed at how students would punch in numbers to their pocket calculators, come up with a patently ridiculous answer, and defend the answer based on the idea that "That's what the calculator says." The notion of an input mistake was somehow not part of their equation, nor was the idea of trying in some way to judge whether the answer made sense or not. How sad.

But, you say, no matter. Computers fixed all that.

Well, the hell they did. But let's not get off on that rant. What is more interesting to talk about is how the last generation of slide rulers became the first generation of computer jocks. For during that 10 years before the pocket calculator replaced the slide rule, computers arrived on campus, and those of us who could see the future knew there was a computer in it.

So we learned FORTRAN on an IBM 1620-class machine. I won't bore you with war stories. But we learned a lot about how to translate computations done by hand into computations done on a machine. And because the process was onerous, to say the least, we reserved writing programs for something that really merited it, like a computation you had to do over and over again.

Even for those of us who took to programming like a fish to water, using the computer was a big pain in the butt. We discovered that these machines were notoriously picky about misplaced punctuation marks and inadvertent intrusions into column six. (Anything punched into column six on a FORTRAN statement card meant, "Tack this statement onto the previous one." It was the "continuation" field. Naturally, if you did this by accident, the FORTRAN compiler would burp unpleasantly.) It seemed to us that most of the time our programs were rejected for the most silly of reasons.

The reality was that we were being inconvenienced by batch processing. A single error could halt the entire process, and we had to fix these serially, one at a time. If you didn't get multiple "passes" at the machine per day, debugging took a long, long time. So we learned to be precise because, like it or not, the machine was unforgiving. We also learned to put in lots of diagnostic print statements, so that, when things "went off into the weeds," we could detect when, where, and, hopefully, why. Above all, we became the original "defensive programmers." Once interactive terminals came, followed by personal computers, this style diminished in usenot in importance, mind you, but in use.

We also made a discovery that would be remade over and over again for the next 40 yearsmost college-level problems are "toy" problems, so your computer programs don't have to be very long or very good. But, ironically, we didn't write much code to handle errors on data input. After all, the computer was a tool to be used by professionals, meaning engineers. The idea that "civilians" would use a computer and need error-checking on input was as improbable to us as a man walking on the moon.

Were we better computer users for having been slide rule jockeys? You bet we were. We were trained to suspect the result of every calculation, whether performed by man or beast (the computer was considered a beast). So there was no hypnotic trance induced by seeing results neatly printed out in rows on forms paper that had tractor hole punches on both sides. No GIGO^[9] for us. We knew that the answer was probably wrong. Only after a lot of scrutiny were we willing to accept that the computer hadn't screwed it up this time. Like their pocket calculator brethren, we marveled at how many people would blindly accept a result just because "a computer" had printed it out. We knew that a person had written a program to obtain that result, and we all knew how easy it was to make a mistake when writing a program. We had written enough of them ourselves to be painfully aware.

^[9] GIGO is an acronym standing for "Garbage In, Garbage Out."