An absolutely wonderful write-up. My first contact with punch cards was in 2005. As a tradition, my alma mater uses two punch cards and magnetic tape to make the name tags for the new computer science students. Supplies are of course limited, so this is a dying tradition. I remember reading about how they worked and even, late on a Friday night, learning a bit of Fortran that could have been punched onto my name tag.
From the older professors I learned about the diagonal stripe trick and that the biggest fear they had on a cold winter day was to slip when carrying a box of cards down the long nasty stone stairs just outside the maths department, when taking their code to the computing centre. Something that I did not see mentioned in the submission that I learned from them was that at least some computers in the 60;s would make a different sound depending on which instruction that was being processed. Now, remember that this, just like in the article, was before the days of displays. So, a way to detect infinite loops was to listen to the machine. An infinite loop would of course be detectable by the same sound pattern repeating itself over and over. Auditory debugging indeed.
I've stumbled across this before, its a very good read. Highly recommended! There are some great videos on YouTube about the subject, left over from that era. I really like this one: https://www.youtube.com/watch?v=oaVwzYN6BP4 (produced in 1969)
Its interesting how little programming has changed since these days. The way we program has changed significantly, put what we produce is almost identical. Each punch card represents a single instruction, equivalent to a line of code in our modern text editors.
I wrote a small punch card toy in JavaScript not too long ago to get a feel for what programming with punch cards may have been like. That's here if your curious: http://tyleregeto.com/article/punch-card-emulator
Not at out end we used to get data back from some of our partners (Admiralty Research Establishment at Portland from memory) in paper tape form - I had a few paper cuts from our high-speed paper tape reader.
I "learned" to program Fortran IV on punch cards in 1973. Punch cards were not the only option for input--you could use machines that looked like teletypes to create paper tapes. However, there was the problem of typing errors: with the teletype you got underline marks to show your deletions, so changing "wile" to "while" left you with WILE___HILE on the paper, which I found hard to read. With a punch card, you could copy to another card up to the point of error, then proceed. And believe me, nobody thought of providing keypunch help for college freshmen. I didn't mind Fortran, I did OK in the class, but the experience did not encourage me to go on.
One of my leading regrets from college is that a couple of quarters later, I sat in the back row of a classroom where I could see the cursor blinking on a CRT (probably connected to a Data General Nova), and thought "Hmmm" but did not follow up, and let a dozen years go by before I took up programming again.
This makes me wonder: In 50, 100, 1000 years, what will be the state of studying computer languages from the present? Surely many of them will be gone by then (although probably not C), but some programs may still exist written in them. Or, some future archaeologist may recover a bag of servers and attempt to understand what they do.
Will courses teach old languages like they teach Latin and Greek now? Centuries from now, we may need people to decipher old computer programs just like old texts.
Or, perhaps all the documentation will be preserved and there will be little need to study the old languages beyond their primary docs.
I could see Python surviving as well (maybe not a 1000 years, but 100). With its heavy usage in scientific computing, It's rapidly becoming the next Fortran. LISP will also probably exists in some incarnation.
Industrial archaeology is already a thing. For example, efforts by NASA to recover early Mars and Venus images from tapes before the tapes crumble.
There will probably always be a small but lucrative business in binary-patching systems that have long lost all their documentation but are critical to the functioning of something.
I surely hope that in all those years developers finally learn to take security and software quality seriously, making it available in the same amount, or less, of computer systems that still run PL/* [0] nowadays.
[0] As an example for a systems programmer language family older than C.
Fantastic read. My first real glimpse of what programming was like back then :)
He speaks of the paradigm shift he underwent there, from punched cards to terminals with screens (which seems close enough to using a text editor or IDE on your workstation now :)). Do you think a similar paradigm shift may happen again? If so, what could it be?
Could programming with a keyboard ever become obsolete? What if you could just ask your computer what you want in plain English and it actually understands and "implements" it?
You mean like SQL? That is a literal / formal language, but still quite legible in English. A looser one is Siri and Google's voice recognition, same idea. The main problem though is interpretation and specificity, something which English isn't very good in (multiple interpretations possible). Which is what programmers are paid for; translating loose requirements ('I want a contact form') into code (fields, styling, validation, submission, storage, reporting, etc).
Yeah, those were the times! Columbia's computer history pages (links at the end of the document) are also very enlightening.
I don't write self-modifying code any more, but I can relate to the times when that was a sheer necessity. I find it important that documents like these help us keep those times alive so we don't forget where we came from.
From the older professors I learned about the diagonal stripe trick and that the biggest fear they had on a cold winter day was to slip when carrying a box of cards down the long nasty stone stairs just outside the maths department, when taking their code to the computing centre. Something that I did not see mentioned in the submission that I learned from them was that at least some computers in the 60;s would make a different sound depending on which instruction that was being processed. Now, remember that this, just like in the article, was before the days of displays. So, a way to detect infinite loops was to listen to the machine. An infinite loop would of course be detectable by the same sound pattern repeating itself over and over. Auditory debugging indeed.