Engineers often meet the present in its most compressed form: a framework, an API, a cloud service, a board, a model, a protocol. Everything seems available now, as if technology were only a succession of updates. History of Computer Systems teaches the opposite. It shows that computing is cumulative, that technical environments are layered, and that every generation of tools sits on older scientific, industrial and political decisions.

To understand a system, students should ask what problem it originally solved, which constraints shaped it, what older layer it still depends on and what social world made it durable.

01 Why history belongs in an engineering curriculum

At DSTI we follow a long-standing conviction in scientific and engineering education: the humanities belong inside technical training. A good engineer does not only implement a method; they can situate it, recognise its assumptions and see the historical horizon it comes from. History does not dilute technical formation — it gives it depth.

That matters especially in computing, a field that moves quickly but remembers more than it admits. The fashionable surface changes; the deep structures are inherited — programming paradigms, operating-system ideas, database models, network architectures and the institutions that standardise them. The sections below trace a few of those inheritances concretely, because the point is not that history is interesting but that it is load-bearing.

02 A working day is full of the 1970s

Two ideas from a single decade still sit under most of what a software engineer touches. The first is UNIX. Begun at Bell Labs around 1969 by Ken Thompson and rewritten in Dennis Ritchie’s new C language in the early 1970s, it made a handful of design commitments that proved unusually durable: a single hierarchical file system, the principle that almost everything — devices, processes, configuration — can be treated as a file, and small programs composed through pipes rather than one large application. Those commitments are everywhere today. Linux inherited the model; the BSD line runs inside macOS and iOS; Android sits on a Linux kernel; and most cloud servers are UNIX-like. The POSIX standard exists precisely so that this inheritance stays portable across vendors.

The second is the relational model. In 1970 Edgar Codd, at IBM, argued that data should be expressed as relations and queried by describing what you want rather than navigating how it is stored. The systems he displaced — hierarchical databases such as IBM’s IMS, and network databases — forced the application to walk pointer paths by hand. Codd’s idea took years and two research prototypes, IBM’s System R and Berkeley’s Ingres, to become practical; SQL descended from the former. It endured because it survived a change of hardware generations without changing the questions you ask of it.

New is often a reorganisation

The recent twist is instructive: the NoSQL movement of the 2000s traded relations and strict consistency for scale, and the NewSQL systems that followed quietly put the relational interface back on top of distributed storage. Much of that debate re-ran trade-offs Codd’s contemporaries had already named. Recognising the reorganisation is a practical skill, not a merely historical one.

03 The mainframe never left

It is tempting to file mainframes under history. They are, instead, where several load-bearing ideas were first worked out. IBM’s System/360, announced in 1964, introduced something more important than any single machine: a family of computers sharing one architecture — one instruction set — independent of how each model was built in hardware. That separation of architecture from implementation is the contract every modern instruction set still honours, from x86 to Arm to RISC-V, and it is why software can outlive the chip it first ran on.

Virtualisation, now the substrate of cloud computing, was not invented by the cloud; IBM was running full virtual machines by the early 1970s. Time-sharing systems such as MIT’s CTSS and Multics, in the 1960s, already let many users share one machine under isolation and scheduling — the direct ancestor of multi-tenant cloud. And COBOL, standardised in 1959, still runs a large share of the world’s core banking, insurance and government processing. Calling that code legacy is accurate; treating it as inert is not. A good deal of what is marketed as cloud-native is time-sharing and virtualisation rediscovered with better tooling and a billing model.

04 Networks are agreements, not just cables

A protocol looks like a technical artefact. Historically it is also an institutional one, and the two are hard to separate. Packet switching — breaking communication into independently routed packets — was proposed in the early-to-mid 1960s by Paul Baran at RAND, who wanted a network that could survive partial destruction, and independently by Donald Davies at the National Physical Laboratory in Britain, who coined the term. ARPANET carried its first packets in 1969.

The decisive move came in 1974, when Vinton Cerf and Robert Kahn specified the protocol that became TCP/IP, and in the end-to-end principle articulated by Saltzer, Reed and Clark in 1984: keep the network simple and push intelligence to the edges. That principle is an engineering choice with political consequences — it is part of why the internet stayed open to applications its designers never imagined. So is the culture that standardised it: the IETF’s working motto, “rough consensus and running code”, and the open RFC series describe a particular way of deciding who may define an interoperable network. Debugging a connection means working inside decisions about governance as much as about packets.

05 AI is a long argument, not a sudden arrival

No field is described more ahistorically than artificial intelligence, and none suffers more for it. The name dates to the 1956 Dartmouth workshop, but the conversation is older — Norbert Wiener’s Cybernetics appeared in 1948, and statistics and optimisation are older still. The pattern since has been cyclical, not linear.

Frank Rosenblatt’s perceptron (1958) generated great optimism; Minsky and Papert’s Perceptrons (1969) made its limitations explicit and is associated with the funding collapse now called the first AI winter. Neural methods revived when backpropagation was popularised in 1986, faded again with the expert-systems bust of the late 1980s, and returned decisively only when enough computing power and labelled data existed to make deep networks work — the moment usually dated to AlexNet’s ImageNet result in 2012. Today’s systems are the latest layer on that sequence of hope, disappointment and accumulation.

Knowing the cycle is the best inoculation against both the claim that everything changed last year and the cynicism that nothing is ever new. History usually says which part is which.

06 Technology is political history: the French case

Because engineering is never separate from the institutions that fund and standardise it, the same system can take very different shapes in different states. France is an unusually clear case to study — part of why it has a place in this course. After American export restrictions and General Electric’s absorption of the French firm Bull, France launched the Plan Calcul in 1966: a state programme to build a sovereign computing industry, which created the manufacturer CII and the research institute that became INRIA.

Two decades later the Minitel network put a working online terminal into millions of French homes from the early 1980s — a directory, services and a payment model years before the consumer web. It is a textbook example of a national strategy that genuinely succeeded and created its own later form of lock-in. Read together, these episodes teach what no architecture diagram can: that who funds a technology, who standardises it, and which industrial and administrative structures surround it shape the result as much as the engineering does. That judgement matters directly when graduates later work on data governance, platform design, cyber security or AI deployment.

That is why “AI is humanities” matters: engineers build inside societies, not outside them, and the history of a technology is part of knowing how to build its next layer responsibly.

07 Why this sits in the BSc

The course gives students the map above and the habit of using it: connecting a present-day architecture to the generation of systems beneath it, understanding why some legacy survives and some standards endure, and reading a new technology by asking what problem it first solved and what older layer it still depends on. It complements programming, systems, mathematics and engineering practice rather than competing with them — the aim is an engineer with technical memory as well as technical skill, able to recognise hype without becoming cynical about genuine change.

At DSTI it is taught by Pr Pierre Mounier-Kuhn, a research historian of computing (CNRS; Centre Roland Mousnier, Sorbonne University) whose work on the emergence of computing as a science, and on the French case in particular, is part of the scholarly record listed below.

08 Further reading

For readers who want to go to the sources rather than take the summary on trust:

Pierre-Éric Mounier-Kuhn, L’Informatique en France, de la seconde guerre mondiale au Plan Calcul. L’émergence d’une science (Presses de l’Université Paris-Sorbonne, 2010) — the institutional history of how computing became a discipline in France.
Pierre-Éric Mounier-Kuhn, Mémoires vives. 50 ans d’informatique chez BNP Paribas (BNP Paribas, 2010) — fifty years of enterprise computing seen from inside one organisation.
Martin Campbell-Kelly & William Aspray, Computer: A History of the Information Machine — the standard single-volume survey.
E. F. Codd, “A Relational Model of Data for Large Shared Data Banks”, Communications of the ACM (1970) — the paper underneath every SQL database.
D. M. Ritchie & K. Thompson, “The UNIX Time-Sharing System”, Communications of the ACM (1974) — UNIX described by its authors.
V. G. Cerf & R. E. Kahn, “A Protocol for Packet Network Intercommunication”, IEEE Transactions on Communications (1974) — the origin of TCP/IP.
J. H. Saltzer, D. P. Reed & D. D. Clark, “End-to-End Arguments in System Design” (1984) — why the internet keeps intelligence at the edges.

Editorial note. This is an editorial presentation of the BSc course “History of Computer Systems” and the reasons it belongs in the curriculum. The historical summaries are written for a general engineering audience and simplified accordingly; the editorial wording is not attributed to Pr Pierre Mounier-Kuhn. Suggested readings are listed for those who wish to consult the sources directly.