Hacker News new | past | comments | ask | show | jobs | submit login
Programming with Punched Cards (2005) [pdf] (columbia.edu)
53 points by e12e on July 24, 2014 | hide | past | web | favorite | 20 comments

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.

You could secure a card deck with a rubber band. And if you had a card sorter and your cards has line numbers, you could recover it.

So they tell me - I missed punch cards by months. We had them around the lab as a reminder and as note paper.

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

Programming in the punch card-era sounded better. When it was time to compile your program, you got to take a walk, and you met girls.

mm but the waiting in line wasn't fun - back in the 80's we had a dial up link to a mainframe to run CFD models,

I recall one day in our terminal room one of the engineers came in logged on - then commented with a sigh 48 jobs in the queue ahead of hers.

You were using punch cards in the 80s? I thought they'd given way to magnetic storage by then.

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.

>> (although probably not C)

C has good survival characteristics. The other language that I expect to last 1000 years is Javascript.

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.

If you want to scare yourself, try using the words 'JavaScript' and 'Singularity' in the same sentence.

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.

Archaic languages could be a source of jobs for really old programmers.

> although probably not C

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.

My recollection of the punched card days is the tyranny of the Data Processing Manager - the keeper of the gateway to the computer.

We can thank Bill Bridge for killing the punched card. George Snively

Applications are open for YC Winter 2020

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact