Before punch cards and programmable computation, humans engineered astonishing mechanical systems to represent, control, and display data. These devices served as precursors to modern information technologies, blending automation with symbolic function.

Heron’s automation project for a statue of Bacchus pouring wine and milk in a temple. Illustration in a 13th century manuscript. Source

A self-trimming lamp, from the book “On Mechanical Devices” by Ahmad ibn Mūsā ibn Shākir (9th century CE). Source: Staats Bibliothek Berlin

Strasbourg astronomical clock (1574), a civic monument of timekeeping and automata. Source

Van Eyck and the Hemony brothers working on the carillon. Lithograph by W. G. Hofdijk (c. 1875), from “Lauwerbladen uit Neerlands Gloriekrans. Source

Claude Monet, “The Zuiderkerk, Amsterdam” (c. 1874). Philadelphia Museum of Art. The Zuiderkerk tower (1656) was among the earliest to house a fully automated Hemony carillon — a direct antecedent to punched media. Source

One of the earliest documented examples is Heron of Alexandria’s 1st-century CE automata: programmable theater devices, coin-operated dispensers, and wind-powered machines. These relied on systems of ropes, gears, and counterweights — physical logic encoded in motion. They demonstrated that information could be embedded in a mechanism, with repeatable outputs triggered by controlled inputs.

By the late Middle Ages and early modern period, public clocks and automata took on increasingly representational functions. The Strasbourg astronomical clock, for instance, combined religious calendar tracking with celestial mechanics, animating saints, angels, and planetary positions. These weren't mere decorations — they automated civic rituals and encoded cosmic models for public audiences.

In the 17th century, the Hemony brothers pioneered pinned-cylinder bell carillons in Amsterdam, prefiguring later musical machines and punch card systems. Their programmable melodies translated sound into hardware logic — a principle reused in music boxes, player pianos, and eventually looms and computers.

In 1725, Basile Bouchon, a textile worker from Lyon, adapted techniques from pinned music automata to control weaving with perforated paper tape. It was a subtle revolution: a machine that could remember patterns. This innovation marked the beginning of externalized, symbolic memory for controlling machines.

Jacquard loom with punch cards (c. 1840). The punched card mechanism controlled warp threads, enabling automated weaving of complex patterns. Source: National Museum of American History

Chain of 8×26 hole punched cards used to program weaving patterns (early 19th century). Source.

By 1804, Joseph-Marie Jacquard refined this concept into a fully automated loom using punched cards. Each row of holes controlled which warp threads were lifted, encoding textile patterns in binary sequences.

These punch cards enabled repeatability, modularity, and the separation of logic from mechanics. The loom became a programmable system — its behavior governed by structured data. Charles Babbage later cited Jacquard’s cards as direct inspiration for programming his Analytical Engine, applying the same logic to mathematical computation. Textile control became abstract logic.

Digital aesthetics of the 1990s have deep roots in Jacquard weaving, where each punch is a bit and each row a line of code. Image generated by authors.

Digital aesthetics of the 1990s have deep roots in Jacquard weaving, where each punch is a bit and each row a line of code. Image generated by authors.

By 1880, the U.S. Census had become a monumental paper problem. Processing returns by hand had taken nearly a decade — far too long for a modern bureaucracy. To break the bottleneck, a young engineer named Herman Hollerith turned to a familiar source: punch cards, inspired by Jacquard looms and railway tickets.

Tabulating machine by Herman Hollerith (c. 1890). Its punch-card system adapted the Jacquard method for demographic counting. Source: American History museum

Hollerith’s breakthrough wasn’t the cards themselves, but the electromechanical system that could read them. His 1889 tabulator used metal pins to detect holes in a card and close electrical circuits, counting data categories automatically. With custom sorters and punched templates, information could be processed faster than ever before — and with far less human labor.

Long before mechanical tabulators, governments used data to exert control. In early modern Europe, the rise of absolutist states brought new pressures to measure, compare, and forecast populations. Inspired by older registers like the Domesday Book, a new intellectual tradition emerged in the 17th century: political arithmetic.

Title page of Johannes Weitzel’s “Geschichte der Staatswissenschaft” (early 19th century), reflecting the formalization of state science as an academic and administrative discipline in German-speaking regions. Source

William Petty (1623–1687), pioneer of political arithmetic. His demographic and economic analyses laid foundations for modern statistical governance. Source

Table from the Down Survey (1655–1656), an early large-scale land and property data collection in Ireland under William Petty, using tabular methods to inform colonial administration. Source

Folio from the Domesday Book (1086), detailing Warwickshire. Part of William the Conqueror’s survey of English landholdings, one of Europe’s earliest centralized census efforts. Open Domesday

Pieter Bruegel the Elder, “The Census at Bethlehem” (1566), a Flemish reinterpretation of the biblical census that blends daily life with state authority in early modern administrative culture. Source

Pioneers like John Graunt and William Petty introduced statistical summaries of mortality and trade in London, proposing that societies could be studied mathematically. In German-speaking states, this formalized into Staatswissenschaft — the “science of the state” — combining demographic counts, land surveys, and resource assessments into a toolkit for rational administration

After the success of the 1890 U.S. Census, punched card machines quickly became a pillar of state and corporate infrastructure. Already in 1891, governments in Canada, Norway, and Austria had adopted versions of punch-card tabulators for their own censuses.

Then, Hollerith’s systems — now under the Computing-Tabulating-Recording Company (CTR), which later became IBM — expanded from population counts to civil registries, tax records, military logistics, and industrial payroll.

Hollerith’s U.S. patents (Nos. 395,781–783, 1889), collectively describing his invention as the “Art of Compiling Statistics.” Google Patents

Herman Hollerith with his punch-card tabulating machine, used in the 1890 U.S. Census. Transcription required 72.5 hours (twice as fast as competitors), while tabulation took only 5.5 hours (ten times faster). MIT Technology Review

Scientific American, August 1890, featuring Hollerith’s census machine. From the collection of Dr. Sid Kolpas. Mathematical Association of America

In Europe, punched card tabulators were used to track unemployment during the Weimar Republic and later for darker purposes under totalitarian regimes. In the U.S., corporations adopted the technology to manage workers and inventories. Punched cards became tokens of identity: each card a fragile stand-in for a worker, a file, a life — processed at scale.

Their layout became standardized: 80 columns, rectangular holes, precise rows. What began as a statistical tool evolved into a universal format for encoding human activity. This expansion paved the way for mainframe computing, but it also quietly embedded new logics of sorting, surveillance, and abstraction — long before digital systems arrived.

Long before modern statistics, societies developed elaborate systems for counting people, goods, and time.

Cuneiform tablet (Sumer, c. 3000 BCE), used to record grain and livestock quantities as part of temple administration. Such artifacts enabled resource tracking, labor management, and redistribution across Mesopotamian city-states. Musée du Louvre, AO 29560. © 2002 GrandPalaisRmn (Musée du Louvre) / Franck Raux. Louvre

Clay tokens and bullae (Sumer, pre-3000 BCE), used as transaction records. Small tokens representing goods such as grain or sheep were sealed in hollow clay envelopes. This system provided the conceptual groundwork for abstract numeration and the invention of writing. Musée du Louvre, Iran antique 17403. Source

Model of cattle census (Egypt, 11th Dynasty). Wooden funerary model from the tomb of Meketre, showing scribes counting livestock. Such scenes were both documentary and magical, intended to ensure the eternal continuation of bureaucratic order and provisioning in the afterlife. Egyptian Museum, Cairo. Source.

Han Dynasty administrative slips (China, c. 1st century CE). Strips of bamboo and wood bound into scrolls, used to record census figures, tax receipts, legal proceedings, and edicts. Though paper existed, these durable media defined early Chinese record-keeping at imperial scale. Ejine Banner Museum of Inner Mongolia. China Services Info

Roman military diploma (90 CE), cast in bronze. Granted citizenship and marriage rights to a discharged auxiliary soldier. Designed for durability and authenticity, such diplomas reflect Rome’s infrastructure for legal and identity verification across the empire. Israel Museum. Source

Census of Quirinius, mosaic (Istanbul, c. 14th century), Church of the Holy Saviour in Chora. Depicts the biblical census from the Gospel of Luke, enshrining Rome’s enumeration practices in religious memory. The scene links identity, taxation, and power, showing census as both ritual and registration. Source

In ancient Sumer, clay tokens evolved into cuneiform tablets to track grain, livestock, and labor — a direct response to the needs of temple economies. Egypt’s annual nilometer readings and population tallies shaped everything from taxation to cosmic order. In Imperial China, the household registration system (hukou) maintained dynastic stability. Rome’s census did more than record — it legitimized class, military duty, and political privilege.

Tables were among the earliest tools used to organize and transmit information. In antiquity, cuneiform tablets managed inventories and taxes. By the 6th century CE, the Eusebian Canon Tables linked Gospel passages across the New Testament, facilitating theological study and laying the foundation for relational thinking.

Eusebian canon tables from the Gospels, Armenian manuscript (12th century CE). A Christian adaptation of Hellenistic cross-referencing, these tables represent an early method for structuring complex information. Walters Manuscript W.538, fol. 10v. Source: The Walters Art Museum

Medieval Islamic scholars refined astronomical and mathematical tables, using them to convey empirical and calculated data. In Western Europe, tables were employed for liturgical purposes such as computing the Easter date, exemplified by Dionysius Exiguus's calendrical system in 532 CE.

By the 17th century, printed tables circulated widely, covering subjects from demographic counts to planetary motion, and provided a standardized format for organizing and comparing information.

Mathematical methods pushed economic data beyond counts and inventories. But the abstraction came with choices: what to count, what to ignore, and how to draw a system where labor and material resistance disappeared.

This was no longer about describing society, but simulating it. Graphs of cost and output treated work as a function, not a force. The body vanished. Diagrams circulated through ministries and lecture halls, presenting a world of perfect inputs and optimized exchange.

Lancashire power loom from Richard Cotton Marsden’s “Weaving: Its Development, Principles, and Practice” (1895). English looms like this dramatically increased textile productivity while displacing skilled handweavers across the countryside. Source

Luddite resistance, engraving by unknown author (early 19th century). The uprisings of the 1810s were less a rejection of technology than a revolt against the erosion of skill, autonomy, and fair wages under early factory regimes. Smithsonian Magazine

In this shift, the loom returned — not as a machine, but as a metaphor. Economic modeling borrowed its logic: patterns encoded, complexity reduced, skill displaced. And just as mechanical looms once triggered uprisings among artisans, this new epistemic loom — operated by economists — restructured the world with invisible consequences.

While Herman Hollerith’s punch-card systems became the foundation of administrative computing, other thinkers explored more physical metaphors for modeling economic systems. In 1891, economist Irving Fisher built a hydraulic machine to simulate general equilibrium using interconnected tubes and flowing water. By adjusting valves and fluid levels, users could visualize supply, demand, and price dynamics across markets.

This idea didn’t end there. In 1949, Bill Phillips, a New Zealand economist and engineer, built the MONIAC — a larger hydraulic computer that modeled national income flows, taxes, investments, and savings using colored water in tanks and pipes. It became a teaching and policy tool, particularly in postwar Britain.

Irving Fisher’s hydraulic machine (1891). A pioneering attempt to simulate market equilibrium, using water to model flows of supply and demand. Conversable Economist

The MONIAC, built by Bill Phillips (1949). An analog computer using tanks and pumps to demonstrate Keynesian economics. Conversable Economist

These analog machines never reached administrative scale. But they represented an alternative path: computation through embodied simulation rather than abstraction. Their legacy is conceptual — a reminder that the urge to visualize systems long predated digital spreadsheets, and that data modeling once flowed, quite literally, through pipes.

Sir Henry Furnese, who founded the Bank of England in 1694, was among the first merchants to build espionage networks, gathering reports from across Europe on military, political, and trade affairs. His ability to anticipate market shifts through such information marked an early form of business intelligence, moving commerce from instinctual decision-making toward data-driven speculation.

Adriaen van Diest, “Destruction of the Soleil Royal at the Battle of La Hogue” (1692). This pivotal event in the Nine Years’ War shaped European political and military outcomes and influenced emerging financial systems. The Bank of England, mentioned earlier, was founded to fund this conflict. Source: Royal Museum Greenwich

With the rise of industrial capitalism, businessmen sought more formalized, empirical ways to manage complexity. In the 1880s, engineer Frederick Winslow Taylor developed time-and-motion studies to measure labor productivity. His data-driven insights redefined managerial decision-making.

Film still from a pioneering study by Lillian Gilbreth and Ralph Barnes (1910–1924). Using motion-picture analysis to record factory tasks, they developed motion study techniques that advanced systematic approaches to business intelligence and laid foundations for data-driven management in early 20th-century industry. Source: Archive.org

In the early 20th century, the pioneering films by Lillian Gilbreth and Ralph Barnes, investigating industrial operations and developing motion study techniques (1910-1924), further advanced the systematic approach to business intelligence. Their work laid the foundation for the growing use of data to streamline operations and decision-making.

Soon after, Henry Ford adapted such techniques to refine production lines, timing the manufacture of each component and embedding measurement into industrial practice.

As statistical thinking matured, so did methods to visualize it. By the 17^th century, England’s Bills of Mortality were not only collected but interpreted. John Graunt’s 1662 analysis offered early demographic insights, tracking plague deaths and life expectancy. A few decades later, Edmund Halley’s mortality tables laid the foundation for actuarial science.

In the 19^th century, the use of charts and graphs became more systematic. William Playfair’s bar and pie charts helped represent trade balances and budgets. In the U.S., business statisticians embraced infographics to guide decision-making.

Illustration from Willard Brinton’s “Graphic Methods for Presenting Facts” (1914), using the octopus metaphor to depict the complexity and interconnectedness of data. Source: Archive.org

Willard Brinton’s Graphic Methods for Presenting Facts (1914) emphasized that clear representation could shape executive understanding. His manual ranged from simplified charts to complex 3D diagrams, promoting visuals as practical tools for business and government.

The industrial push to mechanize business records brought calculating devices out of labs and into the workplace. In 1879, Ohio saloon owner James Ritty and inventor John Birch patented the “incorruptible cashier,” a mechanical register designed to prevent employee fraud.

Models were soon enhanced with paper rolls for printed receipts, turning cash registers into trusted tools for recording financial transactions. This innovation led to the founding of companies like Burroughs and National Cash Register, which later pivoted into the computing industry.

Meanwhile, Swedish engineer Willgodt T. Odhner, working in St. Petersburg (Russian Empire), developed a compact mechanical arithmometer in the 1870s. His device, refined over decades, became a standard in Soviet administrations and was marketed in the West under the “Facit” brand.

Blueprint of the cash register and indicator from U.S. Patent No. 221360, filed by James and John Ritty on November 4, 1879. Google Patents

Illustration of Odhner’s arithmometer from the magazine “Science and Life” (Nauka i zhizn), No. 45 (1890). Life and Science

In 1890, Herman Hollerith demonstrated his punch card tabulator to the Actuarial Society of America, marking a pivotal moment in the adoption of data-driven decision-making in business. Insurance companies like Prudential quickly saw the potential and adopted the system to streamline claims processing, though some actuaries, including John K. Gore, developed faster alternatives to Hollerith’s machines.

By 1910, Hollerith’s tabulator was being used by British railways to monitor costs and revenue per locomotive, linking granular data to profit margins. As Hollerith’s company evolved into IBM, the technology spread into European transportation networks — in 1928, Ferrovie dello Stato in Italy began using IBM equipment to manage train schedules and spare parts.

Postcard of Earby Station (Edwardian England, 1905). Source

Electric train ETR200 of the Italian State Railways (mid-1930s), connecting Milan and Torino, where precise scheduling was critical. Source

UNIVAC central panel, used by operators to control programs and monitor machine status through switches and indicator lights. Photo by Don DeBold. Source

The UNIVAC I (Universal Automatic Computer I), introduced in 1951, was the first digital computer designed for commercial use in the United States. It was a room-sized system powered by thousands of vacuum tubes, using magnetic tape drives along with punch cards. UNIVAC could execute approximately 1,905 operations per second, and it employed mercury delay line memory capable of storing 1,000 words of 12 characters each.

This hardware allowed UNIVAC to handle both numeric and alphabetic data at unprecedented speeds for its time. It was programmable, universal in purpose, and significantly outpaced earlier mechanical and electromechanical systems.

The machine sold for between $1.25 and $1.5 million, which limited its potential to spread across industries. But its cultural impact was such that it quickly became a symbol of the new era of machine-powered thinking.

UNIVAC’s debut wasn’t in theory — it was in practice. The U.S. Census Bureau became the first non-military, non-academic institution to operate an electronic digital computer. The agency used it to tabulate census data, performing large-scale record matching and statistical analysis that would have taken human clerks weeks or months.

A UNIVAC computer at the U.S. Census Bureau (c. 1960). Source: U.S. Census Bureau

This early deployment in 1951 was so successful that the Bureau later declared UNIVAC had never been involved in any error incident — a powerful vote of confidence in machine logic at a time when skepticism ran deep. Soon after, General Electric became the first private business to use UNIVAC, adopting it for payroll computation.

At the time, IBM dominated government installations. Their tabulators were already embedded across agencies. Many public-sector computing offices were effectively IBM-run — staffed by former IBM employees, running IBM systems, and thinking in IBM workflows. UNIVAC, though technically superior, was considered an outsider.

As one official put it:

“If I recommend UNIVAC and it fails, I made a mistake. If I recommend IBM and it fails, IBM made a mistake.”

By the mid-1950s, the U.S. Air Force and other federal agencies had adopted UNIVAC systems for logistical planning, missile tracking, and resource scheduling. These systems weren’t designed for battlefield control, but served instead as part of the administrative backbone of Cold War operations.

UNIVAC’s ability to process alphabetic data was a major advantage, allowing for more complex record-keeping and scenario modeling than number-crunching machines alone.

Air Force enlisted specialists operating a UNIVAC computer (July 28, 1956). Source: Special Collections and Archives; Wright State University Libraries

Toward the end of the decade, Remington Rand’s UNIVAC division was bidding alongside IBM for government defense contracts, embedding itself in the infrastructure of federal automation. Unlike IBM’s tightly controlled systems, UNIVAC’s flexibility and tape-based I/O made it attractive for unconventional environments — from defense logistics centers to early weather modeling programs.

J. Presper Eckert and John Mauchly, already known for ENIAC, left wartime research to form the Eckert–Mauchly Computer Corporation. Their aim was to build a “universal automatic computer” that could handle business records as easily as equations.

UNIVAC began not with a corporation but with two engineers pushing an idea beyond ballistics. But their startup struggled: capital was scarce, the market uncertain, and the technology untested.

In 1950, the project was absorbed by Remington Rand, a typewriter and office-equipment giant with money and distribution power. That merger kept the machine alive — and with it, the possibility of a commercial computing industry.

While UNIVAC made waves in the U.S., the UK had its own breakthrough in 1951: the Ferranti Mark I, derived from the Manchester Mark I project at the University of Manchester. It holds the distinction of being the first commercially available stored-program digital computer — predating UNIVAC by a few months. While primarily delivered to research institutions, it marked the beginning of programmable computing as a product.

The machine was designed to process 20-bit words, with a memory architecture that included vacuum tube storage (each tube holding 64 words) and a magnetic drum with capacity for 512 pages. It sold for between £50,000 and £100,000, and crucially, was made available beyond the confines of academia or government labs.

Alan Turing (right) with the Ferranti Mark I, 1952 — the only known photograph of Turing with a computer. The image appeared on the front cover of Ferranti’s Mark I brochure. Source: Science Museum Group Collection © The Board of Trustees of the Science Museum

The Ferranti Mark I supported a wide range of programs, from business analytics and scientific modeling to experimental computer music and some of the first computer games. Its stored-program design — the ability to modify instructions directly in memory — allowed far more complex data manipulation than earlier fixed-instruction machines.

The Dnipro (Dnepr) computer, developed in Kyiv, Ukraine in the late 1950s and early 1960s, marked a key shift in Soviet computing: the move from vacuum tubes to transistors. It was part of a broader effort to modernize scientific and industrial computation across the USSR and its satellite states.

Academician Viktor Glushkov presenting the Dnipro computer at the Ukraine Fair, Kyiv (1962). Photograph by unknown author.

Designed for engineering calculations, process control, and scientific modeling, it found applications in aerospace, power generation, and metallurgy. Its general-purpose design allowed deployment across state institutions, though use remained tightly controlled by government and industrial planners.

Despite limited commercialization, the system marked the Soviet Union’s entry into the transistor era and its attempt to match Western advances in computing.

Yugoslavia entered the digital age in the 1960s and 1970s with the CER (Cifarski Elektronski Računar) series, developed in Belgrade by the Mihajlo Pupin Institute. It was one of the first independent national computing initiatives outside the United States and the Soviet Union.

Early models like the CER-10 used transistor-based architecture with punched cards for input, later adding magnetic tape for storage and backup. The system featured 4 KB of magnetic core memory, expandable in later versions, and processing speeds in the tens of thousands of operations per second.

CER-10 computer at the Tanjug building (1963). Photograph by Dušan Hristanović.

CER machines were applied to scientific research, state statistics, and media tasks such as automated news distribution. They played a central role in modernizing Yugoslavia’s administrative and information infrastructure.

In 1956, statistician Richard Canning gave currency to the term Electronic Data Processing (EDP) to describe the systematic use of computers for managing information. He broke it into three integrated functions:

1. Decision support — automating lower-level management choices using structured data.
2. Order issuance — translating those decisions into paperwork such as production orders, invoices, and notices.
3. Feedback control — comparing outputs with goals and flagging discrepancies for correction.

This definition emphasized decomposing workflows into discrete steps, sequencing tasks, and keeping data stored, checked, and synchronized. EDP became a framework for applying computers to large-scale projects, from military logistics to industrial production and business operations.

At General Electric in the early 1960s, Charles Bachman led the development of the Integrated Data Store (IDS) — one of the earliest database management systems. IDS introduced the concept of an information inventory: a centralized, disk-based repository of shared records that could be queried and updated by multiple applications.

Walt Disney with GE president Gerald L. Phillipe at the Progressland Pavilion, New York World’s Fair (1964). Source: Smithsonian Institution Archives

This architecture enforced relationships between records — what would later be called the network data model. IDS supported a data dictionary to track record structures and allowed programmers to retrieve or update data using early forms of a data manipulation language.

IDS ran on the GE-225 computer, paired with the MRADS disk system — offering random access to data, rather than the sequential tape storage common at the time. Its first major deployment, MIACS (Manufacturing Information and Control System), provided real-time production control at a GE factory in Philadelphia.

By unifying data storage and enabling shared access, IDS became the prototype for modern database systems. In 1973, Bachman received the Turing Award for this work.

In 1965–1966, Weyerhaeuser, a major U.S. timber company, became the first non-GE customer to implement IDS — turning the database into the foundation for a real-time, nationwide business system.

Sales brochure for the GE-200 series computer (1960s). The platform was later used for early IDS implementations. Source: Ferretonix.com

The setup linked over 100 remote teletype terminals to a central GE-235 computer using a DATANET-30 network. Orders placed across the country were entered directly into the system, which updated inventory, managed shipping logistics, and generated invoices.

The system used Problem Controller, an early form of online transaction processing (OLTP), to prioritize and manage concurrent requests. At peak demand, transaction volumes briefly overwhelmed the system, but the architecture proved robust and adaptable.

By the late 1950s, the Soviet Union faced a contradiction: while its military and scientific sectors deployed digital computers with growing sophistication, civilian institutions — especially Gosplan, the State Planning Committee — remained wary of adopting the same tools.

The USSR had previously used imported tabulators like Powers and Hollerith machines, later building its own analogs such as the T-5, exported to other socialist countries. But the leap to electronic computing was politicized. Even as Gosplan quietly launched its own Computer Center in 1959 and installed its first Ural-2 machine in 1960, internal resistance to large-scale data automation persisted.

Fidel Castro at the Main Computer Center of the USSR State Planning Committee, Moscow (1972), with Nikolai Baibakov, chairman of Gosplan, and Nikolai Lebedinsky, head of the center. Source

The paradox deepened in the 1960s. Despite new equipment — including British Elliott 403 and ICL System-4 machines — and cooperation with East Germany on ALGOL translators, Gosplan remained cautious.

A proposed national automation system, the OGAS network, led by cybernetician Victor Glushkov, envisioned a nationwide digital system for economic planning. But it was blocked — not due to technical failure, but because it threatened existing institutional control over data flows. In the Soviet model, information was not only infrastructure but also political power.

In the 1960s, Soviet cybernetician Victor Glushkov proposed a nationwide network of computers to manage the USSR’s economy in real time. Called OGAS (Общегосударственная автоматизированная система учёта и обработки информации), or the National Automated System for Computation and Information Processing, it aimed to unify factories, ministries, and planners in a single, continuously updated digital infrastructure.

The proposed system included regional computing centers linked to central hubs in a three-tier architecture, real-time inputs from across industries, and automated modeling to aid planning. Terminals were planned for remote enterprises, from industrial plants to mining sites and state-owned farms.

Glushkov’s team at the Kyiv Institute of Cybernetics had experience in systems design, and prototypes for smaller-scale implementations already existed. But OGAS never launched.

Victor Glushkov with Tadeusz Marjanovich, who led process-modeling research at the Kyiv Institute of Cybernetics. Near Kyiv, 1970s. Source: Glushkov family archive

The system promised transparency, efficiency, and redistributed authority, challenging the entrenched gatekeepers of economic knowledge. Despite repeated proposals through the late 1960s and early 1970s, OGAS was quietly defunded, gutted, and eventually abandoned.

In the early 1960s, two very different machines shaped how organizations approached digital information: the General Electric GE-225 and the IBM 1401.

The GE-225, introduced in 1960, was built for power and flexibility. It featured simultaneous input/output handling, supported both alphabetic and numeric data, and could connect to disk drives like MRADS. Input came from magnetic tape, punched cards, MICR documents, and even paper tape, with long-distance connections supported via the DATANET-15. It was a machine for custom-built systems like real-time data integration.

Meanwhile, the IBM 1401, released in 1959, took the market by storm with its affordability and reliability. Its six-bit character system, magnetic core memory (4K–16K), and decimal arithmetic made it perfect for payroll, billing, and inventory. Leased for around $2,500/month, it brought computing within reach of small and mid-sized businesses — earning the nickname "the Model T of the computer industry."

IBM 1401 computing the results for the city of Kiel, West Germany, during the federal election (1965). Source

Their rivalry wasn’t just about specs — it was about philosophies:

• IBM offered safe, standardized tools for the mainstream.
• GE pushed toward modularity, extensibility, and integration.

The GE-225 later found academic life as well — a time-sharing version at Dartmouth became the birthplace of the BASIC programming language.

In May 1959, over 40 representatives from government, industry, and academia gathered at the Pentagon to address a growing problem: early computer languages were difficult to learn and maintain, limiting business adoption. Their solution was CODASYL — the Conference on Data Systems Languages — a volunteer group aimed at creating a common, English-like programming language for business.

Cover of the FLOW-MATIC programming system manual, developed by Grace Hopper at Remington Rand (1958). Source: Bitsavers

At the time, Grace Hopper’s FLOW-MATIC, developed at Remington Rand UNIVAC, was the only business-oriented language using human-readable commands. Hopper, a pioneering computer scientist and naval officer, had long championed making programming more accessible. The committee, with members from Burroughs, Honeywell, IBM, RCA, Sperry Rand, and Sylvania, drew inspiration from her work.

On December 6, 1960, a live demonstration proved COBOL could compile and run the same code on both UNIVAC and RCA systems — a landmark moment for interoperability.

COBOL wasn’t designed in a vacuum — it was shaped by the constraints and capabilities of the early business computers it was meant to run on. The language was intended for high-volume, data-driven tasks on large systems like the UNIVAC I and II, IBM 705, Honeywell 800, RCA 501, Sylvania MOBIDIC, and Burroughs B-5000.

Grace Hopper speaking in 1982 about running COBOL and FORTRAN on various machines.

These machines varied widely in architecture and I/O capabilities, but COBOL’s standardization effort required them to speak a shared language. This forced a shift in how hardware designers thought about software compatibility, and it catalyzed interest in portable, high-level languages. The 1960 live demonstration of COBOL running on both UNIVAC and RCA systems proved the concept.

COBOL’s standardization opened the door to an entirely new market: commercial software development. In 1959, Advanced Data Research (ADR), a New Jersey–based firm, began offering contract programming services, specifically advertising COBOL expertise in Datamation magazine by 1961.

Advertisement for AUTOFLOW, a programmers’ assistance tool, in Datamation magazine (June 1966). Source: Bitsavers

One of ADR’s key products was AUTOFLOW, an application that automatically generated flowcharts from COBOL source code. At a time before video terminals, visualizing program logic on paper was essential. AUTOFLOW helped users trace and document complex logic paths, making it easier to debug, explain, or maintain large-scale software.

Despite Cold War tensions, the Soviet Union closely followed developments in Western data processing — and COBOL did not go unnoticed. In 1965, the Kyiv-based journal Kibernetika published a technical overview of COBOL by Lyudmila Babenko, helping introduce the language to Soviet scientific circles. She later earned a PhD for formalizing COBOL-style data translation methods for mass data processing.

Soviet adaptations emerged rapidly: the Dnipro-2 control system, built in Kyiv, integrated COBOL-like translators designed by Kateryna Yuschenko’s team. Meanwhile, the Minsk-22 computer from Belarus offered its own compiler variant. These efforts reflected a broader drive to align with international standards while maintaining domestic engineering autonomy.

Kateryna Yushchenko, member of Victor Glushkov’s pioneering team in Soviet programming. In 1955 she created the Address programming language, introducing indirect addressing nearly a decade before similar features appeared in Western systems. Source: Yushchenko family archive

The arrival of the ES EVM (Unified System of Electronic Computers), based on IBM System/360, brought COBOL-style programming into the mainstream of Soviet and Eastern Bloc computing. By 1975, COBOL had received an official Soviet standard.

In the early 1960s, computing began to move beyond producing static reports. Organizations were starting to manage dynamic, shared datasets. The first genuine database management systems (DBMSs) — GE’s IDS (1964) and IBM’s IMS (1965) — were built for disk drives and introduced persistent, structured storage that could be reused across applications.

The concept of a “database” itself came out of Cold War defense projects. In 1962, the System Development Corporation, which had worked on the SAGE air defense network, described shared repositories of information accessible to multiple users and programs — a step beyond archived output.

Airman First Class Trent Bailey, weapons controller technician, with Airman Toni Bailey, a new SAGE surveillance operator, Luke Air Force Base, Arizona (1975). NORAD newsletter archive. Source: Southwest Museum of Engineering,Communications and Computation

By the late 1960s, business computing circles were converging on the same need for consistent storage and retrieval. The CODASYL Data Base Task Group, backed by firms such as RCA and Remington Rand, began formalizing DBMS architecture. Their work intersected with advances in software portability and the push for standard program–data interfaces.

In 1957, IBM users formed SHARE and GUIDE groups to collaborate on programs for new hardware. Projects like SURGE and 9PAC extended the IBM 704/709’s capabilities. Though IBM didn’t develop them, it later supported and maintained 9PAC, seeing its value. These early systems experimented with data dictionaries, file hierarchies, and routines for migrating between hardware environments.

Apollo–Soyuz spacecraft in Earth orbit, docked configuration. NASA diagram (1974). North American Rockwell and IBM collaborated on systems for the Apollo program. Source: NASA Collection, S74-05269

Still, tape-based storage had limits. The real breakthrough came when IBM pivoted to disk — and partnered with aerospace contractor North American Rockwell to build IMS (Information Management System). Originally developed to manage components for the Apollo program, IMS pioneered hierarchical data models and multitasking data access.

By the late 1960s, IMS ran on IBM’s System/360 and supported multiple concurrent applications from a single memory image. IBM states that IMS still supports 95% of Fortune 1000 companies today.

IBM’s System/360, launched in 1964, introduced modular computers with upgrade paths, standardized architecture, and compatibility across a wide range of peripherals. Its design popularized the 8-bit byte, data channels, and 9-track magnetic tape, pushing the industry toward mass production and interoperability. European and Japanese manufacturers soon followed, building IBM-compatible systems.

IBM System/360 mainframe at the opening of The Washington Data Processing Center (April 1, 1966). Statistical Reporting Service of USDA Administrator Harry Trelogan looks on as Agriculture Secretary Orville Freeman tests out some of the functions. Photo courtesy of the National Archives and Records. Source: US Department of Agriculture Flickr

Key hardware elements for early database management included:

• Magnetic tape drives for sequential backups and bulk data archiving.
• DASDs (Direct Access Storage Devices) for fast, random access to structured data.
• Punched cards and paper tape as legacy media for data entry and programs.
• Terminals such as the IBM 2260 and Univac Uniscope, which enabled full-page interaction and gave users real-time access to enter, correct, and visualize data.

In the late 1950s, a spontaneous meeting between IBM and American Airlines executives on a flight sparked the idea for a computerized reservation system. Drawing from IBM’s military experience with the SAGE air defense system, the two companies built SABRE — the Semi-Automated Business Research Environment.

American Airlines SABRE advertisement showing the network of its computerized reservation system (late 1960s). Source: Tails Through Time

Launched in 1960, SABRE became the world’s first commercial real-time data system, handling 83,000 bookings per day via two IBM 7090 mainframes. Its interactive model allowed agents to check seat availability, confirm tickets, and update records instantly, replacing manual booking processes.

The 1964 Tokyo Olympics posed a monumental data challenge: 7,000 athletes, 100 countries, and up to 25 simultaneous contests across 32 venues. To manage this, IBM Japan deployed a real-time data processing system that transformed event coordination forever.

Data-printing center in the Olympic Village, Tokyo (1964). Source: Official Games Report

Using 62 IBM 1050 terminals across venues, scores were sent to a central Olympic Data Center powered by eight IBM computers. With a disk capacity of 56 million characters, the center processed rankings, judge scores, and registration data for 12,000 participants — within seconds. Over 100,000 messages were expected, with three to four times as many replies sent back.

By default, early computing relied on batch processing — collecting data over hours or days, then feeding it into a system for a single, uninterrupted run. This was ideal for repetitive, large-scale jobs like payroll or census tabulation. The method emphasized efficiency in an era when computer time was scarce and expensive.

Brochure page for the 1101 Keyed Data Recorder, Mohawk Data Science Corporation (1965). Source: Internet Archive

The shift to Online Transaction Processing (OLTP) enabled systems to handle data in real time, allowing for immediate response to user input. The change was made possible by new magnetic disks (offering random access), faster processors, and networked terminals.

In the early years of digital computing, businesses faced a fundamental problem: data was everywhere, and nowhere unified. The same customer’s name or address might live in multiple departmental files, each updated (or not) independently. This data redundancy consumed storage and bred inconsistency. A change made in sales might never reach accounting or shipping.

80-column punch card printed at the Tehnoinform facility, Riga, USSR (1976). Source: Tristan Davey’s Punchcard Archive

The emergence of Database Management Systems (DBMS) in the 1960s — such as GE’s IDS and IBM’s IMS — centralized data storage, enabling multiple applications to access the same version of a record.

Centralization also raised the stakes. Errors in one place could propagate everywhere, making data integrity critical: records had to be valid, correct, and complete. Fields were expected to follow strict rules — for example, prices had to be numeric and dates had to conform to valid calendar values. As data became more valuable, concerns about security also grew.

Early computers didn’t greet users with icons or buttons. Interaction meant command-line precision, punched card stacks, and binary switches. Human–machine communication was intense, physical, and deeply technical.

“A Fable for Computer Users,” Control Data Corporation booklet, 1960s. Source: Internet Archive.

“A Fable for Computer Users,” Control Data Corporation booklet, 1960s. Source: Internet Archive.

Users were mostly operators, engineers, and programmers — not everyday clerks or analysts. Programs were written in machine code or assembly, entered via punch cards or front-panel switches. The idea of a “user-friendly” system simply didn’t exist.

Control panels featured toggle switches, status lights, and manual overrides. Later came command line interfaces (CLIs), where users had to type exact instructions. A single typo could crash an entire batch run.

To improve efficiency, Job Control Languages (JCLs) emerged — scripts that told the computer what to do, in what order, and how to handle results. This was automation before the GUI.

Meanwhile, efforts to standardize peripheral interfaces, data formats, and operating procedures foreshadowed the shift toward interoperable systems. Symbolic abstractions like mnemonic codes pointed toward usability, but the user was still a technician, not a typist.

While interfaces determined how people spoke to machines, the machines themselves needed internal structures to manage information once it was loaded. Early programmers discovered that efficiency depended not only on commands, but on how data was arranged in memory.

The first systematic solutions were data structures. Arrays assigned each item to a fixed slot in memory, like numbered positions in a filing cabinet — quick to access but inflexible. Linked lists, by contrast, let each record point to the next, forming a chain that could grow or shrink as needed. Together, they gave programmers reliable ways to store and retrieve data on machines with limited resources.

Processing required algorithms — step-by-step procedures for sorting, searching, or merging records. A payroll system, for example, depended on routines to alphabetize employees or locate specific names. These instructions were hard-coded in assembly or other low-level languages, demanding technical skill to write and maintain.

Later, thinkers such as Donald Knuth and Niklaus Wirth codified these ideas in textbooks and programming languages, ensuring that structures and algorithms became the foundation of computer science education and practice.

After serving as a WWII pilot, Edgar F. Codd returned to Oxford for a mathematics degree and later joined IBM in the U.S. In the 1960s, he developed software for the IBM 7090 mainframe — systems deeply tied to physical data structures. At IBM’s research lab in San Jose, California, he advanced a new idea: databases should represent information using only data values, not pointers, hierarchies, or physical record order.

IBM San Jose Research Lab, Building 25, designed by John Savage Bolles (1958). Photograph by Arnold Del Carlo. Codd developed the relational model here, in a hub of exploratory research at IBM. Source: Smith-Layton Archives at the Sourisseau Academy for State and Local History, San Jose State University

His 1970 paper, A Relational Model of Data for Large Shared Data Banks, introduced the concept of data independence — separating logical data relationships from how data is physically stored. This allowed users to pose declarative queries without understanding the internal structure. It laid the foundation for SQL and shifted database design from hardware-bound logic to abstract, high-level models.

Although the mathematical style puzzled many readers — even IBM engineers admitted they “couldn’t make heads or tails” of it — the paper defined a new direction for database research. In 1981, Codd received the Turing Award for this contribution.

Codd’s work on the relational model was rooted in IBM’s dramatic hardware evolution. In the early 1960s, he worked with the IBM 7090, a transistorized mainframe widely used for scientific and business computing. Bulky by today’s standards, it nonetheless laid the groundwork for systematizing data operations.

A meteorologist at the console of the IBM 7090 electronic computer in the Joint Numerical Weather Prediction Unit, U.S. Weather Bureau (c. 1965). The 7090 underpinned early business computing and formed part of Codd’s working environment. Source: National Oceanic and Atmospheric Administration

By the late 1960s, IBM introduced the System/360, a platform that unified architectures for business and scientific applications. Its design brought direct-access storage devices (DASDs) — a crucial step toward random-access data retrieval and, eventually, relational systems.

Page with mainframe console image from the IBM System/360 sales brochure (1964). The 360 symbolized scalable computing — groundwork for relational systems in business. Source: Computer History Museum

Codd’s vision explicitly abstracted away hardware dependence, promoting logical organization over machine constraints.

In the mid-1970s, the Multics Relational Data Store (MRDS) became the first commercial implementation of Codd’s relational model. At Honeywell’s Phoenix facility, Jim Weeldreyer and Oris Friesen led its development, drawing on Codd’s theoretical framework while working in parallel with early relational projects such as IBM’s System R and Berkeley’s Ingres.

Midtown Phoenix, Arizona (1970s). Honeywell’s Phoenix facility developed MRDS here, an early hub of relational database innovation. Source: Rogue Columnist

Running on the secure, time-sharing Multics operating system, MRDS took advantage of virtual memory and was written in PL/1. Its design allowed users to access and manipulate structured data using high-level relational commands. In 1976, Honeywell marketed MRDS as part of the Multics Data Base Manager (MDBM), which also included a CODASYL-style layer.

Diagram from the MRDS Manual (1981), showing the Relational Data Source Model — one of the first real-world implementations of relational principles for structured business data. Source: Bitsavers

By the mid-1970s, IBM’s San Jose Research Lab launched a bold experiment: could Codd’s abstract relational model actually work in practice? The answer was System R, a prototype designed to show that a relational database could offer full production functionality without sacrificing performance.

The project began in 1974, led by Don Chamberlin, Ray Boyce, Irv Traiger, and Morton Astrahan — though Codd himself watched it from the side. Chamberlin later remarked, “He really didn’t get involved in the nuts and bolts of System R very much. I think he may have wanted to maintain a certain distance from it in case we didn’t get it right. Which I think he would probably say we didn’t.”

San Jose City Lines bus, GM “Old Look” (early 1970s). IBM engineers commuted past a city in rapid urban transformation. Source

System R unfolded in stages. Phase Zero tested the feasibility of a relational language — SEQUEL (later SQL) — using early prototypes. By 1976, the team had demonstrated SQL’s potential to make databases accessible to non-programmers. Internally, the project split into two groups: the Relational Data System (RDS) focused on language and query logic, while the Research Storage System (RSS) tackled data handling, transactions, and concurrency.

System R was both a proof of concept and a development engine: it validated that a declarative approach to data could scale and laid the groundwork for a new generation of commercial database products.

Cover of the pulp novel The Penetrator #30: Computer Kill (1980) by Lionel Derrick (Chet Cunningham). The story follows a rogue engineer sabotaging banking systems through computers. Published as relational databases entered commercial use, it reflects how data systems were already imagined as both infrastructure and threat. Source: Biblio

In the late 1970s, IBM partnered with real-world users to validate the relational model’s performance in live environments. The first major test came in 1977, when Pratt & Whitney, a jet engine manufacturer, used System R to manage parts and inventory.

Pratt & Whitney Aircraft duct burner (1979). System R tracked fine-grained logistics during jet engine assembly, ensuring no parts were left behind. Source: NASA / Glenn Research Center Collection

Shortly after, Upjohn Pharmaceuticals deployed it to track clinical research data for FDA applications. While these early adopters didn’t leverage features like concurrency, locking, or transactions to their fullest, they proved relational systems could serve serious industrial use cases.

Upjohn compensation formula table (late 1970s). The company stored experimental data in System R during clinical trials. Source: Corporate archival material

Among the growing pains IBM engineers faced was the “Halloween Problem,” discovered on October 31, 1976. Updates to a table could cause rows to re-enter a scan and be modified repeatedly — a quirk that haunted the SQL optimizer until engineers redesigned update handling. Despite these challenges, the project’s success was undeniable: it laid the groundwork for SQL/DS (1981) and the launch of IBM DB2.

IBM prepared SQL for enterprise deployment with SQL/DS (announced in 1981) and DB2 (released in 1983), adapting relational concepts for large-scale business use.

Meanwhile, Oracle — founded by Larry Ellison, Bob Miner, and Ed Oates — seized the opportunity to commercialize relational ideas. Its second release, Oracle V2 in 1979, was the first SQL-based RDBMS available on the market. Built not on IBM’s source code but on published research about System R, it proved that relational design could be replicated and sold outside the labs.

Oracle 4.1 start screen, restored on DOS by Carel Jan Engel and Marco Gralike (2005) — a glimpse of how early SQL-based systems appeared to users. Source

SQL also gained traction in universities, where it was integrated into teaching tools and research systems. Students and researchers learned to write short, declarative statements — a style of interaction that began to define how users expected databases to work.

In 1986, the American National Standards Institute (ANSI) ratified SQL as the official database language, followed by the International Organization for Standardization (ISO) in 1987. This recognition established SQL as a common interface across vendors and platforms, fixing its role at the core of relational computing.

Federal Information Processing Standards Publication (1986), establishing SQL as a database language. Issued by the U.S. National Bureau of Standards. Source

The first standards, SQL-86 and SQL-89, defined a common core for queries. SQL-92 expanded the scope with features like outer joins, richer data types, and stricter rules of syntax. Later editions — SQL:1999, 2003, and beyond — layered in recursion, triggers, procedural logic, and eventually XML and JSON support, turning SQL into a full-fledged data manipulation language.

The drive toward standardization combined technical aims with commercial strategy. Vendors like IBM, Oracle, and Sybase backed SQL to ease adoption and reduce customer lock-in, even while promoting their own proprietary extensions. Academic systems and open-source projects followed the same path, ensuring that generations of developers learned SQL as a shared skill.

Critics — including Chris Date, one of Codd’s closest collaborators and most influential educators — argued that SQL strayed from relational purity. Yet its adoption was unstoppable: SQL became the de facto language of enterprise computing, not because it was flawless but because it was everywhere.

In June 1976, Honeywell introduced the Multics Relational Data Store (MRDS), the first relational database management system released by a major vendor. Built directly into the Multics operating system, MRDS let users query data through relational algebra and predicate calculus. It coexisted with the Multics Integrated Data Store (MIDS), a hierarchical model, giving organizations a rare choice between competing paradigms.

System control panel for Honeywell 6000 series mainframes, the hardware platform supporting MRDS (1980s). Source

Multics’ design emphasized security and multi-user access, qualities that MRDS inherited. Although its reach was limited by Honeywell’s less common Series 60/Level 68 hardware, MRDS showed that relational concepts could be implemented as part of a commercial product.

Frisbee from a Multics company picnic (1968–1980) — a glimpse of the community around Honeywell’s computing projects. Source: Biblio

Computerworld coverage of Honeywell’s MRDS launch (September 1976) — part of Honeywell’s high-profile global rollout and among the first commercial ads for a relational DBMS. Source: Google Books

Oracle’s rise was built on portability. While IBM’s System R prototypes required expensive mainframes and internal resources, Oracle targeted smaller markets with a database that could run on minicomputers. Its first releases operated in just 128KB on Digital’s PDP-11 — a radical step toward affordable, portable relational systems.

Control panel of the PDP-11 minicomputer, the platform for Oracle’s first relational database (c. 1976). Oracle’s engine ran in just 128KB on this compact hardware, contrasting with IBM’s mainframes. Photograph by Frank da Cruz. Source: Columbia University

A key milestone came with Oracle Version 3, when the system was rewritten in the C programming language. That decision, pushed internally by Bruce Scott, freed Oracle from hardware dependence and made it runnable across PDP systems, UNIX workstations, and eventually personal computers.

This emphasis on portability became Oracle’s competitive edge. At a time when most databases were tightly bound to specific machines, Oracle’s strategy favored reach over raw optimization, laying the groundwork for cross-platform dominance in the relational market.

INGRES stood apart from IBM’s System R and Oracle’s early products. Developed at UC Berkeley by Michael Stonebraker and his team, it served as both a research platform and a teaching tool, making relational databases accessible to students and researchers worldwide. Its open, experimental character contrasted with IBM’s tightly controlled prototypes and Oracle’s aggressive commercial push.

Commercials from magazines

Advertisements for INGRES in computer trade magazines (early 1980s) — positioning the Berkeley spinoff as a challenger to IBM’s slower-moving offerings. Source: Archive.org

Advertisements for INGRES in computer trade magazines (early 1980s) — positioning the Berkeley spinoff as a challenger to IBM’s slower-moving offerings. Source: Archive.org

Advertisements for INGRES in computer trade magazines (early 1980s) — positioning the Berkeley spinoff as a challenger to IBM’s slower-moving offerings. Source: Archive.org

Humorous video advertisement of Ingres. 1980s

In 1980, the team launched Relational Technology Inc., one of the first startups devoted to database software. INGRES’s portability and academic credibility gave it traction in universities and midsize businesses, where it offered a credible alternative to proprietary systems. It showed that relational software could grow not only through corporate channels but also through academic networks that seeded talent, tools, and ideas across the industry.

As relational databases spread into real-world use, they needed to fit into existing software ecosystems. That meant bridging SQL — a high-level, declarative query language — with the low-level power of system programming. In the 1970s and early 1980s, that meant C.

Ken Thompson and Dennis Ritchie at Bell Labs (1970s–1980s). Their creation of C provided the foundation for operating systems and database engines alike. Source: Computer History Museum

Originally developed at Bell Labs for UNIX, C became the language of choice for operating systems and high-performance applications. Its portability, memory control, and ability to interface directly with hardware made it ideal for embedding database engines like Oracle and INGRES. Oracle’s shift from assembly to C allowed the database to scale across platforms, from PDP-11s to minicomputers and eventually PCs.

Developers also needed ways to issue SQL queries from within C programs, leading to embedded SQL, APIs, and eventually standards like ODBC. This coupling between SQL and C defined a generation of software design, intertwining business logic with database access at the code level.

The power of the relational model lay in how it connected data. Each row in a table carried a “primary key” — a customer ID, invoice number, or another unique marker. “Foreign keys” pointed from one table to another’s primary key, weaving relationships: an order tied to a customer, a payment linked to an invoice, a student mapped to a course.

PDP-11 brochure cover (1970). Relational concepts such as keys were applied to data managed on systems of this era. Source: Computer History Museum

This grammar of keys enabled normalization — reducing duplication and enforcing consistency across sprawling systems. Instead of repeating the same details in every record, databases stored them once and referenced them wherever needed. Codd’s abstract theory of relations thus became a practical framework for structuring business processes, research datasets, and institutional records.

Computer studies in Norway began in the 1950s within military research. Physicist Jan V. Garwick introduced digital methods at the national Defense Research Establishment, where Ole-Johan Dahl and Kristen Nygaard later collaborated on modeling complex systems such as bank queues and shared resources.

Collaboration with Manchester delivered Norway’s first Mercury computer in 1957, and by the early 1960s the Norwegian Computing Center in Oslo became a hub for their work.

Oslo Town Hall (1956). Ole-Johan Dahl first attended NDRE computing sessions here, where Norway’s defense establishment introduced digital methods to researchers. Source: DigitaltMuseum

Their language, Simula I (1965) and its successor Simula 67, introduced the concept of objects: program units with identity, data, and behavior. Conceived as tools for simulation, they established principles that would shape later programming.

Ole-Johan Dahl and Kristen Nygaard. Their collaboration at the Norwegian Computing Center produced Simula I and Simula 67, the first object-oriented languages. Source: History-Computer

Computer scientist Georg Philippot, recalling his time teaching Simula on a CDC 3300, described ending a course with a program that played Chopin’s funeral march as the machine was retired — a symbolic farewell to early computation and the beginning of a new paradigm.

CDC 3300 terminal at the computing center in Berlin. Machines like this hosted Simula courses. Source

Object-oriented programming (OOP) structures software around objects — units that combine data (attributes) with behavior (methods). Each object belongs to a class, which defines its properties and capabilities.

Classes can inherit traits from other classes, allowing shared logic while supporting specialization. A “Vehicle” class, for example, can define rules common to all transport, while “Car” and “Bike” extend it with their own features.

The Simula logo, created in Oslo during the 1960s. Simula introduced the concept of objects and became the first object-oriented programming language. Source

Objects interact by sending messages that invoke behavior, making systems evolve through encapsulation and modular design. Originally built for simulation, OOP soon became a general programming paradigm. It underpins most modern software design, from operating systems and business platforms to mobile apps and video games.

At Xerox PARC in the early 1970s, Alan Kay and his team drew on Simula, Sketchpad, and LISP to design Smalltalk — a system where everything was an object, from numbers to windows. It introduced dynamic class creation, inheritance, and a live graphical interface, offering an integrated environment rather than a standalone language.

Alan Kay at PARC. His background in music shaped his vision of software as modular, interactive, and improvisational — ideas that guided the creation of Smalltalk in the 1970s. Source: CyborgAnthropology

Cover of Smalltalk-80: The Language (1989) by Adele Goldberg. As part of the Xerox PARC team, she co-developed Smalltalk and advanced key object-oriented concepts that later influenced mainstream programming. Source: Amazon

While commercially limited, Smalltalk’s ideas shaped the next generation of programming. In the 1980s, C++ extended the C language with classes, bringing object orientation into mainstream engineering. By the 1990s, Java simplified object-based design for the web era, and Microsoft’s C# followed with a hybrid model for enterprise software.

Object orientation reshaped runtime environments by modeling programs as systems of interacting entities. Instead of treating code as a single flow of instructions, it allowed multiple objects to act in parallel, each maintaining its own state and responding to events.

This approach, first explored in Simula’s simulations and then applied to visual interfaces, soon shaped interactive software more broadly. Early computer games became laboratories for object-oriented thinking, where complex behavior emerged from collections of autonomous agents rather than centralized scripts.

SimCity (1989). Buildings and services function as autonomous objects, with the city emerging from their interaction and responses to changing conditions. Source

Lemmings (1991). Each lemming follows its own rules. Gameplay comes from coordinating a swarm of reactive objects through a shifting environment. Source

Little Computer People (1985). A simulated household built from objects. Behavior arises not from direct scripts but from the state and affordances of items in the environment. Source

As applications grew more complex — in areas such as computer-aided design, multimedia, and geographic information systems — relational databases revealed their limits. Flat tables and joins could not easily handle nested structures, versioning, or user-defined behaviors.

The solution proposed in the mid-1980s was the object-oriented database management system (OODBMS). In these systems, data entries were full objects with identity, structure, and behavior, often linked in complex hierarchies. Methods as well as attributes could persist, narrowing the gap between code and storage.

Early projects such as GemStone (built on Smalltalk) and Orion (written in Common Lisp) attempted this fusion of programming environments with persistent storage. They illustrated both the appeal and the difficulty of merging two paradigms that had evolved separately.

Interface from GemStone/S 2.5. This object-oriented database merged Smalltalk’s class structures with persistent storage, demonstrating how OOP principles were applied to data management. Source: The GemStone Object Database Management System, p. 68

Object-oriented databases promised to eliminate the “impedance mismatch” between code and storage. By treating data entries as objects, they seemed to offer a natural fit for CAD, multimedia, and simulation systems that demanded complex hierarchies and evolving relationships.

CAD design of a Stihl chainsaw (1980s). Applications like CAD demanded hierarchies and versioning that relational systems struggled to handle. Source: Finnish Forest Museum Lusto; Metsähallituksen collection.

Readings in Object-Oriented Database Systems (1990), edited by Zdonik and Maier. This collection captured the momentum of OODBMS research — and the fragmentation that limited its adoption. Source: Google Books

Yet commercial adoption in the 1980s-90s faltered. Each platform tied objects to specific programming languages, and without a common query language like SQL, systems could not work well together. Schema changes were fragile, administrative tools were underdeveloped, and relational vendors kept improving performance and reliability, widening the gap.

Though most OODBMS products faded, their ideas persisted. Object-relational mapping frameworks like Hibernate and ActiveRecord reintroduced the concept at the application layer, while NoSQL systems such as MongoDB revived nested structures and flexible schemas. Even modern SQL engines now support complex types and JSON, echoing features pioneered by OODBMS.

Eusebian canon tables from the Gospels, Armenian manuscript (12th century CE). A Christian adaptation of Hellenistic cross-referencing, these tables represent an early method for structuring complex information. Walters Manuscript W.538, fol. 10v. Source: The Walters Art Museum

Medieval Islamic scholars refined astronomical and mathematical tables, using them to convey empirical and calculated data. In Western Europe, tables were employed for liturgical purposes such as computing the Easter date, exemplified by Dionysius Exiguus's calendrical system in 532 CE.

By the 17th century, printed tables circulated widely, covering subjects from demographic counts to planetary motion, and provided a standardized format for organizing and comparing information.

Throughout the 19^th century, the integration of mathematical methods into economics began to reshape data interpretation, despite resistance from traditional theorists. Many early modelers — including engineers like Charles Ellet and Jules Dupuit — introduced diagrams and curves to represent trade, cost, and flow.

Henry Higgs, “Some Remarks on Consumption,” in the Economic Journal (December 1899). Illustrates how qualitative analysis and verbal reasoning still dominated economic theory at the turn of the century, while mathematical modeling remained rare. JSTOR

Alfred Marshall’s graphical models (1870s–1890s), p. 67. Early use of curves to represent economic forces such as supply and demand, helping to formalize economics as a mathematical science. EE-T Portal

Their attempts to visualize economic behavior were seen as marginal at first. As late as 1892, 95% of articles in the top four economics journals used neither mathematical notation nor graphs (Stigler and Friedland, The Journals of Economics).

Still, this shift was underway. By the 1870s, Alfred Marshall brought graphical modeling into the mainstream, using intersecting curves to depict market mechanisms. These visualizations made abstract theory accessible and policy-relevant — a foundational turn toward data-driven economic reasoning.

The Jacquard loom created a radically new workflow of design abstraction. The key step was the mise en carte: transposing a textile pattern into an enlarged grid (rule-paper), where each square represented a thread action. From this intermediate visualization, specialized workers could generate punched cards — the program — detached from the weaver and readable by the machine.

Jacquard engine attached to a carpet loom (c. 1840). From Toshio Kasamitsu’s doctoral dissertation, 1982, p. 52. Source

In 1835, French machine maker C. Guillotte described this logic-to-fabric pipeline before a British committee. His testimony revealed an early encounter with the formalization of instructions. Design was now “read in,” parsed into discrete mechanical steps, and stored in physical memory.

This early modularization of creative labor—design, translation, encoding—foreshadowed modern digital interfaces and data visualization. Long before computers, workers were debugging logic patterns and offloading execution to automated systems, mediated through symbolic encodings on physical media.

After the success of the 1890 U.S. Census, punched card machines quickly became a pillar of state and corporate infrastructure. Already in 1891, governments in Canada, Norway, and Austria had adopted versions of punch-card tabulators for their own censuses.

Then, Hollerith’s systems — now under the Computing-Tabulating-Recording Company (CTR), which later became IBM — expanded from population counts to civil registries, tax records, military logistics, and industrial payroll.

Hollerith’s U.S. patents (Nos. 395,781–783, 1889), collectively describing his invention as the “Art of Compiling Statistics.” Google Patents

Herman Hollerith with his punch-card tabulating machine, used in the 1890 U.S. Census. Transcription required 72.5 hours (twice as fast as competitors), while tabulation took only 5.5 hours (ten times faster). MIT Technology Review

Scientific American, August 1890, featuring Hollerith’s census machine. From the collection of Dr. Sid Kolpas. Mathematical Association of America

In Europe, punched card tabulators were used to track unemployment during the Weimar Republic and later for darker purposes under totalitarian regimes. In the U.S., corporations adopted the technology to manage workers and inventories. Punched cards became tokens of identity: each card a fragile stand-in for a worker, a file, a life — processed at scale.

Their layout became standardized: 80 columns, rectangular holes, precise rows. What began as a statistical tool evolved into a universal format for encoding human activity. This expansion paved the way for mainframe computing, but it also quietly embedded new logics of sorting, surveillance, and abstraction — long before digital systems arrived.

Enumeration isn't just about counting — it's about how categories get visualized and fixed. In the 17th and 18th centuries, European administrations relied on increasingly tabular formats: not simply ledgers of names and taxes, but forms that pre-structured reality into discrete fields, rows, and groupings.

Parish register page (England, 17th–18th c.), with neatly ruled columns for baptisms, marriages, and burials. By reducing lived events to standardized entries, these registers transformed experience into categories. North Yorkshire Archive Blog

André-Michel Guerry’s “Instruction” map of France (1833), showing literacy rates by département with color shading. The map enforced classification and comparison within spatial and categorical constraints. ResearchGate

These documents forced complexity into grids. “Head of household,” “acreage owned,” “occupation,” or “tribe” became checkboxes. In colonies and empires, local identities were reshaped into legible categories that fit bureaucratic templates — erasing nuance in favor of scale and control.

This transition marked a foundational step toward modern data representation.

Mathematical methods pushed economic data beyond counts and inventories. But the abstraction came with choices: what to count, what to ignore, and how to draw a system where labor and material resistance disappeared.

This was no longer about describing society, but simulating it. Graphs of cost and output treated work as a function, not a force. The body vanished. Diagrams circulated through ministries and lecture halls, presenting a world of perfect inputs and optimized exchange.

Lancashire power loom from Richard Cotton Marsden’s “Weaving: Its Development, Principles, and Practice” (1895). English looms like this dramatically increased textile productivity while displacing skilled handweavers across the countryside. Source

Luddite resistance, engraving by unknown author (early 19th century). The uprisings of the 1810s were less a rejection of technology than a revolt against the erosion of skill, autonomy, and fair wages under early factory regimes. Smithsonian Magazine

In this shift, the loom returned — not as a machine, but as a metaphor. Economic modeling borrowed its logic: patterns encoded, complexity reduced, skill displaced. And just as mechanical looms once triggered uprisings among artisans, this new epistemic loom — operated by economists — restructured the world with invisible consequences.

While Herman Hollerith’s punch-card systems became the foundation of administrative computing, other thinkers explored more physical metaphors for modeling economic systems. In 1891, economist Irving Fisher built a hydraulic machine to simulate general equilibrium using interconnected tubes and flowing water. By adjusting valves and fluid levels, users could visualize supply, demand, and price dynamics across markets.

This idea didn’t end there. In 1949, Bill Phillips, a New Zealand economist and engineer, built the MONIAC — a larger hydraulic computer that modeled national income flows, taxes, investments, and savings using colored water in tanks and pipes. It became a teaching and policy tool, particularly in postwar Britain.

Irving Fisher’s hydraulic machine (1891). A pioneering attempt to simulate market equilibrium, using water to model flows of supply and demand. Conversable Economist

The MONIAC, built by Bill Phillips (1949). An analog computer using tanks and pumps to demonstrate Keynesian economics. Conversable Economist

These analog machines never reached administrative scale. But they represented an alternative path: computation through embodied simulation rather than abstraction. Their legacy is conceptual — a reminder that the urge to visualize systems long predated digital spreadsheets, and that data modeling once flowed, quite literally, through pipes.

Before numerical models dominated, knowledge was often conveyed through images. Scientific illustrations meant more than decoration — they were essential tools for observation, measurement, and communication. In the Renaissance, artists like Brunelleschi and Piero della Francesca systematized linear perspective, providing a new framework for visual reasoning.

Geometrical drawing of an icosahedron inside a cube by Piero della Francesca, from “De quinque corporibus regularibus” (c. 1460). This study shaped post-Medieval fine arts and influenced the early development of data visualization techniques. Source

Geometrical drawing of an icosahedron inside a cube by Piero della Francesca, from “De quinque corporibus regularibus” (c. 1460). This study shaped post-Medieval fine arts and influenced the early development of data visualization techniques. Source

“Melencolia I,” engraving by Albrecht Dürer (1514). Source: Metropolitan Museum

In the late 15^th century, printed science texts such as Euclid's Elements (Erhard Ratdolt, 1482) integrated geometrical diagrams alongside mathematical logic, shaping how abstract concepts were understood. Johannes de Sacrobosco's astronomical works used diagrams to explain celestial mechanics, providing a visual means of understanding complex, invisible systems.

By the 16^th century, Albrecht Dürer combined anatomical precision with proportional geometry, exemplified in his Four Books on Human Proportions. These illustrations went beyond artistic representation, offering a form of visual argumentation that influenced both scientific reasoning.

As statistical thinking matured, so did methods to visualize it. By the 17^th century, England’s Bills of Mortality were not only collected but interpreted. John Graunt’s 1662 analysis offered early demographic insights, tracking plague deaths and life expectancy. A few decades later, Edmund Halley’s mortality tables laid the foundation for actuarial science.

In the 19^th century, the use of charts and graphs became more systematic. William Playfair’s bar and pie charts helped represent trade balances and budgets. In the U.S., business statisticians embraced infographics to guide decision-making.

Illustration from Willard Brinton’s “Graphic Methods for Presenting Facts” (1914), using the octopus metaphor to depict the complexity and interconnectedness of data. Source: Archive.org

Willard Brinton’s Graphic Methods for Presenting Facts (1914) emphasized that clear representation could shape executive understanding. His manual ranged from simplified charts to complex 3D diagrams, promoting visuals as practical tools for business and government.

In 1890, Herman Hollerith demonstrated his punch card tabulator to the Actuarial Society of America, marking a pivotal moment in the adoption of data-driven decision-making in business. Insurance companies like Prudential quickly saw the potential and adopted the system to streamline claims processing, though some actuaries, including John K. Gore, developed faster alternatives to Hollerith’s machines.

By 1910, Hollerith’s tabulator was being used by British railways to monitor costs and revenue per locomotive, linking granular data to profit margins. As Hollerith’s company evolved into IBM, the technology spread into European transportation networks — in 1928, Ferrovie dello Stato in Italy began using IBM equipment to manage train schedules and spare parts.

Postcard of Earby Station (Edwardian England, 1905). Source

Electric train ETR200 of the Italian State Railways (mid-1930s), connecting Milan and Torino, where precise scheduling was critical. Source

In 1945, Vannevar Bush envisioned the Memex, a desk-sized device designed to help users link and retrieve vast amounts of information. Users could create personalized trails connecting photos, notes, and documents, anticipating modern hypertext.

Sketch from Vannevar Bush’s article “As We May Think,” republished in ACM SIGPC Notes (1979). Worrydream

Though never built, the Memex influenced the development of interactive data systems and user interfaces, bridging business data with human memory and creativity. It foreshadowed the personal computer and the idea of navigating data as a cognitive tool, not only storing facts.

UNIVAC central panel, used by operators to control programs and monitor machine status through switches and indicator lights. Photo by Don DeBold. Source

The UNIVAC I (Universal Automatic Computer I), introduced in 1951, was the first digital computer designed for commercial use in the United States. It was a room-sized system powered by thousands of vacuum tubes, using magnetic tape drives along with punch cards. UNIVAC could execute approximately 1,905 operations per second, and it employed mercury delay line memory capable of storing 1,000 words of 12 characters each.

This hardware allowed UNIVAC to handle both numeric and alphabetic data at unprecedented speeds for its time. It was programmable, universal in purpose, and significantly outpaced earlier mechanical and electromechanical systems.

The machine sold for between $1.25 and $1.5 million, which limited its potential to spread across industries. But its cultural impact was such that it quickly became a symbol of the new era of machine-powered thinking.

UNIVAC entered public consciousness in 1952, when CBS used it to predict the outcome of the U.S. presidential election. The machine signaled Eisenhower’s victory hours before most commentators were willing to commit, turning a broadcast into a national spectacle. For many Americans, this was the first moment a computer appeared as an authority, its output treated as a credible forecast rather than a technical curiosity.

UNIVAC advertisement from “Time” magazine (1967). Source: Poshmark

The UNIVAC name soon spread beyond the machine itself — borrowed in fiction, headlines, and advertising. Its visual form became equally iconic: glowing panels, magnetic tape reels, blinking lights. These elements circulated in media and corporate branding, establishing a recognizable aesthetic of computation in the 1950s and 1960s.

While UNIVAC made waves in the U.S., the UK had its own breakthrough in 1951: the Ferranti Mark I, derived from the Manchester Mark I project at the University of Manchester. It holds the distinction of being the first commercially available stored-program digital computer — predating UNIVAC by a few months. While primarily delivered to research institutions, it marked the beginning of programmable computing as a product.

The machine was designed to process 20-bit words, with a memory architecture that included vacuum tube storage (each tube holding 64 words) and a magnetic drum with capacity for 512 pages. It sold for between £50,000 and £100,000, and crucially, was made available beyond the confines of academia or government labs.

Alan Turing (right) with the Ferranti Mark I, 1952 — the only known photograph of Turing with a computer. The image appeared on the front cover of Ferranti’s Mark I brochure. Source: Science Museum Group Collection © The Board of Trustees of the Science Museum

The Ferranti Mark I supported a wide range of programs, from business analytics and scientific modeling to experimental computer music and some of the first computer games. Its stored-program design — the ability to modify instructions directly in memory — allowed far more complex data manipulation than earlier fixed-instruction machines.

To make “information inventory” usable, designers emphasized indexing and navigation: maps and keys were imagined as ways to move through an ocean of records.

The urgency of integration grew as industrial systems became more complex: NASA’s Apollo program, for instance, involved millions of components, while military logistics had already outgrown manual handling.

Dow Chemical advertisement, Fortune magazine, October 1963. A two-page spread contrasted IBM’s 7070 punch-card system (“Our model 7070 — It figures.”) with a Dow salesman’s ID badge (“Our model 506713 — He thinks.”), promoting human expertise over machine analysis. Source: Science History Institute

Dow Chemical advertisement, Fortune magazine, October 1963. A two-page spread contrasted IBM’s 7070 punch-card system (“Our model 7070 — It figures.”) with a Dow salesman’s ID badge (“Our model 506713 — He thinks.”), promoting human expertise over machine analysis. Source: Science History Institute

At Dow Chemical and later at General Electric, Charles Bachman faced the limits of separate departmental files. Dow’s early attempts at integration never took hold, but he carried forward the vision of shared, navigable data that could link records across the entire company.

At General Electric in the early 1960s, Charles Bachman led the development of the Integrated Data Store (IDS) — one of the earliest database management systems. IDS introduced the concept of an information inventory: a centralized, disk-based repository of shared records that could be queried and updated by multiple applications.

Walt Disney with GE president Gerald L. Phillipe at the Progressland Pavilion, New York World’s Fair (1964). Source: Smithsonian Institution Archives

This architecture enforced relationships between records — what would later be called the network data model. IDS supported a data dictionary to track record structures and allowed programmers to retrieve or update data using early forms of a data manipulation language.

IDS ran on the GE-225 computer, paired with the MRADS disk system — offering random access to data, rather than the sequential tape storage common at the time. Its first major deployment, MIACS (Manufacturing Information and Control System), provided real-time production control at a GE factory in Philadelphia.

By unifying data storage and enabling shared access, IDS became the prototype for modern database systems. In 1973, Bachman received the Turing Award for this work.

In the early 1960s, two very different machines shaped how organizations approached digital information: the General Electric GE-225 and the IBM 1401.

The GE-225, introduced in 1960, was built for power and flexibility. It featured simultaneous input/output handling, supported both alphabetic and numeric data, and could connect to disk drives like MRADS. Input came from magnetic tape, punched cards, MICR documents, and even paper tape, with long-distance connections supported via the DATANET-15. It was a machine for custom-built systems like real-time data integration.

Meanwhile, the IBM 1401, released in 1959, took the market by storm with its affordability and reliability. Its six-bit character system, magnetic core memory (4K–16K), and decimal arithmetic made it perfect for payroll, billing, and inventory. Leased for around $2,500/month, it brought computing within reach of small and mid-sized businesses — earning the nickname "the Model T of the computer industry."

IBM 1401 computing the results for the city of Kiel, West Germany, during the federal election (1965). Source

Their rivalry wasn’t just about specs — it was about philosophies:

• IBM offered safe, standardized tools for the mainstream.
• GE pushed toward modularity, extensibility, and integration.

The GE-225 later found academic life as well — a time-sharing version at Dartmouth became the birthplace of the BASIC programming language.

In May 1959, over 40 representatives from government, industry, and academia gathered at the Pentagon to address a growing problem: early computer languages were difficult to learn and maintain, limiting business adoption. Their solution was CODASYL — the Conference on Data Systems Languages — a volunteer group aimed at creating a common, English-like programming language for business.

Cover of the FLOW-MATIC programming system manual, developed by Grace Hopper at Remington Rand (1958). Source: Bitsavers

At the time, Grace Hopper’s FLOW-MATIC, developed at Remington Rand UNIVAC, was the only business-oriented language using human-readable commands. Hopper, a pioneering computer scientist and naval officer, had long championed making programming more accessible. The committee, with members from Burroughs, Honeywell, IBM, RCA, Sperry Rand, and Sylvania, drew inspiration from her work.

On December 6, 1960, a live demonstration proved COBOL could compile and run the same code on both UNIVAC and RCA systems — a landmark moment for interoperability.

COBOL wasn’t designed in a vacuum — it was shaped by the constraints and capabilities of the early business computers it was meant to run on. The language was intended for high-volume, data-driven tasks on large systems like the UNIVAC I and II, IBM 705, Honeywell 800, RCA 501, Sylvania MOBIDIC, and Burroughs B-5000.

Grace Hopper speaking in 1982 about running COBOL and FORTRAN on various machines.

These machines varied widely in architecture and I/O capabilities, but COBOL’s standardization effort required them to speak a shared language. This forced a shift in how hardware designers thought about software compatibility, and it catalyzed interest in portable, high-level languages. The 1960 live demonstration of COBOL running on both UNIVAC and RCA systems proved the concept.

Despite Cold War tensions, the Soviet Union closely followed developments in Western data processing — and COBOL did not go unnoticed. In 1965, the Kyiv-based journal Kibernetika published a technical overview of COBOL by Lyudmila Babenko, helping introduce the language to Soviet scientific circles. She later earned a PhD for formalizing COBOL-style data translation methods for mass data processing.

Soviet adaptations emerged rapidly: the Dnipro-2 control system, built in Kyiv, integrated COBOL-like translators designed by Kateryna Yuschenko’s team. Meanwhile, the Minsk-22 computer from Belarus offered its own compiler variant. These efforts reflected a broader drive to align with international standards while maintaining domestic engineering autonomy.

Kateryna Yushchenko, member of Victor Glushkov’s pioneering team in Soviet programming. In 1955 she created the Address programming language, introducing indirect addressing nearly a decade before similar features appeared in Western systems. Source: Yushchenko family archive

The arrival of the ES EVM (Unified System of Electronic Computers), based on IBM System/360, brought COBOL-style programming into the mainstream of Soviet and Eastern Bloc computing. By 1975, COBOL had received an official Soviet standard.

COBOL’s breakthrough was linguistic. Business software could now be written in something resembling natural English, with syntax drawn from everyday office practice. Instead of abstract math or dense assembly, programmers used phrases like MOVE TOTAL TO SUMMARY-TOTAL. This made programs legible to non-programmers and reframed coding as documentation.

Grace Murray Hopper, Rear Admiral and computer pioneer, in her Washington, D.C. office (1978). She often lectured in uniform, using her Navy role to underscore authority in a male-dominated field, though in everyday work she wore civilian clothes. Photograph by Lynn Gilbert. Source

This readability was deliberate. Grace Hopper and the CODASYL committee wanted software to be transparent, teachable, and aligned with how people already communicated. By borrowing vocabulary and structure from business memos and accounting reports, COBOL positioned itself as a mediator between humans and machines.

In the early 1960s, computing began to move beyond producing static reports. Organizations were starting to manage dynamic, shared datasets. The first genuine database management systems (DBMSs) — GE’s IDS (1964) and IBM’s IMS (1965) — were built for disk drives and introduced persistent, structured storage that could be reused across applications.

The concept of a “database” itself came out of Cold War defense projects. In 1962, the System Development Corporation, which had worked on the SAGE air defense network, described shared repositories of information accessible to multiple users and programs — a step beyond archived output.

Airman First Class Trent Bailey, weapons controller technician, with Airman Toni Bailey, a new SAGE surveillance operator, Luke Air Force Base, Arizona (1975). NORAD newsletter archive. Source: Southwest Museum of Engineering,Communications and Computation

By the late 1960s, business computing circles were converging on the same need for consistent storage and retrieval. The CODASYL Data Base Task Group, backed by firms such as RCA and Remington Rand, began formalizing DBMS architecture. Their work intersected with advances in software portability and the push for standard program–data interfaces.

The 1964 Tokyo Olympics posed a monumental data challenge: 7,000 athletes, 100 countries, and up to 25 simultaneous contests across 32 venues. To manage this, IBM Japan deployed a real-time data processing system that transformed event coordination forever.

Data-printing center in the Olympic Village, Tokyo (1964). Source: Official Games Report

Using 62 IBM 1050 terminals across venues, scores were sent to a central Olympic Data Center powered by eight IBM computers. With a disk capacity of 56 million characters, the center processed rankings, judge scores, and registration data for 12,000 participants — within seconds. Over 100,000 messages were expected, with three to four times as many replies sent back.

In the early years of digital computing, businesses faced a fundamental problem: data was everywhere, and nowhere unified. The same customer’s name or address might live in multiple departmental files, each updated (or not) independently. This data redundancy consumed storage and bred inconsistency. A change made in sales might never reach accounting or shipping.

80-column punch card printed at the Tehnoinform facility, Riga, USSR (1976). Source: Tristan Davey’s Punchcard Archive

The emergence of Database Management Systems (DBMS) in the 1960s — such as GE’s IDS and IBM’s IMS — centralized data storage, enabling multiple applications to access the same version of a record.

Centralization also raised the stakes. Errors in one place could propagate everywhere, making data integrity critical: records had to be valid, correct, and complete. Fields were expected to follow strict rules — for example, prices had to be numeric and dates had to conform to valid calendar values. As data became more valuable, concerns about security also grew.

Before the rise of graphical interfaces and data dashboards, businesses made sense of information through structured printouts — organized columns of numbers, names, and dates. This was the world of reporting and tabulation, where value lay in turning raw machine data into readable summaries.

Brochure page for the Portable Addressograph, Addressograph-Multigraph Corp. (1950s). Source: Internet Archive

Computing’s main output in this era was text, and layouts were built with typewriters and line printers. Custom-coded routines used spacing and symbols, inserted headers, pagination, totals, and alignment, giving readers a way to scan, compare, and analyze continuous-form paper visually.

Draftsmen working on a blade template drawing at a large table (1953). Source: NASA/Glenn Research Center collection

Even without graphics, sales reports, inventory sheets, and payroll summaries transformed raw bits into managerial knowledge. The software behind these outputs became precursors to later business intelligence tools.

While interfaces determined how people spoke to machines, the machines themselves needed internal structures to manage information once it was loaded. Early programmers discovered that efficiency depended not only on commands, but on how data was arranged in memory.

The first systematic solutions were data structures. Arrays assigned each item to a fixed slot in memory, like numbered positions in a filing cabinet — quick to access but inflexible. Linked lists, by contrast, let each record point to the next, forming a chain that could grow or shrink as needed. Together, they gave programmers reliable ways to store and retrieve data on machines with limited resources.

Processing required algorithms — step-by-step procedures for sorting, searching, or merging records. A payroll system, for example, depended on routines to alphabetize employees or locate specific names. These instructions were hard-coded in assembly or other low-level languages, demanding technical skill to write and maintain.

Later, thinkers such as Donald Knuth and Niklaus Wirth codified these ideas in textbooks and programming languages, ensuring that structures and algorithms became the foundation of computer science education and practice.

After serving as a WWII pilot, Edgar F. Codd returned to Oxford for a mathematics degree and later joined IBM in the U.S. In the 1960s, he developed software for the IBM 7090 mainframe — systems deeply tied to physical data structures. At IBM’s research lab in San Jose, California, he advanced a new idea: databases should represent information using only data values, not pointers, hierarchies, or physical record order.

His 1970 paper, A Relational Model of Data for Large Shared Data Banks, introduced the concept of data independence — separating logical data relationships from how data is physically stored. This allowed users to pose declarative queries without understanding the internal structure. It laid the foundation for SQL and shifted database design from hardware-bound logic to abstract, high-level models.

Although the mathematical style puzzled many readers — even IBM engineers admitted they “couldn’t make heads or tails” of it — the paper defined a new direction for database research. In 1981, Codd received the Turing Award for this contribution.

As vendors rushed to sell products branded “relational,” Edgar Codd intervened to separate marketing claims from architecture. In two Computerworld articles (October 14 and 21), he introduced a framework for judging whether a system truly followed relational principles.

Herald Square elevated railroad and Sixth Avenue with R.H. Macy & Company department store in the background, New York (c. 1910s–1930s; published 1949). After emigrating from England, Edgar F. Codd briefly worked in Macy’s men’s department before turning to computing; within two decades he introduced the relational model and later received the Turing Award for it. Source: Library of Congress, Prints & Photographs Division, Detroit Publishing Company Collection

Codd’s 12 rules — actually 13, counting Rule Zero — outlined what a genuine relational database must provide. Rule Zero required that a DBMS manage data strictly through relational methods, not as a façade over hierarchical or network systems. The remaining rules specified fundamentals such as data independence, accessible metadata, set-based operations, and logical consistency.

One practical rule emphasized multiple-record-at-a-time processing: a single command should update entire sets — raising all prices by 10% or changing every Polish address to “Warsaw, Poland.” This stood in contrast to earlier one-record-at-a-time approaches.

By the mid-1970s, IBM’s San Jose Research Lab launched a bold experiment: could Codd’s abstract relational model actually work in practice? The answer was System R, a prototype designed to show that a relational database could offer full production functionality without sacrificing performance.

The project began in 1974, led by Don Chamberlin, Ray Boyce, Irv Traiger, and Morton Astrahan — though Codd himself watched it from the side. Chamberlin later remarked, “He really didn’t get involved in the nuts and bolts of System R very much. I think he may have wanted to maintain a certain distance from it in case we didn’t get it right. Which I think he would probably say we didn’t.”

San Jose City Lines bus, GM “Old Look” (early 1970s). IBM engineers commuted past a city in rapid urban transformation. Source

System R unfolded in stages. Phase Zero tested the feasibility of a relational language — SEQUEL (later SQL) — using early prototypes. By 1976, the team had demonstrated SQL’s potential to make databases accessible to non-programmers. Internally, the project split into two groups: the Relational Data System (RDS) focused on language and query logic, while the Research Storage System (RSS) tackled data handling, transactions, and concurrency.

System R was both a proof of concept and a development engine: it validated that a declarative approach to data could scale and laid the groundwork for a new generation of commercial database products.

Cover of the pulp novel The Penetrator #30: Computer Kill (1980) by Lionel Derrick (Chet Cunningham). The story follows a rogue engineer sabotaging banking systems through computers. Published as relational databases entered commercial use, it reflects how data systems were already imagined as both infrastructure and threat. Source: Biblio

System R’s developers left behind stories that were as colorful as their code. Don Chamberlin recalled a memorable visit to Upjohn Pharmaceuticals in Kalamazoo, Michigan — where the team had installed System R to manage clinical research data. Their hosts lodged them in a Victorian mansion with tandem bikes and a full liquor wall: “We asked if we could take home anything we didn’t drink.”

Company sign spotted by System R engineers during a tour of the vitamin production line (late 1980s). Source: Upjohn

Beyond these surreal moments, IBM tested System R in diverse settings: attack helicopter design at Owego, GUI prototypes at the Santa Teresa Lab, and natural-language querying in the REQUEST project at Yorktown. International installations extended its reach from Tokyo to Heidelberg.

SQL began as a bold attempt to turn Ted Codd’s mathematical vision into something users could actually type. In the early 1970s, Don Chamberlin and Ray Boyce designed SEQUEL — a query language built not on logic symbols, but on readable templates like “SELECT” and “FROM.”

The language pioneered a declarative style: describe the data you want, rather than the steps to retrieve it. SEQUEL’s syntax mimicked English and allowed queries to be composed like building blocks. It was designed as a bridge for analysts, scientists, and business users, not programmers alone.

Query templates from the article “SEQUEL: A Structured English Query Language” by Donald Chamberlin and Raymond Boyce, showing how relational operations were expressed in readable, English-like statements. Source

The name “SEQUEL” was shortened to SQL after a trademark dispute with British aerospace firm Hawker Siddeley. Don Chamberlin recalls dropping the vowels to echo languages like APL.

While SQL began as an internal IBM research effort, it was soon picked up in academic experiments and commercial projects alike, laying the foundation for relational databases as everyday tools.

IBM prepared SQL for enterprise deployment with SQL/DS (announced in 1981) and DB2 (released in 1983), adapting relational concepts for large-scale business use.

Meanwhile, Oracle — founded by Larry Ellison, Bob Miner, and Ed Oates — seized the opportunity to commercialize relational ideas. Its second release, Oracle V2 in 1979, was the first SQL-based RDBMS available on the market. Built not on IBM’s source code but on published research about System R, it proved that relational design could be replicated and sold outside the labs.

Oracle 4.1 start screen, restored on DOS by Carel Jan Engel and Marco Gralike (2005) — a glimpse of how early SQL-based systems appeared to users. Source

SQL also gained traction in universities, where it was integrated into teaching tools and research systems. Students and researchers learned to write short, declarative statements — a style of interaction that began to define how users expected databases to work.

In 1986, the American National Standards Institute (ANSI) ratified SQL as the official database language, followed by the International Organization for Standardization (ISO) in 1987. This recognition established SQL as a common interface across vendors and platforms, fixing its role at the core of relational computing.

Federal Information Processing Standards Publication (1986), establishing SQL as a database language. Issued by the U.S. National Bureau of Standards. Source

The first standards, SQL-86 and SQL-89, defined a common core for queries. SQL-92 expanded the scope with features like outer joins, richer data types, and stricter rules of syntax. Later editions — SQL:1999, 2003, and beyond — layered in recursion, triggers, procedural logic, and eventually XML and JSON support, turning SQL into a full-fledged data manipulation language.

The drive toward standardization combined technical aims with commercial strategy. Vendors like IBM, Oracle, and Sybase backed SQL to ease adoption and reduce customer lock-in, even while promoting their own proprietary extensions. Academic systems and open-source projects followed the same path, ensuring that generations of developers learned SQL as a shared skill.

Critics — including Chris Date, one of Codd’s closest collaborators and most influential educators — argued that SQL strayed from relational purity. Yet its adoption was unstoppable: SQL became the de facto language of enterprise computing, not because it was flawless but because it was everywhere.

***

SQL’s triumph lay in becoming the universal medium of representation. Standardization cemented this role: tables and queries became the common voice through which institutions described and exchanged information.

Oracle’s roots trace back to a mix of military contracting, academic research, and Silicon Valley opportunism. Before founding Oracle, Larry Ellison and Bob Miner worked at Ampex, a CIA contractor developing software to manage and retrieve classified information. One of its projects carried the codename “Oracle” — a label Ellison and Miner later kept when they launched Software Development Laboratories (SDL) in 1977.

CIA Headquarters, Langley, Virginia (c. 1979). The agency’s internal project codenamed “Oracle” inspired Larry Ellison’s company name and marked the intersection of espionage and early relational databases. Source: Washington’s Top News

As relational systems entered the commercial mainstream, vendors competed on perception as much as on performance. In the late 1970s and early 1980s, ads from IBM, Oracle, and Honeywell translated the relational model into strategic narratives aimed at executives and IT buyers.

Trade journals like Computerworld, Datamation, and Byte filled with images of smart terminals, confident managers, and futuristic dashboards. Oracle leaned into portability and cost-efficiency; IBM emphasized enterprise reliability and integration; Honeywell pitched MRDS as a secure solution backed by Multics’ reputation.

Oracle “Page Your Oracle” television advert, ITV (1986). Campaigns like this reframed relational systems as accessible business tools, blending technical promise with cultural messaging.

These campaigns bridged the gap between theory and enterprise reality. Marketing turned relational databases into a recognizable symbol of efficiency and modernity.

The power of the relational model lay in how it connected data. Each row in a table carried a “primary key” — a customer ID, invoice number, or another unique marker. “Foreign keys” pointed from one table to another’s primary key, weaving relationships: an order tied to a customer, a payment linked to an invoice, a student mapped to a course.

PDP-11 brochure cover (1970). Relational concepts such as keys were applied to data managed on systems of this era. Source: Computer History Museum

This grammar of keys enabled normalization — reducing duplication and enforcing consistency across sprawling systems. Instead of repeating the same details in every record, databases stored them once and referenced them wherever needed. Codd’s abstract theory of relations thus became a practical framework for structuring business processes, research datasets, and institutional records.

The relational model didn’t begin with a graphical interface — it began with typed lines on glass screens. Before mice, menus, or dashboards, early relational database users interacted through terminals like the IBM 3270 or DEC VT52, issuing SQL commands in plain text. The user experience was stark: no buttons, no prompts — just blinking cursors and strict syntax.

An Informatics General programmer at the company’s New York office, reviewing Pascal code for the TAPS product on an IBM 3270 terminal (1983). Photograph by Jonathan Schilling. Source

Technical specifications for an early floppy-disk system used with DEC PDP-11 machines, detailing storage capacity (256 KB per diskette), transfer speeds, and physical dimensions. Such austere interfaces — blinking cursors, command lines, and hardware tied to precise limits — framed the early era of relational database use. Source

This minimalist interface reflected the declarative power of SQL itself. Users didn’t instruct the machine how to find data, only what to find. With commands like SELECT, FROM, and WHERE, users could write expressive queries — but only if they understood the structure of the database. In this early phase, accessibility was limited not by technology, but by knowledge.

Still, the separation of logic from layout opened the door to new interfaces. By the 1980s, relational systems would be paired with form builders, report generators, and eventually, GUI-based database tools. But before all that came the terminal — an austere, textual gateway to structured information.

Computer studies in Norway began in the 1950s within military research. Physicist Jan V. Garwick introduced digital methods at the national Defense Research Establishment, where Ole-Johan Dahl and Kristen Nygaard later collaborated on modeling complex systems such as bank queues and shared resources.

Collaboration with Manchester delivered Norway’s first Mercury computer in 1957, and by the early 1960s the Norwegian Computing Center in Oslo became a hub for their work.

Oslo Town Hall (1956). Ole-Johan Dahl first attended NDRE computing sessions here, where Norway’s defense establishment introduced digital methods to researchers. Source: DigitaltMuseum

Their language, Simula I (1965) and its successor Simula 67, introduced the concept of objects: program units with identity, data, and behavior. Conceived as tools for simulation, they established principles that would shape later programming.

Ole-Johan Dahl and Kristen Nygaard. Their collaboration at the Norwegian Computing Center produced Simula I and Simula 67, the first object-oriented languages. Source: History-Computer

Computer scientist Georg Philippot, recalling his time teaching Simula on a CDC 3300, described ending a course with a program that played Chopin’s funeral march as the machine was retired — a symbolic farewell to early computation and the beginning of a new paradigm.

CDC 3300 terminal at the computing center in Berlin. Machines like this hosted Simula courses. Source

Object-oriented programming (OOP) structures software around objects — units that combine data (attributes) with behavior (methods). Each object belongs to a class, which defines its properties and capabilities.

Classes can inherit traits from other classes, allowing shared logic while supporting specialization. A “Vehicle” class, for example, can define rules common to all transport, while “Car” and “Bike” extend it with their own features.

The Simula logo, created in Oslo during the 1960s. Simula introduced the concept of objects and became the first object-oriented programming language. Source

Objects interact by sending messages that invoke behavior, making systems evolve through encapsulation and modular design. Originally built for simulation, OOP soon became a general programming paradigm. It underpins most modern software design, from operating systems and business platforms to mobile apps and video games.

In 1963, Ivan Sutherland’s Sketchpad redefined how humans could work with machines. Built for the TX-2 mainframe at MIT’s Lincoln Lab, it let users draw directly on a screen with a light pen and then duplicate, constrain, or link elements.

Each element behaved like a reusable template, carrying constraints and relationships that could be inherited across instances. Without using the term, Sutherland had created a graphical environment where entities had identity, structure, and hierarchy.

Early research in interface design and cognition. Journals such as the International Journal of Man-Machine Studies built on concepts pioneered by Sketchpad, showing how its ideas influenced both technical design and the emerging study of human–computer interaction. Archive.org

Sketchpad became a foundation for computer-aided design, graphical user interfaces, and later object-oriented languages. It demonstrated that digital systems could respond in real time to visual input, shifting programming toward environments built from objects that could be manipulated directly.

Video demonstration of Sketchpad (1963). Ivan Sutherland shows the system running on the TX-2 computer at MIT’s Lincoln Lab, where users could draw with a light pen and manipulate objects directly on screen.

At Xerox PARC in the early 1970s, Alan Kay and his team drew on Simula, Sketchpad, and LISP to design Smalltalk — a system where everything was an object, from numbers to windows. It introduced dynamic class creation, inheritance, and a live graphical interface, offering an integrated environment rather than a standalone language.

Alan Kay at PARC. His background in music shaped his vision of software as modular, interactive, and improvisational — ideas that guided the creation of Smalltalk in the 1970s. Source: CyborgAnthropology

Cover of Smalltalk-80: The Language (1989) by Adele Goldberg. As part of the Xerox PARC team, she co-developed Smalltalk and advanced key object-oriented concepts that later influenced mainstream programming. Source: Amazon

While commercially limited, Smalltalk’s ideas shaped the next generation of programming. In the 1980s, C++ extended the C language with classes, bringing object orientation into mainstream engineering. By the 1990s, Java simplified object-based design for the web era, and Microsoft’s C# followed with a hybrid model for enterprise software.

As applications grew more complex — in areas such as computer-aided design, multimedia, and geographic information systems — relational databases revealed their limits. Flat tables and joins could not easily handle nested structures, versioning, or user-defined behaviors.

The solution proposed in the mid-1980s was the object-oriented database management system (OODBMS). In these systems, data entries were full objects with identity, structure, and behavior, often linked in complex hierarchies. Methods as well as attributes could persist, narrowing the gap between code and storage.

Early projects such as GemStone (built on Smalltalk) and Orion (written in Common Lisp) attempted this fusion of programming environments with persistent storage. They illustrated both the appeal and the difficulty of merging two paradigms that had evolved separately.

Interface from GemStone/S 2.5. This object-oriented database merged Smalltalk’s class structures with persistent storage, demonstrating how OOP principles were applied to data management. Source: The GemStone Object Database Management System, p. 68

Object-oriented databases found their strongest applications in domains that required complex representations. Computer-aided design (CAD) relied on nested hierarchies of parts, layered graphics, and evolving versions — all difficult to capture in relational tables.

Multimedia systems demanded ways to unify images, video, and sound under shared structures. Geographic information systems (GIS) layered spatial and temporal data into interlinked objects.

M&S Computing (later Intergraph) demonstrating CAD tools (1978). Early CAD required models with nested parts and evolving versions — pressures that encouraged the adoption of object-oriented databases for representing complex structures. Source

Projects such as STORM, developed at the University of Wisconsin, and Jasmine, a Japanese research initiative, demonstrated media-aware queries that could traverse formats and timelines. Teradata GIS and related efforts applied object-oriented logic to mapping and infrastructure, letting analysts represent geography as linked entities rather than disconnected records.

Object-oriented databases promised to eliminate the “impedance mismatch” between code and storage. By treating data entries as objects, they seemed to offer a natural fit for CAD, multimedia, and simulation systems that demanded complex hierarchies and evolving relationships.

CAD design of a Stihl chainsaw (1980s). Applications like CAD demanded hierarchies and versioning that relational systems struggled to handle. Source: Finnish Forest Museum Lusto; Metsähallituksen collection.

Readings in Object-Oriented Database Systems (1990), edited by Zdonik and Maier. This collection captured the momentum of OODBMS research — and the fragmentation that limited its adoption. Source: Google Books

Yet commercial adoption in the 1980s-90s faltered. Each platform tied objects to specific programming languages, and without a common query language like SQL, systems could not work well together. Schema changes were fragile, administrative tools were underdeveloped, and relational vendors kept improving performance and reliability, widening the gap.

Though most OODBMS products faded, their ideas persisted. Object-relational mapping frameworks like Hibernate and ActiveRecord reintroduced the concept at the application layer, while NoSQL systems such as MongoDB revived nested structures and flexible schemas. Even modern SQL engines now support complex types and JSON, echoing features pioneered by OODBMS.

Before punch cards and programmable computation, humans engineered astonishing mechanical systems to represent, control, and display data. These devices served as precursors to modern information technologies, blending automation with symbolic function.

Heron’s automation project for a statue of Bacchus pouring wine and milk in a temple. Illustration in a 13th century manuscript. Source

A self-trimming lamp, from the book “On Mechanical Devices” by Ahmad ibn Mūsā ibn Shākir (9th century CE). Source: Staats Bibliothek Berlin

Strasbourg astronomical clock (1574), a civic monument of timekeeping and automata. Source

Van Eyck and the Hemony brothers working on the carillon. Lithograph by W. G. Hofdijk (c. 1875), from “Lauwerbladen uit Neerlands Gloriekrans. Source

Claude Monet, “The Zuiderkerk, Amsterdam” (c. 1874). Philadelphia Museum of Art. The Zuiderkerk tower (1656) was among the earliest to house a fully automated Hemony carillon — a direct antecedent to punched media. Source

One of the earliest documented examples is Heron of Alexandria’s 1st-century CE automata: programmable theater devices, coin-operated dispensers, and wind-powered machines. These relied on systems of ropes, gears, and counterweights — physical logic encoded in motion. They demonstrated that information could be embedded in a mechanism, with repeatable outputs triggered by controlled inputs.

By the late Middle Ages and early modern period, public clocks and automata took on increasingly representational functions. The Strasbourg astronomical clock, for instance, combined religious calendar tracking with celestial mechanics, animating saints, angels, and planetary positions. These weren't mere decorations — they automated civic rituals and encoded cosmic models for public audiences.

In the 17^th century, the Hemony brothers pioneered pinned-cylinder bell carillons in Amsterdam, prefiguring later musical machines and punch card systems. Their programmable melodies translated sound into hardware logic — a principle reused in music boxes, player pianos, and eventually looms and computers.

Charles Babbage, a mathematician and inventor, designed two groundbreaking machines — the Difference Engine and later the Analytical Engine, the first serious attempt at general-purpose computation. Conceived in the 1830s–1840s, the Analytical Engine introduced ideas far ahead of its time: an arithmetic unit, memory registers, control flow with loops and conditionals, and a programmable instruction set using punched cards.

Babbage’s Difference Engine, on display at the Science Museum, London. Only partially built in his lifetime, it demonstrated the feasibility of complex mechanical computation. Source: Science Museum

Two types of punched cards for Babbage’s Analytical Engine — operation cards (specifying instructions) and variable cards (specifying data), adapting the Jacquard method for programmable logic. Source: Science Museum

Portrait of Ada Lovelace by Antoine Claudet (c. 1843). Lovelace wrote the first published algorithm for a machine and foresaw the wider potential of computation beyond numbers. Source

Babbage borrowed the concept of card-based control directly from the Jacquard loom, which encoded textile patterns as holes in cardboard. But instead of patterns for thread, Babbage imagined instructions for mathematical operations. His machine was never completed, but the architecture he proposed resembles many features found in modern CPUs and programming languages.

Ada Lovelace, working with Babbage in the 1840s, famously grasped the deeper implications of the machine. She proposed that the Engine could manipulate symbols as well as numbers, and might one day compose music or graphics — not merely calculate. Her notes are now recognized as the first published computer program.

Long before mechanical tabulators, governments used data to exert control. In early modern Europe, the rise of absolutist states brought new pressures to measure, compare, and forecast populations. Inspired by older registers like the Domesday Book, a new intellectual tradition emerged in the 17th century: political arithmetic.

Title page of Johannes Weitzel’s “Geschichte der Staatswissenschaft” (early 19th century), reflecting the formalization of state science as an academic and administrative discipline in German-speaking regions. Source

William Petty (1623–1687), pioneer of political arithmetic. His demographic and economic analyses laid foundations for modern statistical governance. Source

Table from the Down Survey (1655–1656), an early large-scale land and property data collection in Ireland under William Petty, using tabular methods to inform colonial administration. Source

Folio from the Domesday Book (1086), detailing Warwickshire. Part of William the Conqueror’s survey of English landholdings, one of Europe’s earliest centralized census efforts. Open Domesday

Pieter Bruegel the Elder, “The Census at Bethlehem” (1566), a Flemish reinterpretation of the biblical census that blends daily life with state authority in early modern administrative culture. Source

Pioneers like John Graunt and William Petty introduced statistical summaries of mortality and trade in London, proposing that societies could be studied mathematically. In German-speaking states, this formalized into Staatswissenschaft — the “science of the state” — combining demographic counts, land surveys, and resource assessments into a toolkit for rational administration

Throughout the 19^th century, the integration of mathematical methods into economics began to reshape data interpretation, despite resistance from traditional theorists. Many early modelers — including engineers like Charles Ellet and Jules Dupuit — introduced diagrams and curves to represent trade, cost, and flow.

Henry Higgs, “Some Remarks on Consumption,” in the Economic Journal (December 1899). Illustrates how qualitative analysis and verbal reasoning still dominated economic theory at the turn of the century, while mathematical modeling remained rare. JSTOR

Alfred Marshall’s graphical models (1870s–1890s), p. 67. Early use of curves to represent economic forces such as supply and demand, helping to formalize economics as a mathematical science. EE-T Portal

Their attempts to visualize economic behavior were seen as marginal at first. As late as 1892, 95% of articles in the top four economics journals used neither mathematical notation nor graphs (Stigler and Friedland, The Journals of Economics).

Still, this shift was underway. By the 1870s, Alfred Marshall brought graphical modeling into the mainstream, using intersecting curves to depict market mechanisms. These visualizations made abstract theory accessible and policy-relevant — a foundational turn toward data-driven economic reasoning.

The Jacquard loom created a radically new workflow of design abstraction. The key step was the mise en carte: transposing a textile pattern into an enlarged grid (rule-paper), where each square represented a thread action. From this intermediate visualization, specialized workers could generate punched cards — the program — detached from the weaver and readable by the machine.

Jacquard engine attached to a carpet loom (c. 1840). From Toshio Kasamitsu’s doctoral dissertation, 1982, p. 52. Source

In 1835, French machine maker C. Guillotte described this logic-to-fabric pipeline before a British committee. His testimony revealed an early encounter with the formalization of instructions. Design was now “read in,” parsed into discrete mechanical steps, and stored in physical memory.

This early modularization of creative labor—design, translation, encoding—foreshadowed modern digital interfaces and data visualization. Long before computers, workers were debugging logic patterns and offloading execution to automated systems, mediated through symbolic encodings on physical media.

Long before modern statistics, societies developed elaborate systems for counting people, goods, and time.

Cuneiform tablet (Sumer, c. 3000 BCE), used to record grain and livestock quantities as part of temple administration. Such artifacts enabled resource tracking, labor management, and redistribution across Mesopotamian city-states. Musée du Louvre, AO 29560. © 2002 GrandPalaisRmn (Musée du Louvre) / Franck Raux. Louvre

Clay tokens and bullae (Sumer, pre-3000 BCE), used as transaction records. Small tokens representing goods such as grain or sheep were sealed in hollow clay envelopes. This system provided the conceptual groundwork for abstract numeration and the invention of writing. Musée du Louvre, Iran antique 17403. Source

Model of cattle census (Egypt, 11th Dynasty). Wooden funerary model from the tomb of Meketre, showing scribes counting livestock. Such scenes were both documentary and magical, intended to ensure the eternal continuation of bureaucratic order and provisioning in the afterlife. Egyptian Museum, Cairo. Source.

Han Dynasty administrative slips (China, c. 1st century CE). Strips of bamboo and wood bound into scrolls, used to record census figures, tax receipts, legal proceedings, and edicts. Though paper existed, these durable media defined early Chinese record-keeping at imperial scale. Ejine Banner Museum of Inner Mongolia. China Services Info

Roman military diploma (90 CE), cast in bronze. Granted citizenship and marriage rights to a discharged auxiliary soldier. Designed for durability and authenticity, such diplomas reflect Rome’s infrastructure for legal and identity verification across the empire. Israel Museum. Source

Census of Quirinius, mosaic (Istanbul, c. 14th century), Church of the Holy Saviour in Chora. Depicts the biblical census from the Gospel of Luke, enshrining Rome’s enumeration practices in religious memory. The scene links identity, taxation, and power, showing census as both ritual and registration. Source

In ancient Sumer, clay tokens evolved into cuneiform tablets to track grain, livestock, and labor — a direct response to the needs of temple economies. Egypt’s annual nilometer readings and population tallies shaped everything from taxation to cosmic order. In Imperial China, the household registration system (hukou) maintained dynastic stability. Rome’s census did more than record — it legitimized class, military duty, and political privilege.

Enumeration isn't just about counting — it's about how categories get visualized and fixed. In the 17th and 18th centuries, European administrations relied on increasingly tabular formats: not simply ledgers of names and taxes, but forms that pre-structured reality into discrete fields, rows, and groupings.

Parish register page (England, 17th–18th c.), with neatly ruled columns for baptisms, marriages, and burials. By reducing lived events to standardized entries, these registers transformed experience into categories. North Yorkshire Archive Blog

André-Michel Guerry’s “Instruction” map of France (1833), showing literacy rates by département with color shading. The map enforced classification and comparison within spatial and categorical constraints. ResearchGate

These documents forced complexity into grids. “Head of household,” “acreage owned,” “occupation,” or “tribe” became checkboxes. In colonies and empires, local identities were reshaped into legible categories that fit bureaucratic templates — erasing nuance in favor of scale and control.

This transition marked a foundational step toward modern data representation.

Before numerical models dominated, knowledge was often conveyed through images. Scientific illustrations meant more than decoration — they were essential tools for observation, measurement, and communication. In the Renaissance, artists like Brunelleschi and Piero della Francesca systematized linear perspective, providing a new framework for visual reasoning.

Geometrical drawing of an icosahedron inside a cube by Piero della Francesca, from “De quinque corporibus regularibus” (c. 1460). This study shaped post-Medieval fine arts and influenced the early development of data visualization techniques. Source

Geometrical drawing of an icosahedron inside a cube by Piero della Francesca, from “De quinque corporibus regularibus” (c. 1460). This study shaped post-Medieval fine arts and influenced the early development of data visualization techniques. Source

“Melencolia I,” engraving by Albrecht Dürer (1514). Source: Metropolitan Museum

In the late 15^th century, printed science texts such as Euclid's Elements (Erhard Ratdolt, 1482) integrated geometrical diagrams alongside mathematical logic, shaping how abstract concepts were understood. Johannes de Sacrobosco's astronomical works used diagrams to explain celestial mechanics, providing a visual means of understanding complex, invisible systems.

By the 16^th century, Albrecht Dürer combined anatomical precision with proportional geometry, exemplified in his Four Books on Human Proportions. These illustrations went beyond artistic representation, offering a form of visual argumentation that influenced both scientific reasoning.

Sir Henry Furnese, who founded the Bank of England in 1694, was among the first merchants to build espionage networks, gathering reports from across Europe on military, political, and trade affairs. His ability to anticipate market shifts through such information marked an early form of business intelligence, moving commerce from instinctual decision-making toward data-driven speculation.

Adriaen van Diest, “Destruction of the Soleil Royal at the Battle of La Hogue” (1692). This pivotal event in the Nine Years’ War shaped European political and military outcomes and influenced emerging financial systems. The Bank of England, mentioned earlier, was founded to fund this conflict. Source: Royal Museum Greenwich

With the rise of industrial capitalism, businessmen sought more formalized, empirical ways to manage complexity. In the 1880s, engineer Frederick Winslow Taylor developed time-and-motion studies to measure labor productivity. His data-driven insights redefined managerial decision-making.

Film still from a pioneering study by Lillian Gilbreth and Ralph Barnes (1910–1924). Using motion-picture analysis to record factory tasks, they developed motion study techniques that advanced systematic approaches to business intelligence and laid foundations for data-driven management in early 20th-century industry. Source: Archive.org

In the early 20th century, the pioneering films by Lillian Gilbreth and Ralph Barnes, investigating industrial operations and developing motion study techniques (1910-1924), further advanced the systematic approach to business intelligence. Their work laid the foundation for the growing use of data to streamline operations and decision-making.

Soon after, Henry Ford adapted such techniques to refine production lines, timing the manufacture of each component and embedding measurement into industrial practice.

The industrial push to mechanize business records brought calculating devices out of labs and into the workplace. In 1879, Ohio saloon owner James Ritty and inventor John Birch patented the “incorruptible cashier,” a mechanical register designed to prevent employee fraud.

Models were soon enhanced with paper rolls for printed receipts, turning cash registers into trusted tools for recording financial transactions. This innovation led to the founding of companies like Burroughs and National Cash Register, which later pivoted into the computing industry.

Meanwhile, Swedish engineer Willgodt T. Odhner, working in St. Petersburg (Russian Empire), developed a compact mechanical arithmometer in the 1870s. His device, refined over decades, became a standard in Soviet administrations and was marketed in the West under the “Facit” brand.

Blueprint of the cash register and indicator from U.S. Patent No. 221360, filed by James and John Ritty on November 4, 1879. Google Patents

Illustration of Odhner’s arithmometer from the magazine “Science and Life” (Nauka i zhizn), No. 45 (1890). Life and Science

In 1945, Vannevar Bush envisioned the Memex, a desk-sized device designed to help users link and retrieve vast amounts of information. Users could create personalized trails connecting photos, notes, and documents, anticipating modern hypertext.

Sketch from Vannevar Bush’s article “As We May Think,” republished in ACM SIGPC Notes (1979). Worrydream

Though never built, the Memex influenced the development of interactive data systems and user interfaces, bridging business data with human memory and creativity. It foreshadowed the personal computer and the idea of navigating data as a cognitive tool, not only storing facts.

UNIVAC central panel, used by operators to control programs and monitor machine status through switches and indicator lights. Photo by Don DeBold. Source

The UNIVAC I (Universal Automatic Computer I), introduced in 1951, was the first digital computer designed for commercial use in the United States. It was a room-sized system powered by thousands of vacuum tubes, using magnetic tape drives along with punch cards. UNIVAC could execute approximately 1,905 operations per second, and it employed mercury delay line memory capable of storing 1,000 words of 12 characters each.

This hardware allowed UNIVAC to handle both numeric and alphabetic data at unprecedented speeds for its time. It was programmable, universal in purpose, and significantly outpaced earlier mechanical and electromechanical systems.

The machine sold for between $1.25 and $1.5 million, which limited its potential to spread across industries. But its cultural impact was such that it quickly became a symbol of the new era of machine-powered thinking.

UNIVAC’s debut wasn’t in theory — it was in practice. The U.S. Census Bureau became the first non-military, non-academic institution to operate an electronic digital computer. The agency used it to tabulate census data, performing large-scale record matching and statistical analysis that would have taken human clerks weeks or months.

A UNIVAC computer at the U.S. Census Bureau (c. 1960). Source: U.S. Census Bureau

This early deployment in 1951 was so successful that the Bureau later declared UNIVAC had never been involved in any error incident — a powerful vote of confidence in machine logic at a time when skepticism ran deep. Soon after, General Electric became the first private business to use UNIVAC, adopting it for payroll computation.

At the time, IBM dominated government installations. Their tabulators were already embedded across agencies. Many public-sector computing offices were effectively IBM-run — staffed by former IBM employees, running IBM systems, and thinking in IBM workflows. UNIVAC, though technically superior, was considered an outsider.

As one official put it:

“If I recommend UNIVAC and it fails, I made a mistake. If I recommend IBM and it fails, IBM made a mistake.”

By the mid-1950s, the U.S. Air Force and other federal agencies had adopted UNIVAC systems for logistical planning, missile tracking, and resource scheduling. These systems weren’t designed for battlefield control, but served instead as part of the administrative backbone of Cold War operations.

UNIVAC’s ability to process alphabetic data was a major advantage, allowing for more complex record-keeping and scenario modeling than number-crunching machines alone.

Air Force enlisted specialists operating a UNIVAC computer (July 28, 1956). Source: Special Collections and Archives; Wright State University Libraries

Toward the end of the decade, Remington Rand’s UNIVAC division was bidding alongside IBM for government defense contracts, embedding itself in the infrastructure of federal automation. Unlike IBM’s tightly controlled systems, UNIVAC’s flexibility and tape-based I/O made it attractive for unconventional environments — from defense logistics centers to early weather modeling programs.

J. Presper Eckert and John Mauchly, already known for ENIAC, left wartime research to form the Eckert–Mauchly Computer Corporation. Their aim was to build a “universal automatic computer” that could handle business records as easily as equations.

UNIVAC began not with a corporation but with two engineers pushing an idea beyond ballistics. But their startup struggled: capital was scarce, the market uncertain, and the technology untested.

In 1950, the project was absorbed by Remington Rand, a typewriter and office-equipment giant with money and distribution power. That merger kept the machine alive — and with it, the possibility of a commercial computing industry.

UNIVAC entered public consciousness in 1952, when CBS used it to predict the outcome of the U.S. presidential election. The machine signaled Eisenhower’s victory hours before most commentators were willing to commit, turning a broadcast into a national spectacle. For many Americans, this was the first moment a computer appeared as an authority, its output treated as a credible forecast rather than a technical curiosity.

UNIVAC advertisement from “Time” magazine (1967). Source: Poshmark

The UNIVAC name soon spread beyond the machine itself — borrowed in fiction, headlines, and advertising. Its visual form became equally iconic: glowing panels, magnetic tape reels, blinking lights. These elements circulated in media and corporate branding, establishing a recognizable aesthetic of computation in the 1950s and 1960s.

Yugoslavia entered the digital age in the 1960s and 1970s with the CER (Cifarski Elektronski Računar) series, developed in Belgrade by the Mihajlo Pupin Institute. It was one of the first independent national computing initiatives outside the United States and the Soviet Union.

Early models like the CER-10 used transistor-based architecture with punched cards for input, later adding magnetic tape for storage and backup. The system featured 4 KB of magnetic core memory, expandable in later versions, and processing speeds in the tens of thousands of operations per second.

CER-10 computer at the Tanjug building (1963). Photograph by Dušan Hristanović.

CER machines were applied to scientific research, state statistics, and media tasks such as automated news distribution. They played a central role in modernizing Yugoslavia’s administrative and information infrastructure.

In 1965–1966, Weyerhaeuser, a major U.S. timber company, became the first non-GE customer to implement IDS — turning the database into the foundation for a real-time, nationwide business system.

Sales brochure for the GE-200 series computer (1960s). The platform was later used for early IDS implementations. Source: Ferretonix.com

The setup linked over 100 remote teletype terminals to a central GE-235 computer using a DATANET-30 network. Orders placed across the country were entered directly into the system, which updated inventory, managed shipping logistics, and generated invoices.

The system used Problem Controller, an early form of online transaction processing (OLTP), to prioritize and manage concurrent requests. At peak demand, transaction volumes briefly overwhelmed the system, but the architecture proved robust and adaptable.

By the late 1950s, the Soviet Union faced a contradiction: while its military and scientific sectors deployed digital computers with growing sophistication, civilian institutions — especially Gosplan, the State Planning Committee — remained wary of adopting the same tools.

The USSR had previously used imported tabulators like Powers and Hollerith machines, later building its own analogs such as the T-5, exported to other socialist countries. But the leap to electronic computing was politicized. Even as Gosplan quietly launched its own Computer Center in 1959 and installed its first Ural-2 machine in 1960, internal resistance to large-scale data automation persisted.

Fidel Castro at the Main Computer Center of the USSR State Planning Committee, Moscow (1972), with Nikolai Baibakov, chairman of Gosplan, and Nikolai Lebedinsky, head of the center. Source

The paradox deepened in the 1960s. Despite new equipment — including British Elliott 403 and ICL System-4 machines — and cooperation with East Germany on ALGOL translators, Gosplan remained cautious.

A proposed national automation system, the OGAS network, led by cybernetician Victor Glushkov, envisioned a nationwide digital system for economic planning. But it was blocked — not due to technical failure, but because it threatened existing institutional control over data flows. In the Soviet model, information was not only infrastructure but also political power.

In the 1960s, Soviet cybernetician Victor Glushkov proposed a nationwide network of computers to manage the USSR’s economy in real time. Called OGAS (Общегосударственная автоматизированная система учёта и обработки информации), or the National Automated System for Computation and Information Processing, it aimed to unify factories, ministries, and planners in a single, continuously updated digital infrastructure.

The proposed system included regional computing centers linked to central hubs in a three-tier architecture, real-time inputs from across industries, and automated modeling to aid planning. Terminals were planned for remote enterprises, from industrial plants to mining sites and state-owned farms.

Glushkov’s team at the Kyiv Institute of Cybernetics had experience in systems design, and prototypes for smaller-scale implementations already existed. But OGAS never launched.

Victor Glushkov with Tadeusz Marjanovich, who led process-modeling research at the Kyiv Institute of Cybernetics. Near Kyiv, 1970s. Source: Glushkov family archive

The system promised transparency, efficiency, and redistributed authority, challenging the entrenched gatekeepers of economic knowledge. Despite repeated proposals through the late 1960s and early 1970s, OGAS was quietly defunded, gutted, and eventually abandoned.

In the early 1960s, two very different machines shaped how organizations approached digital information: the General Electric GE-225 and the IBM 1401.

The GE-225, introduced in 1960, was built for power and flexibility. It featured simultaneous input/output handling, supported both alphabetic and numeric data, and could connect to disk drives like MRADS. Input came from magnetic tape, punched cards, MICR documents, and even paper tape, with long-distance connections supported via the DATANET-15. It was a machine for custom-built systems like real-time data integration.

Meanwhile, the IBM 1401, released in 1959, took the market by storm with its affordability and reliability. Its six-bit character system, magnetic core memory (4K–16K), and decimal arithmetic made it perfect for payroll, billing, and inventory. Leased for around $2,500/month, it brought computing within reach of small and mid-sized businesses — earning the nickname "the Model T of the computer industry."

IBM 1401 computing the results for the city of Kiel, West Germany, during the federal election (1965). Source

Their rivalry wasn’t just about specs — it was about philosophies:

• IBM offered safe, standardized tools for the mainstream.
• GE pushed toward modularity, extensibility, and integration.

The GE-225 later found academic life as well — a time-sharing version at Dartmouth became the birthplace of the BASIC programming language.

COBOL’s standardization opened the door to an entirely new market: commercial software development. In 1959, Advanced Data Research (ADR), a New Jersey–based firm, began offering contract programming services, specifically advertising COBOL expertise in Datamation magazine by 1961.

Advertisement for AUTOFLOW, a programmers’ assistance tool, in Datamation magazine (June 1966). Source: Bitsavers

One of ADR’s key products was AUTOFLOW, an application that automatically generated flowcharts from COBOL source code. At a time before video terminals, visualizing program logic on paper was essential. AUTOFLOW helped users trace and document complex logic paths, making it easier to debug, explain, or maintain large-scale software.

COBOL’s breakthrough was linguistic. Business software could now be written in something resembling natural English, with syntax drawn from everyday office practice. Instead of abstract math or dense assembly, programmers used phrases like MOVE TOTAL TO SUMMARY-TOTAL. This made programs legible to non-programmers and reframed coding as documentation.

Grace Murray Hopper, Rear Admiral and computer pioneer, in her Washington, D.C. office (1978). She often lectured in uniform, using her Navy role to underscore authority in a male-dominated field, though in everyday work she wore civilian clothes. Photograph by Lynn Gilbert. Source

This readability was deliberate. Grace Hopper and the CODASYL committee wanted software to be transparent, teachable, and aligned with how people already communicated. By borrowing vocabulary and structure from business memos and accounting reports, COBOL positioned itself as a mediator between humans and machines.

In 1957, IBM users formed SHARE and GUIDE groups to collaborate on programs for new hardware. Projects like SURGE and 9PAC extended the IBM 704/709’s capabilities. Though IBM didn’t develop them, it later supported and maintained 9PAC, seeing its value. These early systems experimented with data dictionaries, file hierarchies, and routines for migrating between hardware environments.

Apollo–Soyuz spacecraft in Earth orbit, docked configuration. NASA diagram (1974). North American Rockwell and IBM collaborated on systems for the Apollo program. Source: NASA Collection, S74-05269

Still, tape-based storage had limits. The real breakthrough came when IBM pivoted to disk — and partnered with aerospace contractor North American Rockwell to build IMS (Information Management System). Originally developed to manage components for the Apollo program, IMS pioneered hierarchical data models and multitasking data access.

By the late 1960s, IMS ran on IBM’s System/360 and supported multiple concurrent applications from a single memory image. IBM states that IMS still supports 95% of Fortune 1000 companies today.

IBM’s System/360, launched in 1964, introduced modular computers with upgrade paths, standardized architecture, and compatibility across a wide range of peripherals. Its design popularized the 8-bit byte, data channels, and 9-track magnetic tape, pushing the industry toward mass production and interoperability. European and Japanese manufacturers soon followed, building IBM-compatible systems.

IBM System/360 mainframe at the opening of The Washington Data Processing Center (April 1, 1966). Statistical Reporting Service of USDA Administrator Harry Trelogan looks on as Agriculture Secretary Orville Freeman tests out some of the functions. Photo courtesy of the National Archives and Records. Source: US Department of Agriculture Flickr

Key hardware elements for early database management included:

• Magnetic tape drives for sequential backups and bulk data archiving.
• DASDs (Direct Access Storage Devices) for fast, random access to structured data.
• Punched cards and paper tape as legacy media for data entry and programs.
• Terminals such as the IBM 2260 and Univac Uniscope, which enabled full-page interaction and gave users real-time access to enter, correct, and visualize data.

In the late 1950s, a spontaneous meeting between IBM and American Airlines executives on a flight sparked the idea for a computerized reservation system. Drawing from IBM’s military experience with the SAGE air defense system, the two companies built SABRE — the Semi-Automated Business Research Environment.

American Airlines SABRE advertisement showing the network of its computerized reservation system (late 1960s). Source: Tails Through Time

Launched in 1960, SABRE became the world’s first commercial real-time data system, handling 83,000 bookings per day via two IBM 7090 mainframes. Its interactive model allowed agents to check seat availability, confirm tickets, and update records instantly, replacing manual booking processes.

The 1964 Tokyo Olympics posed a monumental data challenge: 7,000 athletes, 100 countries, and up to 25 simultaneous contests across 32 venues. To manage this, IBM Japan deployed a real-time data processing system that transformed event coordination forever.

Data-printing center in the Olympic Village, Tokyo (1964). Source: Official Games Report

Using 62 IBM 1050 terminals across venues, scores were sent to a central Olympic Data Center powered by eight IBM computers. With a disk capacity of 56 million characters, the center processed rankings, judge scores, and registration data for 12,000 participants — within seconds. Over 100,000 messages were expected, with three to four times as many replies sent back.

By default, early computing relied on batch processing — collecting data over hours or days, then feeding it into a system for a single, uninterrupted run. This was ideal for repetitive, large-scale jobs like payroll or census tabulation. The method emphasized efficiency in an era when computer time was scarce and expensive.

Brochure page for the 1101 Keyed Data Recorder, Mohawk Data Science Corporation (1965). Source: Internet Archive

The shift to Online Transaction Processing (OLTP) enabled systems to handle data in real time, allowing for immediate response to user input. The change was made possible by new magnetic disks (offering random access), faster processors, and networked terminals.

Before the rise of graphical interfaces and data dashboards, businesses made sense of information through structured printouts — organized columns of numbers, names, and dates. This was the world of reporting and tabulation, where value lay in turning raw machine data into readable summaries.

Brochure page for the Portable Addressograph, Addressograph-Multigraph Corp. (1950s). Source: Internet Archive

Computing’s main output in this era was text, and layouts were built with typewriters and line printers. Custom-coded routines used spacing and symbols, inserted headers, pagination, totals, and alignment, giving readers a way to scan, compare, and analyze continuous-form paper visually.

Draftsmen working on a blade template drawing at a large table (1953). Source: NASA/Glenn Research Center collection

Even without graphics, sales reports, inventory sheets, and payroll summaries transformed raw bits into managerial knowledge. The software behind these outputs became precursors to later business intelligence tools.

Early computers didn’t greet users with icons or buttons. Interaction meant command-line precision, punched card stacks, and binary switches. Human–machine communication was intense, physical, and deeply technical.

“A Fable for Computer Users,” Control Data Corporation booklet, 1960s. Source: Internet Archive.

“A Fable for Computer Users,” Control Data Corporation booklet, 1960s. Source: Internet Archive.

Users were mostly operators, engineers, and programmers — not everyday clerks or analysts. Programs were written in machine code or assembly, entered via punch cards or front-panel switches. The idea of a “user-friendly” system simply didn’t exist.

Control panels featured toggle switches, status lights, and manual overrides. Later came command line interfaces (CLIs), where users had to type exact instructions. A single typo could crash an entire batch run.

To improve efficiency, Job Control Languages (JCLs) emerged — scripts that told the computer what to do, in what order, and how to handle results. This was automation before the GUI.

Meanwhile, efforts to standardize peripheral interfaces, data formats, and operating procedures foreshadowed the shift toward interoperable systems. Symbolic abstractions like mnemonic codes pointed toward usability, but the user was still a technician, not a typist.

Codd’s work on the relational model was rooted in IBM’s dramatic hardware evolution. In the early 1960s, he worked with the IBM 7090, a transistorized mainframe widely used for scientific and business computing. Bulky by today’s standards, it nonetheless laid the groundwork for systematizing data operations.

A meteorologist at the console of the IBM 7090 electronic computer in the Joint Numerical Weather Prediction Unit, U.S. Weather Bureau (c. 1965). The 7090 underpinned early business computing and formed part of Codd’s working environment. Source: National Oceanic and Atmospheric Administration

By the late 1960s, IBM introduced the System/360, a platform that unified architectures for business and scientific applications. Its design brought direct-access storage devices (DASDs) — a crucial step toward random-access data retrieval and, eventually, relational systems.

Page with mainframe console image from the IBM System/360 sales brochure (1964). The 360 symbolized scalable computing — groundwork for relational systems in business. Source: Computer History Museum

Codd’s vision explicitly abstracted away hardware dependence, promoting logical organization over machine constraints.

In the mid-1970s, the Multics Relational Data Store (MRDS) became the first commercial implementation of Codd’s relational model. At Honeywell’s Phoenix facility, Jim Weeldreyer and Oris Friesen led its development, drawing on Codd’s theoretical framework while working in parallel with early relational projects such as IBM’s System R and Berkeley’s Ingres.

Midtown Phoenix, Arizona (1970s). Honeywell’s Phoenix facility developed MRDS here, an early hub of relational database innovation. Source: Rogue Columnist

Running on the secure, time-sharing Multics operating system, MRDS took advantage of virtual memory and was written in PL/1. Its design allowed users to access and manipulate structured data using high-level relational commands. In 1976, Honeywell marketed MRDS as part of the Multics Data Base Manager (MDBM), which also included a CODASYL-style layer.

Diagram from the MRDS Manual (1981), showing the Relational Data Source Model — one of the first real-world implementations of relational principles for structured business data. Source: Bitsavers

As vendors rushed to sell products branded “relational,” Edgar Codd intervened to separate marketing claims from architecture. In two Computerworld articles (October 14 and 21), he introduced a framework for judging whether a system truly followed relational principles.

Herald Square elevated railroad and Sixth Avenue with R.H. Macy & Company department store in the background, New York (c. 1910s–1930s; published 1949). After emigrating from England, Edgar F. Codd briefly worked in Macy’s men’s department before turning to computing; within two decades he introduced the relational model and later received the Turing Award for it. Source: Library of Congress, Prints & Photographs Division, Detroit Publishing Company Collection

Codd’s 12 rules — actually 13, counting Rule Zero — outlined what a genuine relational database must provide. Rule Zero required that a DBMS manage data strictly through relational methods, not as a façade over hierarchical or network systems. The remaining rules specified fundamentals such as data independence, accessible metadata, set-based operations, and logical consistency.

One practical rule emphasized multiple-record-at-a-time processing: a single command should update entire sets — raising all prices by 10% or changing every Polish address to “Warsaw, Poland.” This stood in contrast to earlier one-record-at-a-time approaches.

In the late 1970s, IBM partnered with real-world users to validate the relational model’s performance in live environments. The first major test came in 1977, when Pratt & Whitney, a jet engine manufacturer, used System R to manage parts and inventory.

Pratt & Whitney Aircraft duct burner (1979). System R tracked fine-grained logistics during jet engine assembly, ensuring no parts were left behind. Source: NASA / Glenn Research Center Collection

Shortly after, Upjohn Pharmaceuticals deployed it to track clinical research data for FDA applications. While these early adopters didn’t leverage features like concurrency, locking, or transactions to their fullest, they proved relational systems could serve serious industrial use cases.

Upjohn compensation formula table (late 1970s). The company stored experimental data in System R during clinical trials. Source: Corporate archival material

Among the growing pains IBM engineers faced was the “Halloween Problem,” discovered on October 31, 1976. Updates to a table could cause rows to re-enter a scan and be modified repeatedly — a quirk that haunted the SQL optimizer until engineers redesigned update handling. Despite these challenges, the project’s success was undeniable: it laid the groundwork for SQL/DS (1981) and the launch of IBM DB2.

System R’s developers left behind stories that were as colorful as their code. Don Chamberlin recalled a memorable visit to Upjohn Pharmaceuticals in Kalamazoo, Michigan — where the team had installed System R to manage clinical research data. Their hosts lodged them in a Victorian mansion with tandem bikes and a full liquor wall: “We asked if we could take home anything we didn’t drink.”

Company sign spotted by System R engineers during a tour of the vitamin production line (late 1980s). Source: Upjohn

Beyond these surreal moments, IBM tested System R in diverse settings: attack helicopter design at Owego, GUI prototypes at the Santa Teresa Lab, and natural-language querying in the REQUEST project at Yorktown. International installations extended its reach from Tokyo to Heidelberg.

SQL began as a bold attempt to turn Ted Codd’s mathematical vision into something users could actually type. In the early 1970s, Don Chamberlin and Ray Boyce designed SEQUEL — a query language built not on logic symbols, but on readable templates like “SELECT” and “FROM.”

The language pioneered a declarative style: describe the data you want, rather than the steps to retrieve it. SEQUEL’s syntax mimicked English and allowed queries to be composed like building blocks. It was designed as a bridge for analysts, scientists, and business users, not programmers alone.

Query templates from the article “SEQUEL: A Structured English Query Language” by Donald Chamberlin and Raymond Boyce, showing how relational operations were expressed in readable, English-like statements. Source

The name “SEQUEL” was shortened to SQL after a trademark dispute with British aerospace firm Hawker Siddeley. Don Chamberlin recalls dropping the vowels to echo languages like APL.

While SQL began as an internal IBM research effort, it was soon picked up in academic experiments and commercial projects alike, laying the foundation for relational databases as everyday tools.

In June 1976, Honeywell introduced the Multics Relational Data Store (MRDS), the first relational database management system released by a major vendor. Built directly into the Multics operating system, MRDS let users query data through relational algebra and predicate calculus. It coexisted with the Multics Integrated Data Store (MIDS), a hierarchical model, giving organizations a rare choice between competing paradigms.

System control panel for Honeywell 6000 series mainframes, the hardware platform supporting MRDS (1980s). Source

Multics’ design emphasized security and multi-user access, qualities that MRDS inherited. Although its reach was limited by Honeywell’s less common Series 60/Level 68 hardware, MRDS showed that relational concepts could be implemented as part of a commercial product.

Frisbee from a Multics company picnic (1968–1980) — a glimpse of the community around Honeywell’s computing projects. Source: Biblio

Computerworld coverage of Honeywell’s MRDS launch (September 1976) — part of Honeywell’s high-profile global rollout and among the first commercial ads for a relational DBMS. Source: Google Books

Oracle’s roots trace back to a mix of military contracting, academic research, and Silicon Valley opportunism. Before founding Oracle, Larry Ellison and Bob Miner worked at Ampex, a CIA contractor developing software to manage and retrieve classified information. One of its projects carried the codename “Oracle” — a label Ellison and Miner later kept when they launched Software Development Laboratories (SDL) in 1977.

CIA Headquarters, Langley, Virginia (c. 1979). The agency’s internal project codenamed “Oracle” inspired Larry Ellison’s company name and marked the intersection of espionage and early relational databases. Source: Washington’s Top News

As relational systems entered the commercial mainstream, vendors competed on perception as much as on performance. In the late 1970s and early 1980s, ads from IBM, Oracle, and Honeywell translated the relational model into strategic narratives aimed at executives and IT buyers.

Trade journals like Computerworld, Datamation, and Byte filled with images of smart terminals, confident managers, and futuristic dashboards. Oracle leaned into portability and cost-efficiency; IBM emphasized enterprise reliability and integration; Honeywell pitched MRDS as a secure solution backed by Multics’ reputation.

Oracle “Page Your Oracle” television advert, ITV (1986). Campaigns like this reframed relational systems as accessible business tools, blending technical promise with cultural messaging.

These campaigns bridged the gap between theory and enterprise reality. Marketing turned relational databases into a recognizable symbol of efficiency and modernity.

INGRES stood apart from IBM’s System R and Oracle’s early products. Developed at UC Berkeley by Michael Stonebraker and his team, it served as both a research platform and a teaching tool, making relational databases accessible to students and researchers worldwide. Its open, experimental character contrasted with IBM’s tightly controlled prototypes and Oracle’s aggressive commercial push.

Commercials from magazines

Advertisements for INGRES in computer trade magazines (early 1980s) — positioning the Berkeley spinoff as a challenger to IBM’s slower-moving offerings. Source: Archive.org

Advertisements for INGRES in computer trade magazines (early 1980s) — positioning the Berkeley spinoff as a challenger to IBM’s slower-moving offerings. Source: Archive.org

Advertisements for INGRES in computer trade magazines (early 1980s) — positioning the Berkeley spinoff as a challenger to IBM’s slower-moving offerings. Source: Archive.org

Humorous video advertisement of Ingres. 1980s

In 1980, the team launched Relational Technology Inc., one of the first startups devoted to database software. INGRES’s portability and academic credibility gave it traction in universities and midsize businesses, where it offered a credible alternative to proprietary systems. It showed that relational software could grow not only through corporate channels but also through academic networks that seeded talent, tools, and ideas across the industry.

As relational databases spread into real-world use, they needed to fit into existing software ecosystems. That meant bridging SQL — a high-level, declarative query language — with the low-level power of system programming. In the 1970s and early 1980s, that meant C.

Ken Thompson and Dennis Ritchie at Bell Labs (1970s–1980s). Their creation of C provided the foundation for operating systems and database engines alike. Source: Computer History Museum

Originally developed at Bell Labs for UNIX, C became the language of choice for operating systems and high-performance applications. Its portability, memory control, and ability to interface directly with hardware made it ideal for embedding database engines like Oracle and INGRES. Oracle’s shift from assembly to C allowed the database to scale across platforms, from PDP-11s to minicomputers and eventually PCs.

Developers also needed ways to issue SQL queries from within C programs, leading to embedded SQL, APIs, and eventually standards like ODBC. This coupling between SQL and C defined a generation of software design, intertwining business logic with database access at the code level.

The relational model didn’t begin with a graphical interface — it began with typed lines on glass screens. Before mice, menus, or dashboards, early relational database users interacted through terminals like the IBM 3270 or DEC VT52, issuing SQL commands in plain text. The user experience was stark: no buttons, no prompts — just blinking cursors and strict syntax.

An Informatics General programmer at the company’s New York office, reviewing Pascal code for the TAPS product on an IBM 3270 terminal (1983). Photograph by Jonathan Schilling. Source

Technical specifications for an early floppy-disk system used with DEC PDP-11 machines, detailing storage capacity (256 KB per diskette), transfer speeds, and physical dimensions. Such austere interfaces — blinking cursors, command lines, and hardware tied to precise limits — framed the early era of relational database use. Source

This minimalist interface reflected the declarative power of SQL itself. Users didn’t instruct the machine how to find data, only what to find. With commands like SELECT, FROM, and WHERE, users could write expressive queries — but only if they understood the structure of the database. In this early phase, accessibility was limited not by technology, but by knowledge.

Still, the separation of logic from layout opened the door to new interfaces. By the 1980s, relational systems would be paired with form builders, report generators, and eventually, GUI-based database tools. But before all that came the terminal — an austere, textual gateway to structured information.

In 1963, Ivan Sutherland’s Sketchpad redefined how humans could work with machines. Built for the TX-2 mainframe at MIT’s Lincoln Lab, it let users draw directly on a screen with a light pen and then duplicate, constrain, or link elements.

Each element behaved like a reusable template, carrying constraints and relationships that could be inherited across instances. Without using the term, Sutherland had created a graphical environment where entities had identity, structure, and hierarchy.

Early research in interface design and cognition. Journals such as the International Journal of Man-Machine Studies built on concepts pioneered by Sketchpad, showing how its ideas influenced both technical design and the emerging study of human–computer interaction. Archive.org

Sketchpad became a foundation for computer-aided design, graphical user interfaces, and later object-oriented languages. It demonstrated that digital systems could respond in real time to visual input, shifting programming toward environments built from objects that could be manipulated directly.

Video demonstration of Sketchpad (1963). Ivan Sutherland shows the system running on the TX-2 computer at MIT’s Lincoln Lab, where users could draw with a light pen and manipulate objects directly on screen.

At Xerox PARC in the early 1970s, Alan Kay and his team drew on Simula, Sketchpad, and LISP to design Smalltalk — a system where everything was an object, from numbers to windows. It introduced dynamic class creation, inheritance, and a live graphical interface, offering an integrated environment rather than a standalone language.

Alan Kay at PARC. His background in music shaped his vision of software as modular, interactive, and improvisational — ideas that guided the creation of Smalltalk in the 1970s. Source: CyborgAnthropology

Cover of Smalltalk-80: The Language (1989) by Adele Goldberg. As part of the Xerox PARC team, she co-developed Smalltalk and advanced key object-oriented concepts that later influenced mainstream programming. Source: Amazon

While commercially limited, Smalltalk’s ideas shaped the next generation of programming. In the 1980s, C++ extended the C language with classes, bringing object orientation into mainstream engineering. By the 1990s, Java simplified object-based design for the web era, and Microsoft’s C# followed with a hybrid model for enterprise software.

Object orientation reshaped runtime environments by modeling programs as systems of interacting entities. Instead of treating code as a single flow of instructions, it allowed multiple objects to act in parallel, each maintaining its own state and responding to events.

This approach, first explored in Simula’s simulations and then applied to visual interfaces, soon shaped interactive software more broadly. Early computer games became laboratories for object-oriented thinking, where complex behavior emerged from collections of autonomous agents rather than centralized scripts.

SimCity (1989). Buildings and services function as autonomous objects, with the city emerging from their interaction and responses to changing conditions. Source

Lemmings (1991). Each lemming follows its own rules. Gameplay comes from coordinating a swarm of reactive objects through a shifting environment. Source

Little Computer People (1985). A simulated household built from objects. Behavior arises not from direct scripts but from the state and affordances of items in the environment. Source

Object-oriented databases found their strongest applications in domains that required complex representations. Computer-aided design (CAD) relied on nested hierarchies of parts, layered graphics, and evolving versions — all difficult to capture in relational tables.

Multimedia systems demanded ways to unify images, video, and sound under shared structures. Geographic information systems (GIS) layered spatial and temporal data into interlinked objects.

M&S Computing (later Intergraph) demonstrating CAD tools (1978). Early CAD required models with nested parts and evolving versions — pressures that encouraged the adoption of object-oriented databases for representing complex structures. Source

Projects such as STORM, developed at the University of Wisconsin, and Jasmine, a Japanese research initiative, demonstrated media-aware queries that could traverse formats and timelines. Teradata GIS and related efforts applied object-oriented logic to mapping and infrastructure, letting analysts represent geography as linked entities rather than disconnected records.