---
title: "Computer science has two parents — Erkan Malcok"
description: "Computer science inherits abstraction from mathematics and practical constraint from engineering. To understand the subject, students need both."
date: "2026-09-02"
canonical: "https://erkanmalcok.com/articles/computer-science-has-two-parents/"
kind: "Opinion"
series: "computing-education"
tags:
  - "Computer science"
  - "Computing education"
---

# Computer science has two parents — Erkan Malcok

Why studying the subject means learning both what can be computed and how to make computation work.

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 in [Ben Brubaker’s Quanta
article](https://www.quantamagazine.org/does-computer-science-need-computers-20260828/):

> “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.

## What you will take away

By the end of this article, you should be able to:

- distinguish the mathematical and engineering traditions in computer science;
- explain why neither tradition is sufficient on its own; and
- use both perspectives to question how a computing topic is taught or built.

## 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](https://www.quantamagazine.org/does-computer-science-need-computers-20260828/),
the theoretical computer scientist [Cristopher Moore](https://www.santafe.edu/people/profile/cristopher-moore) 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](https://www.quantamagazine.org/what-is-entropy-a-measure-of-just-how-little-we-really-know-20241213/)
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:

1. **Abstract.** Remove accidental details and identify the underlying problem.
2. **Reason.** Make claims precise and test whether they follow from the model.
3. **Build.** Turn the idea into something that operates under real constraints.
4. **Observe.** Treat failures, performance, and user behaviour as evidence.
5. **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.

## Related reading

- [Teaching computing beyond syntax](/articles/teaching-computing-beyond-syntax/)
  considers what learners need beyond working code.
- [Debugging as a teachable habit](/articles/debugging-as-a-teachable-habit/)
  shows how engineering evidence can become a classroom routine.

## References

- [Ben Brubaker, "Does Computer Science Need Computers?" \(Quanta Magazine\)](https://www.quantamagazine.org/does-computer-science-need-computers-20260828/)
- [Ben Brubaker, "What Is Entropy?" \(Quanta Magazine\)](https://www.quantamagazine.org/what-is-entropy-a-measure-of-just-how-little-we-really-know-20241213/)
- [Cristopher Moore, Santa Fe Institute profile](https://www.santafe.edu/people/profile/cristopher-moore)