I didn't really grok how punch cards worked until I went to the Computer History Museum and typed one out myself. Then it suddenly clicked.
Each punch card represents a single line of plain text. That's it.
Usually this was a single line of FORTRAN or COBOL code, but it could also be data like a person's name, age, etc. No idea why I didn't get that before. I may have had the idea that developers back then were writing in binary or something. As you type out the card, the holes are punched and the character is printed along the top, so humans can read it. (Cards can hold binary data as well, but I'm talking about the cards used by programmers and for data input by secretaries - say for new account info, etc.)
How many characters can a card hold? 80, of course. Even today, many IDEs will draw a line at 80 columns. I thought it was some pedantic formatting thing. I think many still do. Nope, just a holdover of 1950s tech. A stack of cards? That's akin to a single file, with each line of text data being an individual card. Need to fix a bug? Make a new punch card for that line of code and swap it out. Code reuse is card reuse. Just take that subroutine from one stack and slip it into your program's pile before your next run.
Sure, there were typewriters and printers for interactive use, but without magnetic tape or anything like a floppy, this is how you stored your program in a machine readable way.
As the author of one of the pages you mentioned (thanks for that!), I want to point out that the one at kloth.net is much like the original one on the Web. (There may have been earlier ones, but of those that are still around…)
My dad was a math professor (he was really a computer nerd, but there was no "computer nerd" course of study back then). Down the hall from his office there was a room with a variety of toys in it, including an IBM 029 [1] which was great fun for me to play with as a kid. (It was noisy and you could make your very own cards you could keep!) Although the card punch was still operational, nobody really used it at that point since interactive terminals had taken over.
The computing center had a seemingly infinite supply of cards, and many of them made their way home. My mom to this day (over 40 years later) still uses punch cards as note paper. Good memories.
My educated grandma was a physicist in USSR who coded on punch cards who brought home her programs for note taking. I've taken so many notes on those, learning how to write around the holes. Weirdly enough I found one of her cards in some box that we brought here to USA and gave it to my wife, she has it in her art supplies. That thing is like 70 years old, and I love looking at it!
You know, punched card decks used to store data -- very small amounts of data, at least relative to tapes -- which in turn stored very small amounts of data relative to disk drives, etc., etc.
On that note, if one wanted to make an improvised data storage device, for storing very small amounts of data (for let's say, a future Zombie Apocalypse, or what-have-you!) -- then what about using a Printer/OCR combo -- to store small amounts of data (relatively speaking!) -- as graphical designs, dot graphs, similar to punch cards, in effect, on pieces of ordinary printer paper?
Oh sure, it wouldn't store Gigabytes of information, or even Megabytes or Killobytes -- but you could probably fit some early historical computer programs onto standard printer paper -- just printed as dot patterns!
Which leads to another interesting question!
Given a Printer of X DPI printing capacity, and an OCR of Y DPI scanning capacity:
a) What algorithm or algorithms should be used to put the maximum amount of information that can be reliably scanned (100% accuracy every time!) back onto the the page?
b) What encoding method should be used?
c) What checksumming/CRC/hash/error correcting method should be used to insure 100% accuracy?
d) Are there any other potential snags or gotchas, such as the inability to print and/or scan on a specific part of a page and/or issues with inks fading over time, etc., etc.?
e) All of the above with only black and white permitted...?
f) All of the above with grayscale permitted...?
g) All of the above with all colors that a printer can produce permitted...?
An interesting question in information storage/retrieval, no?
Perhaps it would make a good future interview question...
> store small amounts of data ... as graphical designs ... on pieces of ordinary printer paper?
You mean, printing out a picture?
...
Joking aside, if you tolerate lossy "compression", it'd be interesting to see what the characteristics of printing an image are in terms of image codec metrics. I guess the comparison would be with the "decoded" result, which'd be the raw output of the scanner. With modern equipment, it'd certainly be much higher quality than a JPEG encoded at the (albeit conservative) ~200 kB estimates given for the lossless formats.
This would also be a rare codec where future increases in decoder technology can actually increase the quality of the decoded output, assuming that the printer and scanner currently have similar DPI. I wonder whether that applies still to historical film photos or if digital scanners have already surpassed the resolution of the original media to the point of saturation. Would being able to "subsample" individual film grains allow extracting a tiny bit more detail?
Cauzin Softstrip did this back in the day to save magazine readers from having to type in programs or raw byte code. Or at least, that was the theory, I never actually had a fancy enough setup, or knew someone that did, to see it in action.
Working with the real thing, I remember the horrible feeling when the rubber band holding the card deck together snaps! The FORTRAN cards all had line numbers, but what a pain for a several hundred line program.
I heard it mentioned by an old timer that some programmers in those days used to draw a diagonal line with marker across the side of the stack of cards. This was to make sorting the cards faster if the stack was dropped.
I've got a real hankering to build one of these that punches (or lasers) actual paper tape. There's quite a few examples of DIY tape readers, but I can't find any for tape punches. Heck, even obtaining the tape seems to be a real PITA.
It disturbs me that, 35 years after IBM stopped making punched-card equipment, I still can read card codes. There are definitely better uses for those neurons.
We got personal computers into our university (one lab of Macs for CS and one of PCs for engineers) because of the discontinuation of unit-record equipment. Working with several people from affected departments, I co-authored the proposal that was ultimately approved; we submitted it to the university committee that was struck to manage this transition, the “Committee to Abolish The Card Reader” (yes, that was its official name). To this day, I'm pleased that we managed to bypass time-sharing terminals for our first- and second-year students.
"""I wrote the code and Phil wrote the double- precision part. I tried to anticipate what scaling would be necessary. I reread my code and checked it for bugs. Phil checked it for bugs. I (or Phil) punched up the code on teletype tape and checked that out. The tape was converted automatically to a wire, and the wire cartridge was inserted in the SEAC. We manually set n = 20, crossed our fingers, held our breath, and pushed the button to run the program.
The SEAC computed and computed and computed and computed. Our tension mounted. Finally, the computer started to output the Gaussian abscissas and weights. Numbers purporting to be such started to spew out at the teletype printer. The numbers had the right look and smell about them. We punched in n = 24 and again pushed the “run” button. Again, success. And ditto for even higher values of n.
The staff of the NBS computing lab declared us “Heroes of the SEAC”, a title awarded in those days to programmers whose programs ran on the first try—a rare event—and for some while we had to go around wearing our “medals,” which were drawn freehand in crayon on the back of used teletype paper. (The word “hero” was in parody of the practice in the Soviet Union of declaring persons “Heroes of the Soviet Union” for this and that accomplishment.)"""
My father worked in early IT days and a major fixture in my home growing up was boxes - and I mean dozens and dozens of boxes filled with thousands each - of punch cards they stopped using (all unpunched).
They made for fantastic quick note-taking, grocery-list making, or leaving notes for the family.
This is a super fun site from a pure nostalgia perspective.
I want to see an Amdahl emulator running on a Hitachi emulator running on a Fujitsu emulator running on a zos emulator that runs Linux and reads punch cards. Fire up the DASD!
This hits me right in the nostalgia synapse. As a child I collected baseball cards and IBM punch cards. Of course MLB All-Star Game ballots were a double win
While the main body of a Hollerith card was invariably a light tan, it was typical to have a quarter-inch strip of color across the top. The idea was that you could tell the payroll program (purple) from the inventory program (green). It was also helpful to see which cards in the deck had been revised, if any, as they’d be a different color. Kind of like “revision pages” in a script, or output from “diff”.
There was indeed often a colored stripe at the top of the card. At computer centers I used, this stripe was used to indicate what JCL (job control language) statement was on the card. So the computer center would have a big stack of pink cards already punched with the statement to invoke the FORTRAN compiler, for example. The teacher told you to put a pink card at the front of your FORTRAN deck before you submitted it, or it wouldn't work.
Each punch card represents a single line of plain text. That's it.
Usually this was a single line of FORTRAN or COBOL code, but it could also be data like a person's name, age, etc. No idea why I didn't get that before. I may have had the idea that developers back then were writing in binary or something. As you type out the card, the holes are punched and the character is printed along the top, so humans can read it. (Cards can hold binary data as well, but I'm talking about the cards used by programmers and for data input by secretaries - say for new account info, etc.)
How many characters can a card hold? 80, of course. Even today, many IDEs will draw a line at 80 columns. I thought it was some pedantic formatting thing. I think many still do. Nope, just a holdover of 1950s tech. A stack of cards? That's akin to a single file, with each line of text data being an individual card. Need to fix a bug? Make a new punch card for that line of code and swap it out. Code reuse is card reuse. Just take that subroutine from one stack and slip it into your program's pile before your next run.
Sure, there were typewriters and printers for interactive use, but without magnetic tape or anything like a floppy, this is how you stored your program in a machine readable way.