66

The main reason punched cards aren't used any longer is density. A one-inch stack of cards is only 142 80-byte records (assuming the usual practice of encoding one byte per column). So if you need to store 50,000 records that's a stack of cards 350 inches tall (over 29 feet). And 50,000 80-byte records isn't that much, just 4 megabytes of data. If you ...


44

Do the holes in Jacquard loom punched cards represent input data or program code? yes. Let me tell you a story. Somebody I used to work with many years ago was flying into the USA (or it might have been Britain from the USA) with some half inch tapes containing the source code for a Cobol program. Because he was carrying the tapes separately to his luggage,...


37

Nice Question :)) Short answer: Density - It just takes way too much cards to store anything useful. (And no, there is no way back in the good old time of optimized data structures) When you think about it, punch cards are the safest way to backup data for long term storage. As usual that depends on your definition on 'safest way'. They are not ...


34

TL;DR; Punch card code is not binary but a collection of n out of m encodings. Long Story Yes, really a long story, so I'll only cover the main line from Hollerith to EBCDIC. there are many sidelines for special equipment, situations and as used by different manufacturers. Some covering up to 7 holes but all mostly compatible in the basic Numeric/Alpha ...


23

Uppercase text only needs six bits per character. The fundamental mistake that you are making is assuming that punch codes were binary numbers. They were not. The encodings were patterns, combinations of of zero, one, two, or three holes. This is a reference card in IBM 5081 format: The row numbering was somewhat odd, for historical reasons: 12, 11, 0, 1, ...


20

Although you have many correct answers describing the nature of the coding used in punched cards, no one has touched on the mechanical properties of the cards. Regular users of punched cards in the past would be familiar with this issue, as getting cards through the mechanics of a fast card reader regularly and repeatedly was a major issue at the time. If a ...


17

Program code for modern CPUs, in practice, consists of opcodes which tell the CPU what operation to perform, and operands which provide data to operate on. In RISC CPUs these are necessarily both encoded into the same instruction word, while in CISC CPUs the two usually live in separate bytes, with the operands following each opcode. However there are ...


15

All code is data. But not all data is code. For example, you can take a digital photo and the numbers represent light intensity across a 2D rectangle. Nobody would dispute that this is data but not code. Code is a special kind of data which controls behaviour. ... but it's not that simple. Arguably the digital photo controls the behaviour of whatever ...


13

Round holes might have been 'stiffer', but rectangular holes won on packing density. When IBM invented the 80-column card (up from the previous 40-column Hollerith card of the same size), they determined you could get more columns per card by using rectangular holes. IBM's own history describes two competing designs: the 80-column rectangular-hole card we ...


12

Your premise fails because it presumes higher density methods can't also be used. Back in the 1980s, the magazines that published code started using a barcode scheme so you could wand the program into your computer instead of keyboarding. It didn't take off, but the concept is sound. Scanning those magazine pages is trivial; Google Books has already done ...


11

For most parts it's code. Well, code is a quite sloppy term, it covers a huge list of uses, from card scratching to encryption. So more correctly, it's a program (*1), as it defines a sequence of action to be taken by the machine - interpreted when the loom runs the cards. If at all, then thread is data. It is input from spools, processed by the loom ...


11

It wasn't just a Soviet thing: … This time I decided to look closely at the program deck. By now I knew just about everything there was to know about the source deck. The program deck was quite different from the source deck. To start with, it was a much smaller stack of cards. There were no letters typed on the top of the cards, and ...


9

I'd have added this in a comment but don't have enough rep. If you read far enough into the IBM history link given by another-dave in his answer, you'll find this quote that indicates the rectangular holes were in fact stronger: As well as handling more data, the unique rectangular hole was stronger [emphasis mine] and more compatible with the wire brushes ...


8

Many years ago I worked in a shop that had desktop apps (VB6) and mainframes. I developed an app that replaced punch cards with ASCII text. This was in the 1998-1999 timeframe. The biggest reason given was the card reader was highly mechanical and broke down several times a week. Eventually, parts were difficult (if almost impossible) to obtain. The ...


8

However, there were other possibilities, such as a later IBM format that used round holes. Not only later, but also previous IBM formats used round holes. Similar next to all other contemporary (1930s) manufacturers (Powell, CDC, Honeywell, etc). Intuitively it seems to me that round holes would be better from a mechanical stiffness viewpoint, making the ...


7

There are also some failure modes you have overlooked. The GB academic community's copy of the 1966 census was stored on punch cards but when someone tried to reload it they discovered that a squirrel had nested in the punch cards and many were now unreadable.


7

I think the other answers cover the topic pretty well, but allow me to ask a related question as food for thought: is the music roll of a player piano code or data? On the one hand, the piano just sits there and does nothing without the roll, suggesting that it's "code". On the other, the roll is morally equivalent to sheet music that a human musician ...


7

TL;DR; What was the DEC CR11 card reader 'compressed Hollerith code' for? It essentially allows to read arbitrary card data as distinct 8 bit values, as long they follow the 'Hollerith scheme' of decimal encoding marked up with zones. Long Read: Compressed Hollerith: 5 rows are delivered as-is, and the other 7 (rows 1 to 7) are delivered as a 3-bit ...


6

It may not be ideal for graphics, but data - e.g. a family tree or government records - would be much safer if stored on punch cards in a fire-proof box. As already said, one card holds about 80 bytes of data, is made of paper, has the size of about, well, a postcard, and needs relatively low technology to read (or even, with some effort, you can train ...


6

The reason we don't use punch cards anymore is because literally every other data storage medium that's been invented since is vastly superior in every way imaginable. Let's compare them to the current media of choice for long-term data storage: magnetic tapes: The first is obviously density, as every other answer here reflects, so I won't get into that ...


6

If you didn't have access to (magnetic) backing store then the only way to keep your executable code once you'd compiled/assembled your source code would be to output the working file to paper tape or punched cards. However as a student in the late 70s, it was more a case of retrieving the job to correct source code errors, or runtime program faults; once ...


6

Fundamentally the card is just an 80x12 array of bits (punch = 1, no punch = 0) and it's up to the system reading the card to interpret them. For example, the IBM 701 could read a card in "binary" mode, which interpreted the card as 12 rows of 72 bits (the rightmost 8 columns were ignored). Each 72-bit row represented two 36-bit machine words, which could be ...


6

The Jacquard loom predates the computer by a long time. As such, the distinction is a bit like asking whether or not a horse runs on diesel or petrol; whatever distinction you're trying to make by applying terminology from a different technology isn't likely to be useful or meaningful. The distinction between code and data is mostly a relic of Von Neumann ...


5

The fascinating thing to me is the way in which the media is a hybrid of a punched card and a floppy. It's more like a floppy - especially in its original version, the IBM 2321 Data Cell Drive of 1964 (see below). MagCards are a downscale from the 2321, which was, at its time the top end of random accessible online storage. They provide much larger storage ...


5

The pencil marks would have been punched into the card. Back in the 1960s-70s most computer suites had teams of people who would transcribe written notes onto punched cards. My mother worked part-time in one for many years. These places were the typing pools of their day. Data would arrive either on paper or on part-punched cards and the operators would ...


5

Punched cards generally contained human-readable source code or data. In combination with computers, they were pretty much exclusively used as a data entry (as opposed to data storage) medium. You can find an example of the encoding used in the section "IBM 80-column punched card format and character codes" of the Wikipedia article, https://en.wikipedia.org/...


5

The code punched into a 12-row card is not a binary code, but actually a form of extended decimal coding. Rows 0-9 are used to directly encode decimal digits, while letters and symbols are encoded as one decimal row plus one "zone row" which could be the A, B or 0 rows. Within the IBM 1401 series, this was re-encoded as an extended-BCD code in six ...


4

Punched card object files were used as a "standard" method of distribute software in some low-volume specialized applications. In the 1970s, magnetic disks were not generally portable, and the proliferation of incompatible magnetic tape hardware and software being developed made it problematical for a small scale software development team to produce tapes ...


4

Unfortunately, as someone who was around in those days of punch cards, a major con was the sheer size and costs of the card puncher and the reader. And as they were paper cards there was always the issue of card-jams/ripped cards, not only possible in the card puncher, but in the reader as well. A punch machine and reader/sorter required an area of about 10'...


4

There are plenty of good reasons but to me the primary reason is the ease of copying. Two copies on bad mediums are more desirable than one copy on a good medium. I put a 4TB drive in a box and in less than a day have a complete copy on the medium of my choice. Don't try this with your box of punch cards at home. Punch cards are only as good as the staff ...


Only top voted, non community-wiki answers of a minimum length are eligible