Ernest
A quantum compiler that ran DOOM, then learned Fortran.
Ernest is a compiler for quantum hardware, written from scratch in C99. It reads OpenQASM 3, runs it through a pass manager and a SABRE routing pass, lowers it to a vendor's native gate set, and submits it to a real superconducting chip sitting in a refrigerator colder than deep space. No Python. No vendor SDK doing the hard part. Just text in and qubits out, the same way every other compiler I write works, except the target is a machine that does not obey the rules the rest of computing runs on.
It is named after Ernest Rutherford, of Brightwater, who fired alpha particles at gold foil in 1909, watched a few come back, and worked out that atoms have nuclei. He trained more Nobel laureates than any supervisor in history and never wrote a wavefunction himself. I have so far trained zero Nobel laureates, but the spirit is the same.
DOOM, On Actual Quantum Hardware
The thing people remember is the DOOM. You can encode an image as the amplitudes of a quantum state, a technique called QPIE, where the brightness of each pixel becomes the probability of measuring that basis state. Read the TITLEPIC lump out of a real DOOM.WAD, encode it, send the circuit through Ernest to a chip, measure it sixteen thousand times, and the picture comes back out of the statistics. Noisier than the original, because the hardware is honest about its own limits, but unmistakably DOOM, reconstructed from the measurement record of a quantum computer in Virginia.
It is not "running DOOM" in the sense the game runs on a calculator. There is no game loop. Running the actual code would need orders of magnitude more qubits than exist. But the pixels are real id Software pixels, the substrate is real superconducting silicon, and the compiler in the middle is mine. The honest version of that is more interesting than the hype version anyway, so it is the one I tell.
Then It Learned Fortran
The quantum software world is built almost entirely in Python, which is a strange choice for a field whose entire stated purpose is accelerated mathematical computation. The mathematics that actually runs the world has been written in Fortran for sixty years. Every climate model, every reactor physics code, every quantum chemistry package. So I wired my Fortran 77 compiler into Ernest, and started compiling Fortran down to quantum circuits on real hardware.
Then I pointed it at SLATEC, the Sandia and Los Alamos mathematical library that quietly underpins half of scientific computing, and got routines from it executing on a quantum backend. It runs the parts that are quantum-expressible and fails exactly at the I/O boundary, which is not a bug. It is the cleanest demonstration I have of where quantum computation actually begins and ends, drawn with the scientific canon as the measuring stick. A quantum computer is not an I/O machine. It is an amplitude-transformation machine, and the moment a SLATEC routine reaches for the outside world, it walks straight into the wall between the quantum and the classical, and my pipeline maps that wall in real code.
Why
Partly because the substrate for quantum computing does not really exist yet and will not for a while, and it seems worth building the parts that take it seriously ahead of the hardware, the way the operating systems for the first mainframes were sketched out years before the machines they ran on were finished. Partly because a field whose whole purpose is mathematics deserves something sturdier than a notebook held together with library calls.
Mostly, though, I build things like this because I find them genuinely interesting and every one of them teaches me something I did not know when I started, which this time was how a superconducting chip actually behaves once you stop reading about it and start sending it circuits. None of this is my job, and that is the point. I am not doing it on a deadline or to satisfy anyone's roadmap, so I get to follow the question wherever it goes and ship the thing while it is still rough and half-finished, without anyone deciding whether that counts as a release. A work in progress is a perfectly good thing to put into the world when nobody is grading it, and most of what I have learned came out of exactly the messy, unfinished versions I would never have been allowed to publish anywhere that mattered.
The Code
Ernest is open source under Apache 2.0. github.com/Zaneham/ernest.