Computer science is often introduced through its most visible activity: programming. Write instructions, run them on a machine, fix what fails. That is part of the subject, but it is not an adequate description of it.
William Rapaport, emeritus professor of computer science and philosophy at the University at Buffalo, offers a more useful account:
“Computer science has two parents. It’s got a mathematical parent, and it’s got an engineering parent, and it’s really a cross between those two.”
This is more than a neat origin story. It explains why computer science can feel abstract in one lesson and stubbornly practical in the next. It also explains why studying only code is not enough. To understand computation, you need to learn both what is possible in principle and what works under real constraints.
One subject, two traditions
The mathematical parent asks questions such as:
- What can be computed?
- How much time or memory must a solution require?
- Can we prove that an algorithm is correct?
- Are some problems inherently harder than others?
The engineering parent asks a different, equally necessary set:
- How should the system be built?
- What happens when memory, time, bandwidth, energy, or money is limited?
- How does it behave when a component fails or an input is unexpected?
- Can another person operate, maintain, and trust it?
These are not rival descriptions of computer science. They discipline each other. Mathematics stops engineering from becoming guesswork. Engineering stops mathematics from remaining detached from the machines, organisations, and people through which computation has effects.
What mathematics contributes
Mathematics gives computer science a language for abstraction. An algorithm can be studied independently of a particular laptop, programming language, or processor. We can ask whether it terminates, whether its result is correct, and how its resource requirements grow as the input becomes larger.
That last question matters because a faster computer cannot rescue every slow method. In Ben Brubaker’s discussion of the boundaries of computer science, the theoretical computer scientist Cristopher Moore (opens a new tab) puts the point plainly:
“Mathematical problems have a fundamental structure which makes them qualitatively easier or harder to solve. It’s not a matter of how fast your computer is, and it’s not a matter of how clever you are.”
This is one reason students need mathematics. The aim is not merely to become quicker at calculation. It is to recognise structure: which details matter, which can be abstracted away, what kind of proof a claim requires, and where a problem’s difficulty actually lies.
Without that perspective, programming can become a sequence of local tricks. A program may work on the examples in front of us while leaving unanswered whether it will scale, whether it handles every valid case, or whether a better method is even possible.
What engineering contributes
An abstract algorithm does not have a user, a battery, a network connection, a deadline, or a maintenance budget. A real system does.
Engineering introduces constraint and consequence. A theoretically sound idea must be represented in hardware and software, connected to other systems, tested against failure, and made usable by people who did not design it. Those conditions expose questions that an abstract model may deliberately set aside.
This does not make engineering the less intellectual parent. Building often reveals the weakness of our assumptions. A system that is correct but unusably slow is not useful. A secure protocol implemented carelessly is not secure. A predictive model with impressive accuracy may still be unsuitable when its errors fall unfairly or its decisions cannot be examined.
Engineering makes ideas answer to reality. It turns “this should work” into a testable claim.
Computation as a scientific lens
Computer science also reaches beyond the study of manufactured computers. Researchers use computation to describe and investigate processes in physics, biology, economics, linguistics, and other fields. A physical system can be modelled as information changing over time. Evolution can be studied through search, variation, and selection. Networks can reveal shared structures in phenomena that otherwise look unrelated.
In that sense, you can view other sciences through computation. This does not mean reducing every discipline to software or pretending that domain knowledge is optional. It means asking a productive question: what becomes visible when we describe this process in terms of information, rules, states, and change?
The value of that lens depends on both parents. Mathematics supplies the formal model. Engineering supplies instruments, simulations, data, and encounters with the unruly details of the world. Neither alone is sufficient evidence that the model explains what it claims to explain.
Practice can produce theory
We often tell the history of science as a one-way journey: first a profound theory is discovered, then engineers find something useful to do with it. The history of computer science is less tidy. Practical machines have repeatedly made theoretical questions visible and urgent.
Scott Aaronson’s example in the Quanta article comes from thermodynamics. The second law of thermodynamics describes entropy tending to increase over time — a claim with enormous reach — yet the problem came into focus through efforts to understand and improve steam engines:
“It’s maybe the most fundamental thing that you can say about the evolution of the entire universe. And yet it’s not something that anyone thought of until they were building steam engines.”
The lesson is not that engineering always comes first. It is that practical and theoretical work form a loop. Building creates anomalies, limits, and questions. Theory explains some of them and identifies deeper boundaries. New engineering then tests those explanations under conditions the theory did not anticipate.
Computer science develops through the same movement. Real computers did not merely implement a completed theory of computation. They helped researchers see which questions about algorithms, efficiency, reliability, and interaction were worth asking.
Why you need to study both
If you study only the mathematical parent, you may learn elegant models without learning how assumptions fail in use. If you study only the engineering parent, you may learn to assemble working systems without understanding their deeper structure or limits.
A serious education in computer science therefore needs both habits:
- Abstract. Remove accidental details and identify the underlying problem.
- Reason. Make claims precise and test whether they follow from the model.
- Build. Turn the idea into something that operates under real constraints.
- Observe. Treat failures, performance, and user behaviour as evidence.
- Revise. Improve the model, the implementation, or both.
This is also why learning computer science cannot be reduced to memorising a programming language. Languages change. Tools become easier. Machines become faster. The durable education lies in understanding which problems computation can address, how to design a defensible solution, and what happens when that solution meets the world.
Rapaport’s two parents give us a useful standard for study. Ask of every topic: What structure is mathematics helping me see? What constraint is engineering making me confront?
Computer science lives in the conversation between those questions. That is precisely why both are worth studying.