00 · The Map
This chapter is the ground floor of the tower — the map every chapter above it assumes you have seen.
Why is "computer science" neither about computers nor a science — and what are the disciplines, really?
In September 1967, three men wrote a letter to the journal Science because colleagues kept telling them their field did not exist. Allen Newell, Alan Perlis, and Herbert Simon were not obscure cranks defending a fad: Perlis had received the first Turing Award ever given, the year before; Newell and Simon would share one in 1975; Simon would add a Nobel Prize in economics in 1978. Their defense fit in a sentence — computer science is "the study of computers and all the phenomena surrounding them" (Newell, Perlis & Simon, 1967).
Eighteen years later, the most famous textbook the field ever produced opened by disagreeing with its founders. Abelson and Sussman's Structure and Interpretation of Computer Programs declares in its preface a conviction that "computer science" is not a science, and that its significance has little to do with computers (SICP, 1985). A sharper version of the same jab circulates to this day — computer science is no more about computers than astronomy is about telescopes — usually pinned on Edsger Dijkstra, though the traceable source is Michael Fellows and Ian Parberry in 1993 (Quote Investigator).
So the founders called it a science of computers, and the field's own catechism says it is neither. Both are right, and seeing how both can be right is the work of this chapter — and the organizing idea of this book.
The first thing to understand is that "computing" is not one discipline wearing five name tags. Each discipline is a different question asked about the same machines. The official map was drawn by the professional computing societies: the CC2005 report (ACM, AIS, and the IEEE Computer Society) fixed the five classical disciplines, and its successor CC2020 — a fifty-member task force from twenty countries, reporting at the end of 2020 — inherited them and welcomed two arrivals. The five ask:
Computer science (CS): what can be computed at all, and at what cost? Computer engineering (CE): how does electricity become logic — and where exactly does hardware end and software begin? Software engineering (SE): what happens to a program when it must live for years and be changed by many hands? Information systems (IS): what does computing do inside an organization — to its decisions, records, and power? Information technology (IT): who keeps real systems running for real users, and how? The arrivals are cybersecurity (curricular guidelines: CSEC2017) and data science (ACM competencies, 2021) — younger, and, as we will see, shaped differently from the elder five.
Watch one artifact — a hospital's patient-records system — and the five become five professions. The computer scientist asks whether the record-matching algorithm scales to ten million patients. The computer engineer asks why the storage controller corrupts writes during power loss. The software engineer asks how to change the billing module without breaking the pharmacy's. The IS specialist asks why nurses route around the system with paper notes. The IT professional is the one paged at 3 a.m. when it goes down. Same machine; five questions.
This book does not walk that map department by department. It makes a different cut — the cut the field itself quietly makes every day. Computing's one great trick, the trick underneath every discipline, is abstraction: build a floor, hide its machinery, and offer the floor above a surface simpler than what it conceals. Electric charge is hidden by the transistor; transistors by logic gates; gates by the processor; the processor by the operating system; the machine's bare instructions by programming languages; single machines by networks; and on upward until a child drags a photo across a screen, commanding billions of switches with one finger and needing to understand none of them. Nobody holds the whole tower in mind at once. That is not a failure of education — it is the design. Dijkstra, in his 1972 Turing Award lecture, put his finger on why the trick works: the purpose of abstracting is not to be vague, but "to create a new semantic level in which one can be absolutely precise" (EWD340). Each floor is not a blurrier view of the one below; it is a new language, exact on its own terms.
The proof that the tower is climbable is that students climb it. In Nisan and Schocken's course-in-a-book The Elements of Computing Systems (nand2tetris.org), learners start with a single logic gate and build — gates, chips, a machine, an assembler, a compiler, an operating system, a game — in one term. One person can build the whole stack only because each floor needs nothing from the floor below except its surface.
But the surfaces are not perfect, and this is the second idea the whole book leans on. Joel Spolsky named it the Law of Leaky Abstractions: "all non-trivial abstractions, to some degree, are leaky" (Spolsky, 2002). Your app promises that a message "was sent," until the network below it disagrees. Two loops, logically identical, run ten times apart in speed because of how memory hardware three floors down caches data. When an abstraction leaks, someone must descend the stairs — and knowing which floor the leak comes from is most of what expertise in computing is. That is why every chapter in this book answers three questions about its floor: what it hides, what surface it offers, and where it leaks.
Now the two 1967-versus-1985 claims resolve. Newell, Perlis, and Simon were right: the phenomena are real, and floors like architecture, networks, and machine learning are studied with experiments, like nature. Abelson and Sussman were right too: no floor above the bottom two is about electronics at all — the upper tower is made of pure structure, closer to mathematics than to any machine. Computing is not one kind of knowledge. It is a tower in which physics hardens into engineering, engineering into language, and language into something very much like thought.
How to read this book: there are fifteen floors and a closing chapter, each self-contained, each 900–1,400 words — principles, not surveys. Chapters 01–03 are bedrock (what is computable, what is efficient, what is information); 04–06 build the machine; 07–10 take it to scale; 11–14 walk the edges, where adversaries, learned behavior, and human beings enter. Read in order to climb the tower, or jump to any floor — every chapter names its place in the stack in its first line, and its Connections section tells you which stairs lead where.
Connections
Below this chapter: nothing — this is the ground. Every other chapter stands on it. The disciplines map onto the floors unevenly, and that is worth noticing as you read: CS saturates chapters 01–03 and 12, CE owns 04, SE owns 07, IS and IT surface in 08–10, and the two young arrivals — security and data science — turn out not to be floors at all but stairwells, cutting vertically through everything (11 and 12 explain why).
Open questions
Is computing a science, a branch of engineering, or a new kind of mathematics? The 1967 letter did not settle it, and sixty years on the field still funds all three answers. Will data science and cybersecurity harden into disciplines with their own floors, or dissolve into competencies every computing professional needs — the reading CC2020's competency-first framing quietly favors? And is the tower finished growing? Chapter 12 raises the live possibility that natural language itself is becoming the newest floor — a surface under which everything in this book is hidden.
Go deeper
- Charles Petzold, Code: The Hidden Language of Computer Hardware and Software, 2nd ed., Microsoft Press, 2022 — the lower tower, built floor by floor for a general reader; interactive companion at codehiddenlanguage.com.
- Allen Newell, Alan Perlis & Herbert Simon, "Computer Science," Science 157, no. 3795 (1967): 1373–1374 — science.org.
- ACM & IEEE Computer Society, Computing Curricula 2020: Paradigms for Global Computing Education — full report PDF.