Punch Card Programming - Computerphile

"There is no quicker way to discover what n! means" Brilliant!

Imagine a Windows update shipped as punch cards...

i cracked up so much at his n-factorial joke. that was brilliant

As a technologist apprentice we had opportunities to use these systems in the late 70's. However in the big company at the time all punch cards were made by a secretarial pool that was 100% female staffed. One of my colleagues who was a straight A type student, brilliant at everything, from a wealthy family, good looking and bizarrely also a nice chap who also was No 1 in all tasks kept failing at computing. He discovered why eventually. The girls in the card typing pool were 'adding' in messages on the job cards for him, asking him out on dates, and these didn't compile. Devil's own job to locate these little 'notes' in a stack of punch cards a foot high.

80 characters per card. So is this why still, in year 2013, for example Windows command prompt width is 80 characters by default?

Professor B. neglected to mention the fact that back in the day, every program was written out longhand --- either on a form, or on a pad/in a notebook. We would "desk-check" what we wrote, and then we would sit down at the keypunch machine to enter our work line-by-line. It took a long time. There was a period in the 1960s when we had mark-sense cards for programming in Fortran, and I suppose other languages. You would use your special IBM Electrographic pencil (in retrospect, I'm surprised IBM product people didn't come up with one of their ridiculous names, such as the 9850 graphite depositing device!), and you'd have a specialized reader/punch produce your source deck. Writing code was a lot of work. You had to write your code, go somewhere to punch it (don't forget you had to punch your data too !!!) , bundle it up, take it to a job entry station or put it in a box for someone to run it for you (assuming compile, link and go), then return later to retrieve your printed output from "your" box. Depending on where you were, you might have to wait as long as 24 hours for your output...and the output might simply consist of compiler messages telling you that you'd missed a comma, or that it tried to compile 5 lines of comments because you'd forgotten to put a C in column 1 (Fortran). Your commands to the compiler might have been wrong....or your code didn't work the way you thought it should... or maybe it worked....and you'd end up with a stack of fan-folded greenbar paper to pore over. Debugging code was an art and a science. We'd spend hours and hours going over our code, using nothing more than paper, pencil and mind to trace the execution of our work. We took a lot of pride in our ability to write clean code and to debug quickly. Each of us would have our own stash of handy routines and test programs to assist in the debugging and testing processes. After we started using teletype text editors (some of the early ones were so bad, arcane and user-hostile, you'd wish for cards!), things became a little simpler. There were no "studios", or syntax checkers, etc. , but at least you could write your code, save it, compile it, and review the output without resorting to cards. Such memories! It's much easier now.

I learned to program on an IBM 1401 computer in 1971, It had 16 K of memory, and no disk drive of any kind. It could output your results onto a printer, onto a tape, or onto new cards. No consoles or terminals, just a big panel with some big buttons on it. Over the summer, the school system (yes, one computer for the entire school system of over 100,000 students) replaced the IBM with a Honeywell computer with 64 K of memory. We could not imagine what we would do with so much memory. Still no hard disks.

I had the good fortune to be taught by Professor Brailsford in the late 1970s, and it is great to see his enthusiasm, knowledge and anecdotes still able to educate and motivate as it did me in his lectures all those years ago. Great to see the stack of punched cards - I still have my set from my first year Computing project - a Chess program written in Algol 68!

In the mid 1960's I punched FORTRAN cards for input to an IBM 360. Sometimes my stack of cards was several inches high. I'd draw on the top of the stack so I could watch them move down as the high speed card reader inhaled a three foot long rack of cards. What a THRILL when my job caused the reader to pause for a second before the line printer started. It meant my job had actually run!

if XP were on punch card(~40,000,000 lines), supposing a .007 inch card thickness and being able to fit all of a line on a single card, the resulting stack would be 4.42 miles tall and weigh 145.5 tons!

I'm feeling a little old...I started as a IBM 370 mainframe operator in 1981. Computer cards and Hollerith code everywhere. Then we got a data entry system and the cards were gone (as far as programming and most data storage). Doing hex math in my head, pouring over dumps, then looking through card trays of data to find the bad punch that caused a data exception (usually from assuming character data was in packed format for calculations). Collators - patch panels, wow!

Remember this video next time you are about to curse your crashing program..imagine the pain of debugging with set of cards!

I first learned to code around the 2008-2009 time frame (when I was 24 (!)), and I love learning about all this really old stuff. I never took computer science in school, my only experience was a class I took on a whim that taught VB6, and I really missed out. Recently, I bought an old computer architecture textbook for a few dollars that takes you from all the way from how transistors work through the C language, and it's amazing.

11:12 - that trick of drawing a big V, or writing a word across the edges of the cards is also used all the time by woodworkers when they figure out in which order they want to join a stack of boards, but want to work on each individually for a bit, say to plane or sand each before final assembly.

I remember having to read some cards due to an issue that occurred when I was in the military. Our unit was in support of 3D Infantry Division and their supporting units for JUMPS. This was the current pay system (1971). I showed one of the soldiers that worked with me how to use the three zones (0, 11, 12) to translate the punches. To verify what I was reading I had him to run the card through an interpolator which printed the characters on top of a duplicate card. I read the card that had no printing on top. The soldier verified what I wrote out to be exactly what was on the original card. I don't think I could do that today. I also had the opportunity to prepare cards for transmission on the IBM 026 AND 029. We called that "cutting" cards. Normally we would receive a box or decks of cards that had to have a start "Header" and end "EOF" card made. The start card had the routing, serial number, classification, card count. The end card had the same thing to verify the card count. The card count always included the body or deck number and the two additional routing cards. The end or EOF closed the transmission of the deck with four Ns (NNNN). If the Header and EOF card did not match in the card count when the transmission ended, I would have to answer a service message that was generated from the system and recheck the deck by running it through an off-line card counter. I can't remember loosening any cards or sending any decks to the wrong station during my tour. I can say that I really loved doing that job. Thanks for a trip down memory lane with this video.

Isn't it amazing that nowadays a supercomputer to them can fit inside our pocket! And we just use it to watch cat videos and get into random arguments.

There are some pictures of the kinds of machines Professor Brailsford is talking about in the original Mainframes film - see the description for a link >Sean

We worked on a massive Finite Element Analysis program in the late 70s. The master copy was stored in cabinets of trays of punched cards that covered one wall of an office. The usual practice was to use a ruler and magic marker to draw a diagonal line across the edge of each deck. That way, if you dropped a tray, you had at least a fighting chance of getting them back in rough order before having to go through each card to get them into the proper order.

I used the beveled edge to mark cards that needed attention. I would sit at my desk and proof read a program deck. When I found an error I would turn that card around so that it's square edge would stick out of the deck's beveled edge. Therefore keeping my place and additionally marking the deck as not ready for production.

Everything I just heard I knew already. From my first computer-operator job. And I am relieved to learn that I did not exaggerate one bit all these years.