"Testing shows the presence, not the absence, of bugs." — Edsger Wybe Dijkstra
If I ask you whether programming is fundamentally science or mathematics, many people would say mathematics. It feels like it — we use variables, functions, operators, and assignments, which all look like math.
But if we go down to history, we'll see that programming started as a vision to make it mathematical — and then, fortunately or unfortunately (you decide), it transformed into a science.
Maybe this is why we study Computer Science and not Computer Mathematics.
The real question is: Why?
Why is programming a science and not maths?
And could programming have been better if it had stayed mathematical?
You may not get the answer to all of these questions in this article — some are still a "black hole" for us. But you'll understand why structured programming, the backbone of modern software engineering, leans on science instead of math.
The Beginning: Programming with Punch Cards
In the early days, programming was done on punch cards. People at that time had no idea about the future of programming — they were simply trying to reduce the complexity of mathematical calculations.
Edsger Wybe Dijkstra lived in this era. A brilliant mind, he excelled in mathematics, physics, chemistry, and biology during high school. He later became one of the very first programmers, working with large computers, punch cards, and then core-level assembly languages.
The problem of that time? Programs were monolithic and tightly coupled.
A single error could break the entire application, and even a small change in the problem meant rewriting huge amounts of code.
Dijkstra's Vision: Programming as Mathematics
Dijkstra wanted programming to be like mathematics, where we rely on already-proven lemmas, theorems, and corollaries.
In mathematics, proofs build on previous truths:
- We don't re-prove the basics every time.
- Lemmas (already true statements) help prove theorems.
- This recursive building of truths leads to powerful results like integration, differentiation, gradient descent, backpropagation, and more.
Dijkstra's vision was to prove fundamental algorithms, which would then serve as theorems, making larger algorithms provable more easily.
The Roadblock: GOTO
In mathematics:
- Sequential statements can be proved by enumeration.
- Iterations can be proved using mathematical induction.
But programming in those early days used GOTO — an instruction that transfers control anywhere in the program. This broke the possibility of enumeration and induction-based proofs.
The solution was to restrict GOTO. That's how if/else, loops, and breaks were born — controlled ways of transferring control.
This was a breakthrough. It gave us the ability to write modular, independent blocks of code instead of monolithic programs.
But… the proofs never came.
Where Science Entered
Even though Dijkstra's mathematical proofs never materialized, his ideas weren't wasted. The removal of GOTO gave us structured programming — and with it, a way to build modular, testable code.
Here's where science took over:
- In mathematics, we prove something to be true forever.
- In science, we don't prove truth — we prove falsehood.
- If after countless experiments we can't disprove a theory, we accept it as true (for now).
For example: Newton's law of gravitation
was accepted until Einstein's relativity disproved it.
Programming works the same way:
- We test submodules with unit tests.
- If a test fails, we fix the module.
- If it passes thousands of tests, we assume it works.
- Then we combine modules and test again at a higher level.
This is science at work: truth until falsified.
The Conclusion
Fundamentally, programming is science, not mathematics.
Dijkstra's vision of mathematical programming never fully came true. We don't know if it would have been better — maybe, maybe not.
But what we do know is this:
- Programming behaves like science.
- We test, disprove, and iterate.
- We can't prove code to be true for all cases, only that it hasn't failed yet.
And that's why we say:
Programming is science. It is true… until we find a bug.
References
- Martin, R. C. (2017). Clean Architecture: A Craftsman's Guide to Software Structure and Design. Prentice Hall.
Top comments (0)