⚛️ quantum physics

A Survey of Quantum Programming Languages

This paper introduces a classification framework to survey and compare ten popular quantum programming languages, identifying key challenges for their future design in light of recent breakthroughs in quantum computing.

Original authors: Quan Do, Hersh Gupta, Xiyuan Cao, Aarav Pabla, Pranav Singamsetty, Evan O'Grady, Keli Huang, Jens Palsberg

Published 2026-06-26

📖 5 min read🧠 Deep dive

CC BY 4.0

Original authors: Quan Do, Hersh Gupta, Xiyuan Cao, Aarav Pabla, Pranav Singamsetty, Evan O'Grady, Keli Huang, Jens Palsberg

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine you are trying to build a house, but instead of using standard bricks and wood, you are building with "quantum bricks" that can exist in two places at once. To do this, you need a set of blueprints and a language to tell the construction crew exactly what to do.

This paper is a survey of the "languages" programmers use to write instructions for these quantum computers. The authors, a team from UCLA, wanted to figure out which languages are the best tools for the job. They didn't just look at the manuals; they actually built the same three complex structures (algorithms) using ten different languages to see how easy or hard each one was.

Here is a breakdown of their findings using simple analogies:

1. The Goal: Building Quantum Structures

The team chose three specific "construction projects" to test the languages:

Shor's Algorithm: Think of this as a master lock-picking tool. It's designed to break down huge numbers into their prime factors (like taking a giant Lego tower apart to find the specific bricks used). This is famous because it could theoretically break current internet security.
Hamiltonian Simulation: This is like simulating a complex weather system or a chemical reaction. The goal is to predict how a group of tiny particles will move and interact over time. They tested two different ways to do this:
- Trotterization: Like taking a long walk by taking many small, steady steps.
- LCU (Linear Combination of Unitaries): Like taking a shortcut by combining several different paths at once, but it requires a bit more math to set up.

2. The Framework: How They Judged the Languages

To compare the ten languages (like Cirq, Qiskit, Q#, Silq, etc.), the authors created a "report card" with three main categories:

The Programming Model (The Blueprint Style):
- Embedded: Imagine you are writing a recipe (the classical computer part) and, inside that recipe, you are writing a separate, detailed instruction manual for a robot (the quantum part). You have to switch hats between being a chef and a robot programmer. Most current languages work this way.
- Hybrid: Imagine a kitchen where the chef and the robot are on the same team, speaking the same language. You can tell the robot to chop a vegetable and then immediately tell the chef to stir the pot, all in one continuous flow. This is smoother but harder to build.
Expressiveness (The Toolbox):
Does the language have the right tools to make the job easy?
- Pauli Manipulation: Does it have pre-made "Lego bricks" for the specific physics math needed, or do you have to build the math from scratch?
- Classical Data Encoding: Can it easily turn normal numbers into quantum states?
- Quantum Integers: Can it do math with "quantum numbers" (numbers that are made of qubits) just like we do math with normal numbers?
- Dynamic Allocation: Can the language grab a new tool (qubit) from the shelf only when you need it, and put it back when you're done, without you having to count exactly how many tools you'll need beforehand?
Safety (The Guardrails):
- Type Safety: Does the language stop you from trying to use a hammer on a screw? It checks your code before you run it to make sure you aren't making silly mistakes.
- Initialization Safety: In quantum computing, if you reuse a "dirty" tool (a qubit that was used before), it might mess up your new project. A safe language automatically cleans the tool (uncomputes it) so it's fresh and ready to use again.

3. The Results: No Perfect Tool

The team wrote the same programs in ten different languages (a mix of industry tools like Google's Cirq and Microsoft's Q#, and academic tools like Silq).

The Big Finding: There is no "perfect" language yet.
- Some languages are great at safety (like Silq, which automatically cleans up its tools) but lack some of the fancy math shortcuts.
- Some languages are great at math shortcuts (like CUDA-Q or Cirq) but require the programmer to be very careful about how they manage their tools.
- Some languages are "Hybrid" (mixing classical and quantum smoothly), while others are "Embedded" (keeping them separate).
The "Lines of Code" Test: They counted how many lines of code were needed to build the same structure in each language.
- Q# and Silq were very concise (fewer lines) for some tasks.
- PyQuil and CUDA-Q sometimes required more lines because they had to manually build things that other languages did automatically.
- Interestingly, the "LCU" method of simulation always required more code than the "Trotterization" method, regardless of the language.

4. The Conclusion

The paper concludes that while we have many languages to choose from, none of them have everything we need.

If you want safety, you might lose some ease of use.
If you want powerful math tools, you might have to manage the memory (qubits) yourself.

The authors hope this survey helps future language designers build a "Swiss Army Knife" language that has the best safety, the best math tools, and the smoothest workflow, making quantum programming accessible to everyone, not just physics experts.

In short: Quantum programming is like learning to drive a new type of car. Right now, we have ten different models (languages). Some have great brakes (safety), some have powerful engines (expressiveness), but none of them have the perfect combination of features yet. This paper is the first step in figuring out what that perfect car should look like.

Technical Summary: A Survey of Quantum Programming Languages

Problem Statement

As quantum hardware scales toward systems with over a thousand qubits, the reliance on high-level, general-purpose, executable programming languages to express algorithms, verify correctness, and integrate quantum subroutines into classical software systems is increasing. While a diverse ecosystem of quantum programming languages has emerged over the last decade, existing surveys often predate currently active tools or fail to compare concrete implementations of common tasks. There is a lack of systematic, empirical comparison across languages regarding their programming models, expressiveness, safety features, and performance on representative workloads.

Methodology

The authors propose a three-dimensional classification framework to evaluate quantum programming languages:

Programming Model: Distinguishing between Embedded languages (where quantum programs are data structures built within a classical host) and Hybrid languages (where classical and quantum operations are seamlessly interleaved at a single level).
Expressiveness: Evaluating support for four key constructs: Pauli manipulation (types, algebra, exponentiation), encoding of classical data (state preparation, block encoding), quantum integers, and dynamic allocation of qubits.
Safety: Assessing static type safety of quantum code and initialization safety (ensuring clean deallocation and "automatic uncomputation" of temporary qubits).

Using this framework, the authors surveyed ten actively maintained, open-source languages (eight from industry: Cirq, CUDA-Q, Guppy, PennyLane, PyQuil, Q#, Qiskit, Qualtran; and two from academia: Qrisp, Silq).

To provide empirical data, the authors implemented 50 benchmark programs across these languages. The workloads included:

Shor's Algorithm: Factoring an integer $N=21$ .
Hamiltonian Simulation: Simulating two distinct Hamiltonians (Transverse-Field Ising Model and Heisenberg isotropic chain) using two different algorithmic approaches: Trotterization and Linear Combination of Unitaries (LCU).

The study measured program size (lines of code), compilation/execution time, and correctness against a classical baseline. All code and testing harnesses are available as an open-source artifact.

Key Contributions

Classification Framework: The introduction of a structured framework (Programming Model, Expressiveness, Safety) to categorize and compare high-level quantum languages.
Empirical Benchmark Suite: The implementation of 50 benchmark programs and an automated cross-language testing harness. This includes the first side-by-side comparison of Shor's algorithm and Hamiltonian simulation (via Trotterization and LCU) across ten diverse languages.
Conceptual and Experimental Analysis: A synthesis of findings that highlights common design patterns, points of friction, and specific trade-offs. For instance, the paper demonstrates that while hybrid languages offer seamless control flow, embedded languages often provide clearer separation of concerns. It also quantifies the code size overhead of LCU compared to Trotterization across all languages.

Results

No Single Dominant Language: The survey concludes that no single language possesses all desirable characteristics of expressiveness and safety.
- Hybrid languages (e.g., CUDA-Q, Guppy, Q#, Silq) generally offer better integration of classical and quantum control flow but vary in their support for Pauli algebra and initialization safety.
- Embedded languages (e.g., Cirq, Qiskit, PennyLane) enforce a clear separation between host and quantum execution but often require more boilerplate for interleaved logic (e.g., while_loop constructs).
Expressiveness Gaps:
- Pauli Manipulation: Native support for Pauli types and algebra (found in Cirq, CUDA-Q, PyQuil, Qiskit, Qrisp) significantly reduces code size for Hamiltonian simulation compared to manual implementation.
- Quantum Integers: Only Qualtran, Qrisp, and Silq natively support quantum integers, which simplifies the modular exponentiation in Shor's algorithm. Other languages required workarounds like permutation matrices.
- Dynamic Allocation: Guppy and Silq fully support dynamic qubit allocation based on mid-circuit measurements, whereas others offer only partial support or require static allocation.
Safety: Silq and Qrisp stand out for enforcing initialization safety (automatic uncomputation), ensuring temporary qubits are cleanly deallocated. Silq and standalone languages like Q# provide robust static type checking.
Performance: Execution times varied significantly, often due to compilation overheads or specific implementation choices (e.g., permutation matrices vs. arithmetic gates). However, all languages demonstrated the ability to execute the benchmarks with reasonable times, validating their utility for experimentation.

Significance

The paper claims significance by providing a rigorous, reproducible methodology for evaluating quantum programming languages that moves beyond theoretical descriptions to concrete implementation comparisons. By focusing on Shor's algorithm and Hamiltonian simulation—two theoretically central and practically important workloads—the authors identify specific challenges for future language design. The findings suggest that future languages must strive to unify the strengths of current ecosystems: the seamless control flow of hybrid models, the declarative power of Pauli manipulation, the convenience of quantum integers, and the safety guarantees of automatic uncomputation. The authors position their classification framework and benchmark suite as tools to guide the development of next-generation quantum programming languages.