From punched cards to stored programs

Imagine running a library before spreadsheets. You want to count books, sort them by category, and find overdue loans. A machine can speed up those tasks only after someone decides how a book, a category, and an instruction will be represented. That human decision comes before the calculation.

A hole can be a fact, not an instruction

For the 1890 United States census, Hollerith’s equipment used cards with holes encoding information about people. Electrical tabulation helped turn records into counts. A census card was not automatically a general-purpose program: the equipment and its configuration determined how the encoded facts were processed. The Census Bureau describes that workflow.

The useful distinction is between data and the procedure applied to it. In our imaginary library, changing a book’s category changes a record. Changing the definition of “overdue” changes the rule. Either can alter a report, so checking only the final number misses important evidence.

Electronics changed speed; stored programs changed flexibility

Early computing history contains overlapping projects with different purposes. ENIAC’s public presentation in 1946 highlighted electronic calculation. It did not make every earlier calculating device irrelevant, and electronic operation alone does not tell us how a machine was programmed.

In 1948, the Manchester Baby demonstrated execution of instructions held in memory. It was an experimental machine, not a ready-made personal computer. The turning point was practical evidence that stored instructions could direct electronic computation. Loading another instruction sequence could change the job without redesigning the whole physical machine.

That is why “the first computer” needs a qualifier. Mechanical calculation, electronic operation, general-purpose programmability, and stored-program execution answer different historical questions. The people operating and programming these systems mattered alongside the people designing their circuits.

Flexibility gives changes more power

A stored program does not require instructions and data to share one physical memory. It also does not mean every memory region is freely writable or executable. Those are separate architectural and protection choices.

What persists is the need to trust the procedure. Today a signed update, a reviewed change, or a reproducible build helps answer who produced a program and whether it changed. No single control proves that the program’s decisions are correct. A legitimate but mistaken rule can still produce a bad report.

PredictThe library restores yesterday’s book records but keeps today’s faulty counting program. Must yesterday’s totals return?

No. Recovery needs the relevant data and a known, appropriate program version. Restoring only one side may reproduce the error. This is why a recovery plan records dependencies, not just file names.

History gives us a practical habit: separate the record, the rule, and the permission to change each. That habit applies just as well to a phone update or a cloud invoice as it does to a stack of cards.