Confessions of a Software Geek

Ramblings and rumblings about my many worlds of geekdom.

Friday, September 30, 2005

Punch Card Hell

I attended college (engineering school) during the early 80's and got to experience first hand the transformation of computing from mainframes to early personal computers. I took my first programming class during my Freshman year. It was Fortran. At this time (1981-82) you had to type in your program onto punch cards.

For those who aren't familiar with these "wonderful" items, punch cards were manila stock cards about 4 inches tall and 8 inches wide. Each card had a series of columns of numbers on them, I don't recall how many. These numbers were used to encode a single letter, number, or other symbol from a keyboard. The encoding for a single character was "punched" into the column of numbers by the keyboard on the card punch device. So to enter a line of your program, you placed a blank card onto the card punch device and typed in the line of characters. When complete, you removed the punched card, and placed a new blank one on the card punch and entered the next line from your program.

So if your program had say 100 lines of Fortran statements, you ended up with a deck of 100 punched cards. To execute or run your program, you handed in your deck of cards to the computer system operator and he would load it up onto the machine when it was your turn to run your program. Once the machine processed your program (i.e. read each card, compiled the program, executed the program, and returned results), you got back your program deck and a printout of the program's results. If everything ran perfectly (assuming no typos in your program), you would get your expected results on the printout based on whatever you had asked the computer to do/calculate/etc. But it hardly ever went perfectly. You would often get compilation errors (typos again), or logic errors, or who knows.

To edit your program, you removed the "bad" line of code by removing that particular punch card and retyped a corrected one on the card punch device, re-insert the new card in place of the "bad" one, and submitted your program to run again. This process often took a long time for each edit / execute cycle. You could easily spend hours debugging a single program and still have to come back to repeat the exercise over several days. God help you if you dropped your deck of cards and had to re-assemble the program back into the correct order. At various times the computer room floor would be so littered with "bad" cards that you could not see the color of the carpet. At the end of the semester, students often created "snow storms" by throwing their card decks into the air as they exited the computer facility and headed back to their dorm rooms.

Luckily the Fortran classes were the last time I had to use punch cards for anything. Later on I took an Assembly Language class that used terminals connected to a Dec-20 mainframe computer. You still had to collect your printouts from a system operator, but at least you could edit and debug your program on the terminal itself. At other times, I got to use an Apple II for some database programming, a Digital PDT-11 for documents and other tasks, and the school's Wang Word processing system. During my grad school years, I was happy to see that all the old clunky systems had been replaced by various Unix workstations. Now I realize that I had participated in a part of computing history that most recent engineering students have little to no knowledge of.