Is Your Phone a Pile of Chips or a Stack of Ideas?

The Crash That Made You Think

Maya installed an app to block spam calls. Instead, it sometimes blocks her grandma. She grumbles, “Stupid software.” Her dad says, “Maybe the phone’s chip is overheating.” Who’s right? Most people split a computer into two worlds: software (the instructions, the code) and hardware (the physical machine that runs them). Software is ghostly and abstract; hardware is solid and touchable. But philosophers of computer science say that simple split falls apart the moment you look closely. If you can’t say where software ends and hardware begins, you can’t properly explain what a computer is — or why it sometimes misbehaves.

In the late 1970s, philosopher James Moor argued that the software/hardware border is a practical invention, not a deep fact about the world. He noticed that old computers literally wired their programs into physical levers. A programmer might call those levers “software,” while an engineer calls them “hardware.” What counts as software depends on who’s doing the counting. To Moor, the division is like deciding whether a sandwich’s taste belongs to the bread or the filling — useful for the cook and the baker, but not a clear line in nature.

Other thinkers pushed harder. Peter Suber, writing in 1988, claimed that hardware is a kind of software. He defined software as any pattern — any definite structure — that can be read and executed. A rock with a streak of cracks, a bookshelf arranged in a certain order, a toaster’s heating coil: all physical objects carry patterns. If someone invents a language that gives meaning to those patterns, then the rock becomes a program. Suddenly, the solid world starts looking a lot less solid.

When Chips Become Code

Suber’s idea sounds wild, but it has a point. Any physical object that displays a definite pattern can, in principle, be treated as an executable set of instructions if you assign a syntax and a meaning to it. You could decide that a line of pebbles spells out “add 2 and 3.” The pebbles don’t care; the computation happens in the eye of the interpreter. This makes the hardware/software split more about human perspective than about the machine itself.

Philosopher Timothy Colburn (1999) tried a middle path. He called software a concrete abstraction. It’s concrete because code always lives in some physical medium — a hard drive, a piece of paper, a flash of electricity. It’s abstract because programmers think about what the code should do without worrying about the exact hardware underneath. A program written in Python should work on a laptop, a tablet, or a toaster if someone writes the right translator. Colburn called this “enlargement of content”: instead of stripping away details, the abstraction of code adds possibilities — one set of instructions can run on many kinds of machines.

Nurbay Irmak (2012) objected that an object cannot be both concrete and abstract in the same way, because concrete things have spatial and temporal properties and abstract things don’t. Software, he said, has a beginning in time (someone invents it) and can stop existing if every copy is destroyed and nobody remembers the algorithm. But software has no fixed location — you can’t point to the “real” copy of a program the way you can point to a single chair. Irmak called software an abstract artifact: something human-made that exists in time but not in space.

These debates show that even the two-layer model of “code running on metal” is full of cracks. To solve the puzzle, some philosophers decided to draw a much taller picture.

A Layer Cake of Abstractions

Instead of a simple sandwich, think of a tall layer cake. This is the levels of abstraction (LoA) approach. According to this view, a computational system isn’t just hardware and software; it’s a whole hierarchy. Computer scientist Giuseppe Primiero (2016) laid out six common layers:

• Intention: what you want the system to do (say, “block calls from numbers on a blacklist”).
• Specification: a careful description of the functions the system must perform to meet that intention.
• Algorithm: the step-by-step recipe that solves the problem laid out in the specification.
• High-level language instructions: the algorithm written in a language like Python or Java that humans can read but machines can’t run directly.
• Assembly/machine code operations: the low-level instructions that a specific processor actually understands.
• Execution: the physical level, where electrical signals zip through circuits and produce results on the screen.

None of these layers alone is “the computer.” Take away the intention, and you just have a machine doing meaningless flips of voltage. Take away the physical execution, and you have a plan that never touches the world. The whole stack counts.

This layered view explains something neat: each level acts as a specification for the one below it and as an implementation of the one above. The algorithm is an implementation of the specification; the high-level code is an implementation of the algorithm; and so on. And because each level sets the correctness rules for the one beneath, a system can go wrong in any layer. A flawed intention (“block all calls from unknown numbers” when you really meant “block telemarketers”) is a problem just as much as a burned-out chip.

Is Your App Correct? The Search for Errors

Philosophers distinguish several flavors of miscomputation, not just “it crashed.” Francesco Fresco and Giuseppe Primiero (2013) sorted them using the layer cake:

• Mistakes are errors in the higher, conceptual layers. An inconsistent intention or a specification that forgets an important case is a mistake. Maya’s app blocking her friend might be a mistake if the spec didn’t allow for known contacts.
• Failures happen when an algorithm or a program doesn’t correctly match the layer above it. The spec said “filter spam,” but the algorithm accidentally filters every incoming call. That’s a failure.
• Operational malfunctions are purely physical — a chip overheating or a memory cell stuck at zero.

There are also slips: tiny syntactic or semantic blunders in the code, like forgetting to initialize a variable.

When you press “send” and the app freezes, the bug could be a lofty mistake in the initial wish or a low-level hardware glitch. The layered picture doesn’t just help philosophers sort these out; it gives engineers a map for where to look when things go wrong. Modern testing and formal verification methods often combine logical proof (to check that the algorithm matches the specification) with empirical experiments (to see whether the physical machine actually behaves). Neither method alone catches every error, and having the right ontology reminds everyone that “correctness” is a relationship all the way down the stack.

Why This Matters: From Toasters to Self-Driving Cars

Our world runs on ubiquitous computational systems — smart thermostats, streaming services, medical robots, the autopilot of a plane. When one of them misbehaves, the practical question is always the same: What went wrong? But you can’t answer that without first answering the philosophical question: What is this thing? If you think of a computer as just a box of chips, you’ll hunt only for broken wires. If you see it as a stack of intentions, specifications, and implementations, you’ll check whether the user’s wish was clear, whether the specification captured it, and whether each layer faithfully translated the layer above.

The debate doesn’t stop at man-made devices. Some scientists argue that brains, cells, even the universe itself might be computational systems in a similar layered sense — a view called pancomputationalism. That’s a bigger can of worms, but it starts from the same puzzle: what counts as a computation, and who decides?

Next time your video game glitches or your phone app blocks a call it shouldn’t, you can think like a philosopher of computer science. Instead of just muttering “the software is buggy” or “the hardware is fried,” you can ask: At what layer did the chain break? Was the designer’s goal fuzzy? Did the specification miss a hidden case? Did the algorithm handle the situation correctly, but the code messed it up? Suddenly, the crash isn’t just annoying — it’s a detective story whose clues are scattered across a tower of ideas.

Think about it

1. If you could interpret any pattern as a program, does that mean a rock is a computer if you decide it’s adding numbers? What, if anything, would make a rock a real computer?
2. Your app keeps crashing, and the developer blames the hardware manufacturer, who blames the programmer. Without a layer-by-layer map, whose job is it to fix the bug?
3. Could your own brain be seen as a layered computational system — intention, specification, execution — or is there something about thinking that refuses to be a cake of rules?