What Does Quantum Mechanics Have to Teach a Software Developer?
After spending most of my adult life thinking about software, I have accumulated a fairly comfortable mental model for what computation looks like. We have data. We have state. We have operations that transform that state. We have conditionals, loops, functions, objects, messages, events, threads, processes, and increasingly elaborate abstractions built on top of them. We've spent decades inventing better ways to organize those things.
Structured programming taught us to tame goto. Object-oriented programming taught us to organize state and behavior. Functional programming taught us to think in terms of transformations rather than mutable state. Distributed computing taught us that time and state become considerably less cooperative when there is more than one machine involved. I've spent enough years writing software that most of this feels intuitive.
And then there is quantum mechanics.
I understand enough about quantum computing to know that it isn't simply "a really fast computer." I understand the basic idea of qubits, superposition, entanglement, measurement, and quantum gates. But what I find most interesting isn't the possibility of building a faster computer. It is the possibility that the computational patterns themselves might be different. And that is a much more interesting question.
We Tend to Think of Computation as Manipulating State
The traditional programming model is wonderfully concrete.
Consider:
x = 5
x = x + 1
There is an x. It has a value. We perform an operation. It now has another value.
Even when we move into more sophisticated programming models, there is usually some recognizable notion of state being transformed.
A function takes inputs and produces outputs.
An object contains state and exposes operations on that state.
A database stores state and queries transform or retrieve representations of it.
A distributed system consists of many pieces of state attempting, with varying degrees of success, to agree about reality.
Even our algorithms tend to be described in terms of states and transitions between states.
That mental model is so deeply ingrained that it is easy to forget that we invented it.
It is not necessarily the only possible way to think about computation.
Quantum Computing Feels Different
The first thing that makes quantum computing uncomfortable to my software-development brain is superposition.
A classical bit is either 0 or 1.
A qubit isn't quite "both 0 and 1" in the way that phrase is usually interpreted. It is represented by a quantum state that can produce either result when measured, with probabilities determined by its amplitudes.
And then measurement changes what we can know about that state.
That is already weird.
But the really interesting part, to me, is what happens when we start composing these things.
Quantum gates don't simply say:
Change this variable from 0 to 1.
They manipulate amplitudes.
Operations can cause possibilities to reinforce one another or cancel one another out.
That's a very different computational metaphor.
Instead of thinking:
state → operation → new state
we might start thinking:
state → transformation of possibilities → interference → measurement
That feels less like traditional programming and more like manipulating a mathematical landscape.
And I can't help wondering whether there are programming patterns hiding in there that we haven't really learned to recognize yet.
What Would a Quantum Design Pattern Look Like?
We've spent enormous amounts of effort cataloging useful patterns in classical software.
Factory.
Observer.
Strategy.
Decorator.
Pipeline.
Map/reduce.
Recursion.
Memoization.
Actor.
Publish/subscribe.
These are abstractions for repeatedly useful structures in computation.
So what happens when the underlying computational substrate changes?
Would the equivalent of a design pattern in a quantum program look familiar?
Or would we discover things that have no particularly useful classical analogy?
That's the part I'd love to understand someday.
Perhaps there are quantum equivalents of concepts we already know.
Perhaps there are entirely new abstractions.
Or perhaps some of the things we regard as fundamental programming concepts—state, identity, sequence, causality—turn out to be artifacts of classical computation.
That last possibility is particularly intriguing.
Entanglement Is Especially Difficult to Think About
Entanglement is one of those concepts that I can explain reasonably well and still not feel that I understand.
Two quantum systems can have a combined state that cannot be described simply by describing each system independently.
For a software developer, that is almost offensive.
We like encapsulation.
We like independent objects.
We like being able to say:
Here is object A. Here is object B. They each have their own state.
Quantum mechanics says, essentially:
Not necessarily.
Sometimes the meaningful thing is the relationship between them.
That strikes me as potentially significant beyond quantum computers themselves.
We have spent a great deal of effort in software engineering trying to manage dependencies between components. We build interfaces, abstractions, contracts, message passing, dependency injection and all sorts of other mechanisms specifically so that components can remain reasonably independent.
Quantum mechanics suggests a computational world where relationships can be more fundamental than the individual pieces.
I have no idea what the software-engineering equivalent of that idea ultimately looks like.
But I'd like to find out.
And Then There Is Measurement
Another thing that seems profoundly strange from a programming perspective is measurement.
In ordinary software, looking at a variable doesn't fundamentally change the variable.
print(x)
isn't normally a destructive operation.
Quantum measurement is different.
The act of extracting certain information from a quantum system changes the state of that system.
That's fascinating from the perspective of computation.
We tend to treat information as something that can simply be inspected, copied, stored, transmitted and examined.
Quantum information puts limits on some of those assumptions.
The no-cloning theorem is a particularly interesting example: an unknown quantum state cannot simply be copied in the same way that we copy a classical bit.
Imagine discovering that x = y isn't merely an assignment operation with some implementation details—it is sometimes a physically impossible operation.
That forces you to reconsider what "data" actually means.
Maybe the Interesting Question Isn't "How Do I Program a Quantum Computer?"
Perhaps the better question is:
What concepts will we have to invent to program one naturally?
Early programmers had to think in terms of machine instructions.
Then we invented higher-level languages.
Then structured programming.
Then objects.
Then functional abstractions.
Then distributed and concurrent models.
Each abstraction allowed programmers to stop thinking about certain details and start thinking about higher-level structures.
Quantum programming may still be relatively primitive.
Maybe we're currently at the equivalent of assembly language.
We know how to manipulate the machine.
We know the mathematical rules.
We can construct algorithms.
But perhaps we haven't yet discovered the natural language of thought for quantum computation.
That is what I would really like to see.
A Few Things I'd Put on My "Someday" List
If I ever get a sufficiently large block of uninterrupted time—which is probably the real quantum phenomenon here—I would love to explore a few areas.
Quantum algorithms. Not just how they work, but what makes them fundamentally different from classical algorithms. Why do algorithms such as Shor's and Grover's work the way they do?
Quantum information theory. This seems like the deeper layer beneath the programming. What exactly is information when the underlying physical representation isn't classical?
Quantum logic. Classical logic assumes things like propositions having definite truth values. Quantum mechanics apparently gives us a different mathematical structure for reasoning about physical systems. That seems potentially very relevant to someone interested in programming abstractions.
Reversible computing. This one particularly appeals to the software engineer in me. Quantum operations are reversible, and reversible computation has some fascinating implications for how we think about algorithms, information and energy.
Quantum programming languages. I'd like to see how languages such as Q#, Qiskit, Cirq and others express quantum computation and, more importantly, what abstractions they are trying to provide.
Quantum circuits as programs. There is something conceptually beautiful about treating computation as transformations of a mathematical state rather than a sequence of instructions operating on mutable memory.
Topological quantum computing. This is probably getting far beyond my intended rabbit hole, but the idea that computation could be represented through topology rather than conventional state manipulation is exactly the sort of thing that makes me wonder whether we're looking at a fundamentally different computational paradigm.
And eventually, I'd want to circle back to the question that started all of this:
What are the quantum equivalents of software design patterns?
Maybe someone has already answered that question.
Maybe the answer is that the question doesn't make sense.
Or maybe we're still too early in the development of quantum programming to have discovered them.
The Part That Really Interests Me
After a career in software, I've become accustomed to thinking of computers as machines that manipulate symbols according to rules we define.
Quantum computing makes me wonder whether that description is backwards.
Perhaps computation is something more fundamental, and classical programming is merely one particular way of expressing it.
We happened to build our first computational abstractions around bits, memory, instructions and state transitions because that's what our physical machines gave us.
Now we're learning how to build machines whose behavior comes from an entirely different set of physical rules.
Maybe we shouldn't expect to simply port our existing mental models onto them.
Maybe the really interesting discoveries won't be faster versions of existing algorithms.
Maybe they will be new ways of thinking about computation itself.
That's the rabbit hole I'd like to explore someday.
Right after I finish all those other projects I've been meaning to get around to.