Read part 1 of the interview here, where we trace Horizon Quantum’s journey through the CEO’s lens.
Horizon Quantum founder and CEO Dr Joe Fitzsimons unpacks the challenges of building hardware-agnostic software for the quantum industry. He explains how quantum algorithms are not inherently tied to modalities, distinguishes that from the near-term constraints of noisy hardware and fault-tolerance work, and how Horizon Quantum is trying to abstract away much of the complexity for developers.
He takes us through the company’s layered software stack — Hydrogen, Helium, Beryllium (the Triple Alpha platform) — as well as the logic behind the naming, and the rationale behind assembling its own hardware testbeds. On the subject of quantum advantage, Fitzsimons argues that quantum computing as a field is entering a grey zone: no longer purely speculative, but not yet at the point where its advantages are universally obvious.
Are quantum algorithms tied to hardware?
Coming from classical computing, I often hear that algorithms, circuits and hardware are intimately connected in quantum computing. Is that right?
I would strongly disagree with that. The main quantum algorithms that have been studied since the mid-to-late 1990s, such as Grover’s algorithm and Shor’s algorithm, are structured quantum algorithms. They are not tied to hardware. Obviously, you need quantum mechanical hardware to implement them, and if certain qubits can only talk to certain other qubits, you need to figure out how to shuffle information around. But the algorithm itself has nothing to do with that.
Where people have started to talk about algorithms being tied to hardware is in two places. The first is probably what you have encountered: hardware-efficient ansatzes in variational quantum algorithms, or NISQ (noisy intermediate-scale quantum) algorithms. Instead of constructing a quantum algorithm, the general approach is to guess the broad structure of a quantum circuit and then train it with Stochastic Gradient Descent (SGD). You tune the parameters to get closer to a good answer, much like training a neural network.
An ansatz is your guess at the program: what the circuit looks like before the parameters are set – your “guess” at the structure of the circuit. There has certainly been a movement toward guesses that line up with the hardware available. That is fine, but we do it because no one really knows whether one ansatz is much better than the others, and because we do not have error correction. If you have to shuffle information around too much, it picks up too much error. So you may prefer a worse initial guess that is efficient on today’s hardware over the best initial guess that is overly complicated to implement on a real hardware system today.
The other place where hardware co-design appears is fault tolerance and error correction, with hardware being designed to implement particular error-correction codes.
So both forms of hardware dependence can be tied to the absence of a fault-tolerant quantum computer?
The second category is really how you get to a fault-tolerant quantum computer. You have to figure out a fault-tolerance scheme, and that includes several things. It includes the decoding algorithm, which is a classical algorithm that takes the measurement results used to detect errors and determines what error occurred and how to correct it. Along with that, you need procedures for extracting that information and for implementing logic gates in those error-correction codes.
Inside Horizon Quantum’s software stack
When you design for Horizon’s software, what type of quantum computer are you taking into account?
Our tools are designed to be hardware-independent from the developer’s perspective. The developer does not necessarily need to know in advance which kind of hardware system they are writing code for. They can implement algorithms at a high level of abstraction and then compile them down to target different hardware systems.
If they prefer, they can dive directly into the hardware level. For example, for a superconducting system, we have the ability to specify the shapes of the microwave pulses that go to the processor. That is the system-specific end. But our languages — Hydrogen, Helium and Beryllium — are all hardware-agnostic.
Beryllium is the highest-level language, almost like the equivalent of C++?
Something like that. Syntactically, it may be a little simpler than C++, but it is an object-oriented programming language. We have built up our programming languages in terms of capability. We started with Hydrogen, which you can think of as a portable assembly language. It can express everything a mature quantum computer could, but we can make it run on today’s systems using different techniques.
Hydrogen allows us to do more than circuits. Quantum computers can potentially support more general control flow, just as conventional computers can have loops, ‘if’ statements and similar structures. That’s where Turing-completeness comes in — circuits cannot express a computation of indefinite length. Some computations exist where you cannot decide in advance how long they will take, so you cannot express them with a single circuit. You can only express them as families of circuits simulated up to a certain time.
That is why we built Hydrogen: to express a more general form of computation that takes us beyond quantum circuits. Hydrogen also lets us get to Helium, an imperative language, something like a quantum version of BASIC. Helium then lets us get to Beryllium. If we had to jump straight from Beryllium to code running on a particular system, it would be more challenging. We need intermediate steps to leverage ourselves forward.
Hydrogen being an assembly language suggests manipulating memory registers directly depending on the architecture. How does that work across different types of hardware?
In quantum computing, most programming is more like microcode than assembly language. It is really low-level. You are saying: rotate this qubit by this angle; implement the equivalent of an XOR gate between these two qubits. That is how you build quantum circuits, almost like logic circuits.
Obviously, that is not how modern software development works.
If you had to write a modern piece of software, how would you get to ChatGPT if you had to write everything with NAND gates? It is basically impossible. The only way to get there is to build intermediate tools all the way up, which is what we have been doing.
We see it as trying to speed-run the history of computer science. Microcode is solidly a 1950s technology. BASIC is 1960s. Object-oriented programming is late 1970s or early 1980s. That is the track we have been on. We are trying to get to the point where we can go from modern conventional programming languages to an automatically accelerated implementation on quantum computers. That is the second half of the journey for us. We have done the first three steps; now we still have another 40 years of computer science to get through.
Why Hydrogen, Helium, Beryllium — and Carbon?
Triple Alpha is the platform developers will use?
Triple Alpha is our platform. We have a web-based integrated development environment that allows developers to use our programming languages — Hydrogen, Helium and Beryllium — to develop applications for quantum computers. You can compile them down, deploy them and run them on a range of different types of processors. The system is in early access at the moment, so we primarily work with hardware companies.
What is the logic behind the names Hydrogen, Helium and Beryllium?
It is also why the platform is called Triple Alpha. Naming was much harder than we anticipated. We knew we would need different names for different levels. The reason we went with this scheme is that it reflects how carbon is formed.
In stars, hydrogen atoms come together, and eventually you get to helium. The helium nucleus is also called an alpha particle. Two helium nuclei come together to form beryllium, and then beryllium and helium come together to form carbon. That process is where all life comes from, and it is called the triple-alpha process because it involves three helium nuclei coming together. Hence Triple Alpha.
Carbon is what we call our next layer up: being able to go from classical programming languages to quantum-accelerated algorithms.
Building hardware testbeds
Horizon assembled its own hardware in-house rather than buying a complete system. Why?
We put together our first quantum computer from parts. We did not build the processor: the processor is from Rigetti Computing, the control systems come from Quantum Machines, and the fridge, which is quite distinctive, comes from Maybell. Most superconducting quantum computers have suspended cylinders; this one is more like a giant safe.
We put it together from parts because there is an emerging open stack for superconducting quantum computing. There are now many options for processors, control systems and refrigerators that are reasonably compatible with one another, so you can piece together a system without having someone build the entire thing for you.
The advantage is that we can swap components in and out. If we want to put other processors in the fridge, we can. The fridge is large enough to house many more than one processor. If we want to change the control systems, we can disconnect them from the current processor and plug in another controller from a different manufacturer. Having this testbed lets us tightly integrate our software with control systems.
Would you have to do that for each individual modality?
Not really. There is a lot of commonality in control systems between modalities. Apologies if this is offensive to anyone working on experimental efforts, but in my view, you can very coarsely categorise quantum computers into two buckets. One includes systems that need to be very cold and require microwave control. These tend to be engineered or manufactured qubits, such as superconducting qubits, silicon spins and quantum dots.
The other bucket consists of more natural qubits, such as ions, atoms or photons. For many of these, you need to care about optical stability because you use light to control them. You often need high vacuum because you are isolating individual ions or atoms and trying to prevent them from bumping into other atoms in the same space.
That creates a different set of considerations, both for control systems and for facilities and operations. For us, it is useful to have an exemplar of each category. With the addition of the IonQ system, we can learn lessons across both categories. Almost every kind of quantum computer fits somewhere across those two categories.
Are you assembling the IonQ system yourself?
No. The first superconducting system was pieced together from components and is more modular. The IonQ system is entirely from IonQ. We are looking forward to getting it up and running and starting to integrate our software stack.
So as a completely dispassionate third party, any bets on which modality is going to win the race?
It’s like being asked to pick your favourite child –- even if you have one, you should never say.
The grey zone before quantum advantage
Different groups define quantum advantage differently, and some claimed advantages are very specific or can be replicated classically. What does quantum advantage mean to you?
There have been five or six claims in the last year or so to have achieved a quantum advantage, and they are still the subject of debate in the research community. The way I see this is like computers playing chess or Go.
For most of human history, humans were better than machines at those games. In the 1980s and 1990s, you could expect to beat your computer at chess. Then IBM Deep Blue beat Kasparov. On that day, was it clear that machines were better than humans at chess? Not necessarily. There were claims that Kasparov had an off day, or that maybe someone was helping the machine. For a while, it was not certain.
The same thing happened with AlphaGo. Go was viewed as one of those games that would be impossible for machines to get good at. That turned out not to be the case. When AlphaGo beat Lee Sedol, it raised the question: computers are clearly good now, but are they better than the best human player? It was not clear yet. A few months later, it became more clear as AlphaGo claimed its next crown. Today it seems unimaginable that humans would beat the best computer programs at chess or Go ever again – it doesn’t get better for humans from here (I mean that strictly in terms of beating computers at chess and Go).
Once you get to the other side, the gap just widens.
I expect the same with quantum advantage: we are now in a period where it is no longer black and white. Maybe quantum computers can beat conventional computers at some things; maybe the evidence is not fully there at the moment. But it is only going to get more convincing from here.
Probably before too long, we will be out the other side of that grey period, and it will be clear that conventional computers cannot beat quantum computers at certain problems. The gap will only widen. But we are in the grey area around the crossover point, and it is very hard to say exactly when you cross the line. I do not think anyone will ever know exactly when it happened.
