A course with mandatory use of punchcards was the only CS course I ever did poorly in. It was IBM assembly language at a community college, and I just couldn't deal. I'd built my own computer a few years earlier, and going to punchcards -- where you couldn't even delete a mistake -- was miserable.
Later, to avoid other courses with punchcards, I used a combination of Emacs at MIT-AI over the Arpanet, a terminal emulator written in Z-80 assembly and a DEC-10 at my co-op job. It was worth driving 30 miles to pick up printouts to avoid punching cards and waiting hours for my programs to turn around.
Great read. I learnt to program at high school(mid 70s) on hand punched cards (paper-clips are amazing tools!) in Portran. Took to local bank each lunchtime to get processed. Dabbled with Algol/W learnt the same way and then at uni used punch machines to learn COBOL. One of our finals was to design, code, punch, debug a solution - we got 4 days to do it which means finding typos, logic errors, and design errors and elimintating them all with only 4 re-runs (1981)! Today i would re-compile 4x in the blink of an eye and my code is not more reliable than way back then. My first job was as a programmer at NCR and re used a line editor - such joy to be able to change and compile without getting up from my desk. Handling 200Mb disk drives the size of washing machines is another story though.
The 'art' of desk checking is invaluable to some of us while others prefer the 'suck it and see', or the 'push and pray' approaches. They all have their place, but if one is isnt a math geek then desk checks are the best way to 'prove' out the code and find bugs.
I could have written this (but 5 years earlier) you're a kiwi right? I got started p[rogramming when someone gave me 100 PORTRAN cards on a scouts trip to Databank
I went thru Uni Comp Sci mostly using cards for everything, we all shared card punches, even today an 029 punch has a 'feel' to it I haven't forgotten
Reminds me if the time I was using the Naval Electronics Labs' (San Diego) mainframe as part of an Explorer post, semi-officially during high school (1971-ish), and got ambitious, writing a compiler in the assembly macro language. Wrote it up on the punch card forms, several thousand lines of code. Submitted it to the punch card crew, and got it back several days later with a rather strong note about what project to charge it to. Turns out it was quite expensive to punch several thousand cards and they expected our group to be submitting little programs in Fortran, not monster assembly decks.
Oh well, somehow it was glossed over. They ended up hiring me that summer to do some systems programming so I guess they weren't too mad.
That's a nice article. I started programming in 1967 so reading the article and seeing pictures of all of the machines even brought back memories of the unique and slightly pleasant smell of the freshly punched cards as they came out of a 029 keypunch!
Wow! That's almost 50 years. I have a question — the story narrates how output of the computer was driven to chain printers. But VDT / CRT monitors were invented long before and were even used by pioneers like Doug Engelbert in 1960s. So why didn't monitors come into play to receive the output?
The monitors were there, you just couldn't easily make your way around the text until interactive text editing came along. It was far easier to keep an overview of the program on paper than it was on the screen.
I hacked a primitive full text editor on a Sperry Univac mainframe but it was dis-allowed on account of eating up too much machine time. After each keypress it would hit 'submit screen' rather than at the end of a round of editing in the on-screen text buffer. It worked but the resource consumption was off the scale. So this kind of editing had to wait until we all had machines powerful enough on our desks to run an editor directly.
I used punched cards and paper output (continuous fan-fold wide format) from line printers exclusively until 1972. Even after that, cards and hard copy output were still used on many systems I worked with until around 1980. A number of changes had to take place before monitors could replace punched cards and paper.
The early terminals were hardcopy. The Teletype 33 terminal [1] was popular and so were the IBM 2741 and Digital DECwriter. These worked fine and were better than punching cards, but they couldn't be used on many systems. I saw these mostly on minicomputers where there was only a handful of people (often just one) using the computer at a time.
The most dominant mainframe operating systems from around this time (IBM 360 MFT, MVS) were not capable of handling I/O interrupts efficiently enough to support a number of users working at terminals. The hardware and operating systems of these mainframes were designed around an architecture that supported batch processing: read in a program from a deck of cards, read in the data from a large stack of cards, run the program for minutes or hours, print out the results on a line printer.
A properly sized mainframe would be running jobs continuously throughout the day and most of the night, but it would be (mostly) running one job at a time. These early operating systems and the hardware I/O bus designs supported batch processing well but wouldn't have supported large numbers of concurrent programmers sitting at there own terminals connected to the system.
The rise of timesharing operating systems like Multics and Unix provided additional impetus for video display terminals (VDTs), but it wasn't until around 1976 that really affordable VDTs were even available. The ADV 3 was a nice terminal that came out in 1976, see [2]. I couldn't afford one, but I knew someone that had one and was able to work from home over a 300 bit/sec acoustic modem. It had 24 lines of 80 characters (from the 80 columns that cards had). It wasn't until 1978 that the DEC vt100 was produced.
In 1984, I was in software development at IBM and we were still using the 3270 terminal [3]. This terminal was connected to a mainframe timesharing system that still had trouble processing each keystroke as it was typed. Instead, the IBM 3270 was a block or page oriented terminal where you filled out the screen of text and then pressed the transmit key to send the whole screen full of text to the system in one transmission.
"So now I dug out my pad of coding forms and wrote one line on it, this time including the missing comma. I took it back to Maria and asked her to make me a new card."
Baby programmer. As an undergrad we were thrown into the deep-end and given those green/white programming sheets, pointed to the computer centre with its rows of 029 keypunch machines and let loose. This is what a keypunch looks like up close: https://www.flickr.com/photos/bootload/247968267/
While we had a micro-computer lab, we still had to use the Cyber mainframe to program with FORTRAN for data crunching map data. You really worked hard on your code. One mistake, one mistyped character and your printout was all debug. A year into my first startup, ten years later I missed the break-up of this machine. [0]
If I look over on my bookshelf, I still have a couple of decks. That's what I remember most. Card decks and rubber bands. Fun times.
The constraint on computer terminals was inexpensive read-0only memery to hold raster fonts. A set of 72 upper/lower case 5x7 dot letters plus digits and punctuation is 2520 bits. When half kilobyte ROM chips fell to fifty bucks in the early 1970s then it became economical.
Memories...only dealt with cards for a couple of years, often just for archival. It was always great fun putting a couple cards of your roommate's deck out of order.
And still have an EOF card as a bookmark in my old COBOL book
Out of order could be fun. But backwards or upside-down was even more fun. (Clip all the corners of the card so it won't be noticed.)
More fun could be had with card patches (used for corrections) and card saws (used for clearing the worse jams -- no, I'm not kidding.)
The best card patches were transparent or conductive tape, because they'd be read differently by optical vs. brush-contact readers, and many shops had both.
The IBM 1443 printer used a "type bar" instead of a chain...
...on occasion a column hammer would stick (they were operated by electromagnets) and some of the little sets of metal type would pop out of the bar. Note that the woman is holding two bars; one with more type on it than the other. That's because there were two bars: the "13-character" (0-9, +, - and $) and the "43-character" (26 alpha, ten digits and +-=.()$ ) bars, and the 13-character bar printed much faster because it didn't need to move as much to put every character in front of every column hammer.
When a type segment popped out, it could get lost inside the machine, and a supply of replacement type segments were at hand. One night (at a bank) the segment on a 43-char bar that had the numbers on it popped out and was lost. The operator on duty duly replaced it with a spare...which turned out to be from a 13-char bar.
It had all the numerals on it.
In different places.
So all the numbers on the bank's transaction journal and general ledger balances had almost-randomly wrong digits in them sometimes, depending on where in the stroke the bar was and which direction it was moving in for that line on the report.
some times the chain in a chain printer would break, they were reputed to be able to launch themselves thru the sheet steel of the printer's housing and embed themselves in a wall .... no one stood beside them
The first programming course I took was when I was in highschool and a friend and I took a Fortran course at the University of Rochester. They had us do our first two assignments on punched cards - then we switched to green-screen terminals. I am thankful for that exposure, and also because now I am the youngest person I've ever met that has programmed with IBM punch cards!
I was confused at some parts of the narrative because I had only a vague understanding how punched cards worked. Here's a video about their working that gives a much clearer picture —
It's amazing both how much.. and how little the art of programming has changed. The tools we use have changed dramatically over the last 50 years - the methods not as much. I don't know if thats good or bad - or just is.
Later, to avoid other courses with punchcards, I used a combination of Emacs at MIT-AI over the Arpanet, a terminal emulator written in Z-80 assembly and a DEC-10 at my co-op job. It was worth driving 30 miles to pick up printouts to avoid punching cards and waiting hours for my programs to turn around.