Punched cards are the stock image of early computing: a technician feeding a deck into a mainframe, a room of card-punch operators, a dropped box of cards ruining someone's week. But the punched card did not come from computing at all. It came from the textile industry, and it arrived a full century and a half before the first computer.
In 1804 a French weaver named Joseph-Marie Jacquard demonstrated an attachment for the drawloom in Lyon. Figured silk — brocade, damask, anything with a picture woven into it rather than printed on it — required a second worker, the draw boy, sitting above the loom and lifting warp threads by hand in the right combination for every single pass of the shuttle. It was slow, it was error-prone, and every new pattern meant re-rigging the loom from scratch.
Jacquard's mechanism replaced the draw boy with a chain of stiff cards. Each card carried a grid of holes, and each hole corresponded to one hook attached to one warp thread. Where there was a hole, a rod passed through and the hook lifted. Where the card was solid, the rod was blocked and the thread stayed down. One card encoded one row of the image. The cards were laced together into a continuous loop that advanced automatically with every throw of the shuttle.
Why this was the important part
The weaving speed mattered commercially, but the structural idea mattered far more: the pattern was no longer part of the machine.
Before Jacquard, a loom set up to weave one design was a machine for weaving that design. Changing the output meant physically rebuilding the apparatus. After Jacquard, the loom was general-purpose and the cards were the specification. Swap the deck, get a completely different fabric, with no change to the hardware whatsoever.
That is the separation between a machine and the instructions it executes — the distinction we now call hardware and software — and it was demonstrated in a weaving shed in 1804 by someone who was not trying to invent computing.
The line from Lyon to IBM
The idea propagated fast, because everyone who saw it understood immediately that it was about more than cloth.
Charles Babbage owned a Jacquard-woven portrait of Jacquard himself — an image requiring roughly 24,000 cards to produce — and adopted punched cards as the input mechanism for his Analytical Engine, designed in the 1830s. Ada Lovelace's note on that machine makes the parallel explicit: the engine, she wrote, weaves algebraic patterns the way the loom weaves flowers and leaves.
Herman Hollerith turned the concept into a business. The 1880 US census took roughly eight years to tabulate by hand, and the country was growing fast enough that the 1890 count risked not finishing before the next one began. Hollerith's electromechanical tabulator read punched cards to sort and count population data, and the 1890 census was processed in a fraction of the time. His Tabulating Machine Company merged into what became IBM in 1924.
From there, punched cards ran business data processing, then early electronic computers, then FORTRAN and COBOL program entry, right up to the terminal displacing them in the 1970s. A single encoding format stayed in continuous industrial use for over a hundred and fifty years.
The same idea is in your firmware
Reduce a modern connected device to its essentials and the Jacquard structure is still there. A microcontroller is a fixed, general-purpose machine. Firmware is the deck of cards. The silicon does not change; the instructions in flash decide what the product actually is.
This is why an over-the-air update is possible at all. When a sensor node in the field gets new firmware, nobody visits the device — the machine stays exactly as it was and only the specification changes. The same ESP32 module can be a water-level monitor, a queue counter, or a cold-chain logger depending entirely on what is loaded onto it. That is a Jacquard loom with a radio.
It is also why the discipline around firmware matters so much in IoT work. Once the instructions are the product, versioning, rollback, and update integrity stop being housekeeping and become the core of the system. A loom with the wrong deck weaves the wrong cloth. A fleet with the wrong image bricks in the field.
Worth remembering locally
There is a practical reading here for anyone building hardware in the Philippines, where custom silicon is off the table and imported modules are the starting point for nearly every project. Jacquard did not invent a new loom. He built a control layer on top of an existing one, and the control layer was where all the value turned out to be.
That is broadly the right posture for local product work: the differentiator is rarely the board, it is the firmware, the protocol choices, and the cloud layer sitting behind them. A team that treats off-the-shelf hardware as a substrate and puts its effort into the instruction layer can ship something genuinely distinct without a fab.
If you are working through an IoT product, thesis prototype, or connected-device deployment, or you want to talk about how to structure firmware and updates for a fleet you will have to maintain, get in touch with us — we work across the whole stack, from the board to the dashboard.
Two hundred and twenty-two years on, the insight still holds: build the machine once, and put the intelligence in what you feed it.
Top comments (0)