Foundations of Computing

Lesson 1 of 10

What is a Computer?

"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim." — Edsger W. Dijkstra

You are holding one — in your pocket, on your desk, in the phone that woke you this morning. You use computers fluently and yet, pressed to say what one is, most people reach for a picture of a screen and a keyboard. That is like defining a book by its cover. Underneath the glass sits one of the most consequential ideas humans have ever had, and it is far simpler — and far stranger — than the hardware suggests. This chapter is about that idea, because every other chapter in this Volume is a detail of it.

The question this chapter answers

A phone, a laptop, a bank's mainframe, and the Mars rover look nothing alike and do wildly different jobs. What single idea makes all of them the *same kind of thing* — and why does that idea matter the first time an interviewer asks you to "explain what happens when a program runs"?

Core Concepts

A computer is a machine that follows instructions to transform input into output — and, crucially, one whose instructions can be changed. Strip away the screen, the brand, the operating system, and every computer that has ever existed reduces to a four-beat loop: it takes input, processes it by following a list of instructions, produces output, and along the way it can store state to come back to. Input, process, output, storage. A calculator does it. A supercomputer simulating the climate does it. The difference is scale, not kind.

But that definition still describes a washing machine. The word that separates a computer from every other machine is programmable. A washing machine follows instructions too — but they are baked into its wiring. You cannot convince a washing machine to play chess. A computer's instructions are not welded in; they are data you can replace. Change the instructions and the same physical machine becomes a different tool entirely. That single shift — from a machine built to do one thing to a machine that can be told what to do — is the whole revolution.

The stored-program idea

Here is the move that made modern computing possible, and it is subtler than it looks. Early machines drew a hard line: the machine was the hardware, and the instructions came from outside — patch cables you rewired by hand, punched cards you fed in. Reprogramming ENIAC to solve a different problem could take a team of people the better part of two days, physically re-plugging the thing.

The breakthrough was to notice that instructions are just numbers too. If a program is a sequence of numbers, and a computer is a machine that reads and writes numbers, then the program can live in the same memory as the data it works on. This is the stored-program concept, and it is why you can install an app in seconds instead of rewiring a room. The computer fetches an instruction from memory, does what it says, fetches the next, and repeats — millions or billions of times a second. Software stopped being a physical act and became information.

That arrangement — one memory holding both instructions and data, a processing unit that fetches and executes them one after another — is the von Neumann architecture, named for the 1945 report that described it. Nearly every computer you will ever touch is, at its heart, a von Neumann machine. Its parts map cleanly onto our four beats:

Part Role Our four-beat loop
CPU (control unit + ALU) Fetches instructions, does the arithmetic and logic Process
Memory (RAM) Holds both the running program and its data Store (working)
Input devices Keyboard, network, sensors — data coming in Input
Output devices Screen, speaker, network — results going out Output
Storage (disk/SSD) Keeps data and programs when the power is off Store (persistent)

What an "instruction" actually is

We keep saying "instructions," so let us be exact, because interviewers will be. An instruction is not a line of Python. It is something far smaller and far dumber: a single, primitive command the CPU understands directly, encoded as a number. Add these two numbers. Copy this value from memory into a register. If this value is zero, jump to that instruction. Compare these two. That is roughly the whole vocabulary — arithmetic, moving data around, comparing, and jumping.

A CPU has no idea what a website, a photo, or your name is. It knows how to add, move, compare, and jump — and it does so astonishingly fast. Everything else — this sentence rendering on your screen, a video call, a neural network — is built out of billions of those tiny operations stacked into towers of abstraction. When you write total = price + tax in a high-level language, a chain of translators (compilers, interpreters) grinds it down into a few of those primitive numeric instructions the silicon can actually execute. The gap between "add two numbers" and "run a video call" is not magic. It is layers — and this whole Volume is a tour up that ladder.

Universality — the idea underneath everything

Now the deepest point, and the one that separates people who use computers from people who understand them. In 1936 — before a single electronic computer existed — a 24-year-old named Alan Turing described an imaginary machine so simple you could explain it on a napkin: a tape of cells, a head that reads and writes symbols, and a tiny table of rules. He then proved something staggering: a machine of this kind, given the right rules, could compute anything that any other such machine could compute. He called it a universal machine.

The consequence is the hidden foundation of the entire industry: hardware does not determine what a computer can do — software does. A computer is not a tool for one job that happens to be flexible. It is a universal machine that becomes whatever program you load into it. Your laptop is a word processor, a guitar tuner, a chess grandmaster, and a film studio — not because it has parts for each, but because it is universal and you fed it different instructions. This is why the software industry exists at all. We do not manufacture new machines for new problems; we write new instructions for the universal one we already have.

History changed here

Two men, one idea, five years apart. In 1936 Alan Turing, trying to settle an abstract question in mathematical logic, invented the "universal machine" on paper — proving that a single simple device could, in principle, compute anything computable. He was not trying to build a product; he was trying to define the *limits* of calculation, and stumbled onto the blueprint for the computer. Then in 1945, John von Neumann distilled the practical engineering into the First Draft of a Report on the EDVAC — the document that fixed the stored-program design we still build on. Turing gave us the why it's possible; von Neumann gave us the how to build it. Almost every machine since has been a physical answer to those two theoretical questions.

Everyday analogy

Think of a player piano versus a pianist. A music box is welded to one tune — that is a washing machine, a fixed-function device. A player piano reads a paper roll punched with holes; swap the roll and the same piano plays a different song. That roll is a stored program, and the piano is a small computer: the instructions live in the same slot the machine reads from, so changing the instructions changes the behaviour without touching the hardware. Now imagine a piano whose roll could describe any instrument at all — that leap, from "plays any song" to "becomes any instrument," is universality.

The engineer's notebook

What this abstraction buys you in daily work:

• The layers are the mental model. When something breaks, good engineers ask which layer — hardware, OS, runtime, or my code? Knowing the machine is a stack of translations tells you where to look.
• "It's all just instructions and memory" cuts through mystique. A slow program is doing too many instructions or touching memory badly. A crash is an instruction that did something illegal. The four-beat loop is your first diagnostic.
• Software is data. This is why a bug can rewrite a program's own behaviour, why a virus is possible, and why "code" and "config" and "data" blur together at the bottom. The stored-program idea has security consequences you will meet for your whole career.

Real-world example — chika.ng Academy

The server that renders this very lesson is a plain von Neumann machine running in a data centre. Your click is input arriving over the network; the CPU processes it by executing the Academy's instructions — fetching your lesson, checking your progress, building the page; the database is persistent storage holding your account when the power's off; and the rendered chapter is output sent back to your screen. Nothing exotic. The same site could tomorrow become a certificate verifier, a quiz engine, or a video host — same hardware, different instructions. That is universality earning its keep in production.

Common Mistakes

  • Confusing the computer with its screen. The monitor, keyboard, and case are peripherals. The computer is the part that fetches and executes instructions. A server with no screen is still every inch a computer.
  • Thinking hardware determines capability. "My phone can't do X" is almost always a software statement, not a hardware one. Universality means the limit is usually the program, not the silicon.
  • Believing a program is the text you wrote. Your source code is a human convenience. What runs is a stream of primitive numeric instructions the CPU understands — your code is translated down to them first.
  • Treating instructions and data as different kinds of things. In a stored-program machine they live in the same memory and are both just numbers. That's the whole trick, not a footnote.
  • Saying "the CPU is the brain" and stopping there. It's a fast, obedient, unthinking clerk that can only add, move, compare, and jump. Intelligence in software is built from those primitives — it is not inside them.
Thought experiment

Imagine a computer with exactly four instructions: add two numbers, move a number between memory slots, compare two numbers, and "if the last comparison was equal, jump to a different instruction." No multiply, no divide, no "display image," nothing else. Could this machine run a spreadsheet? Render a photo? Train an AI? The astonishing answer is yes — given enough memory and time, that four-instruction machine can compute anything your laptop can. Multiplication is just repeated addition; everything richer is layers built on the same floor. That is Turing's universality made concrete — and the reason "what can a computer do?" is really a question about software, not hardware.

Interview Corner

Interview Corner — the same idea at three levels. Answer yours; recognise the one above it.
Junior
"What's the difference between hardware and software?"
Model answer — "Hardware is the physical machine — the CPU, memory, disk, the parts you could touch. Software is the instructions that tell the hardware what to do, stored as data in memory. The key insight is that the same hardware runs different software, so it can become different tools — a browser one moment, a game the next — without any physical change."
Follow-up they'll throw: "Where does firmware fit?" → It's software stored on the hardware itself (like a BIOS) — the boundary is a spectrum, not a wall, which is exactly the point.
Intermediate
"Explain the von Neumann architecture, and what a 'stored program' means."
Model answer — "It's a design where a CPU, a single shared memory, and input/output are connected by a bus. The defining feature is that both the program's instructions and its data live in the same memory — that's the stored-program idea. The CPU runs a fetch-decode-execute cycle: fetch the next instruction from memory, decode what it means, execute it, repeat. Because instructions are just data in memory, you can load new programs without rewiring anything — which is why software exists as a field."
Follow-up: "What's the von Neumann bottleneck?" → Instructions and data share one path to memory, so the CPU can stall waiting on it. Naming caches and the Harvard architecture as responses is a strong signal.
Senior
"Walk me through what actually happens, top to bottom, when a user runs your program."
Model answer — "The OS loads the executable's instructions from disk into memory and creates a process with its own address space. The CPU's program counter points at the first instruction and the fetch-decode-execute cycle begins — each instruction a primitive: arithmetic in the ALU, moves to and from registers and memory, compares, and jumps that implement my loops and branches. My high-level code was already compiled or is being interpreted down to those primitives. System calls hand off to the kernel for anything privileged — I/O, networking, allocating memory. Output leaves through devices the OS mediates. At bottom it's the stored-program loop; everything above it — processes, languages, frameworks — is abstraction layered to keep me from thinking in raw instructions."
This is really a systems-thinking question wearing a trivia costume. The senior move is naming the layers — hardware, kernel, runtime, application — and showing you can move between them deliberately.
Company lens — how the same topic gets asked
micro1Live and conversational. The AI interviewer wants you to define terms cleanly out loud — "hardware is X, software is Y, and here's why the boundary matters." Structure beats a memorised paragraph.
GooglePushes for first principles: "why is it designed that way?" Expect to defend the stored-program trade-off and reason from the fetch-execute cycle up, not recite it.
MicrosoftValues clear, layered explanation. Narrate the model from CPU and memory upward through the OS to the app — organised thinking scores over deep trivia.
Amazon / AWSOperational lens: "your program runs on thousands of these machines at once — what's really a CPU, memory, and I/O bound?" Tie the architecture to cost, throughput, and where the bottleneck lives.
Hands-on exercise
  1. Take a device near you — a microwave, a car key, a smart speaker. Decide out loud whether it is a fixed-function machine or a programmable computer, and justify it using the word "stored program."
  2. Map one action you did today (sending a message) onto the four beats: input, process, store, output. Name what played each role.
  3. Explain in one breath, as in a micro1 screen, why "my laptop can't do that" is usually a claim about software, not hardware. Use the word "universal."

Chapter Summary

  • A computer is a programmable machine: input → process (by following instructions) → output, with storage for state — the four-beat loop under everything.
  • "Programmable" is the dividing line: a computer's instructions are replaceable data, not welded-in wiring.
  • The stored-program idea — instructions are just numbers living in the same memory as data — is what makes software a thing you can install instead of a room you rewire.
  • The von Neumann architecture (CPU + shared memory + I/O, running fetch-decode-execute) is the design nearly every real machine still follows.
  • An instruction is a tiny primitive — add, move, compare, jump — and everything richer is layers of abstraction stacked on those.
  • Universality (Turing, 1936): one machine can run any program, so what a computer can do is decided by software, not hardware. That is why our whole industry writes instructions instead of building new machines.
Narrative bridge

We keep saying instructions and data are "just numbers" living in the same memory — but numbers written how? A CPU has no tens, no hundreds, no digits as you know them. It has switches, and a switch is only ever on or off. Every instruction, every photo, every word in this lesson is ultimately built from that single two-state atom. So before we can climb the ladder of abstraction, we have to meet its bottom rung — the language the machine actually thinks in. That is where we turn next: Binary.

Editorial reflection — the temptation is to treat "what is a computer?" as a warm-up question, beneath a real engineer. Resist it. Almost every hard bug, every performance mystery, every security hole you will ever chase is a place where the machine is behaving exactly as a fetch-execute loop over stored instructions must — and your intuition, built on screens and apps, expected something else. Understand the machine as it actually is, and you spend the rest of your career being surprised far less often than everyone around you.

Q&A · 0

Enrol to ask questions and join the discussion.

No questions yet — be the first to ask.