In Sight Developers: Quantum Programming: Speaking the Language of Qubits

Quantum software tools are evolving and will soon make quantum computing easily accessible. With tools like Qiskit and Cirq, anyone can begin exploring the quantum world, experiment with algorithms, and contribute to a rapidly evolving field.

Quantum programming is rewriting the rules of computation in the technology world. While traditional computers process bits as 0s and 1s, quantum computers use qubits, harnessing the properties of quantum mechanics. This new model opens doors to solving problems classical computers struggle with, such as complex simulations and cryptography. As the field matures, quantum programming languages and tools are evolving, making it increasingly accessible for tech enthusiasts, programmers, and students.

Quantum programming languages: An overview

Quantum programming languages are designed to express quantum algorithms and control quantum hardware. Unlike classical languages, they must handle superposition, entanglement, and measurement. Some of the most prominent quantum languages include:

Qiskit: Developed by IBM, Qiskit is Python-based and widely used for building and running quantum circuits.

Cirq: An open source Python library from Google, Cirq focuses on designing, simulating, and running quantum circuits; it is particularly suited for near-term quantum hardware.

QuTiP: A toolbox for simulating quantum systems, this language is useful for research and education.

Q#: Created by Microsoft, Q# is a standalone quantum language integrated with the Quantum Development Kit.

Other notable languages are PyQuil (Rigetti), Strawberry Fields (Xanadu), and Ocean (D-Wave), each of which targets specific hardware or quantum computing models. These languages make quantum programming more accessible, abstracting complex physics and allowing programmers to focus on logic and algorithms.

Coding with Qiskit and Cirq

To illustrate quantum programming, let’s examine basic examples with Qiskit and Cirq. Both frameworks let you define quantum circuits, run simulations, and analyse results. While their syntax differs, the underlying ideas are similar. Example 1: Creating a quantum circuit in Qiskit



Measurement results: {0: 513, 1: 487}

In this output, the measurement results show approximately equal counts for 0 and 1, reflecting the probabilistic nature of quantum measurement after applying a Hadamard gate to the qubit. The slight difference in counts is due to statistical variation over 1000 repetitions, as expected from an ideal quantum simulation.

In Cirq, the approach is similar — to define a qubit, apply a Hadamard gate, and measure. The result is a histogram of measurement outcomes, showing the quantum nature of computation.

Beyond Qiskit and Cirq, other languages offer unique features, but the essential building blocks—creating circuits, applying gates, and measuring—remain central.

Simulators and emulators: Testing code on classical computers

Access to real quantum hardware is limited and often expensive. Simulators and emulators bridge the gap by allowing quantum code to be tested on classical computers. Simulators model ideal quantum behaviour, while emulators may introduce noise to mimic real hardware.

Both Qiskit and Cirq come with built-in simulators. For example, the code snippets above use Qiskit’s qasm_simulator and Cirq’s simulator. These tools help programmers develop and debug algorithms before deploying them on actual quantum processors.

Here’s an example of noisy simulation in Cirq:



When you run the above Cirq code with the depolarising noise using the DensityMatrixSimulator, you will get an output like this:

Noisy measurement results: {0: 545, 1: 455}

This output shows the histogram of measurement results for the qubit after 1,000 repetitions, where the key ‘0’ corresponds to measuring the qubit in the |0⟩ state and ‘1’ to the |1⟩ state. The results will vary slightly with each run due to the inherent randomness and simulated noise. This example introduces depolarising noise, offering a more realistic preview of what might happen on actual quantum devices.

Algorithm design: Thinking quantum

Quantum algorithms differ fundamentally from classical ones. They exploit superposition, entanglement, and interference to solve problems in new ways. When designing quantum algorithms, consider:

Parallelism: Qubits can represent multiple states, enabling massive parallel computation.

Entanglement: Qubits can become correlated in ways impossible for classical bits, allowing unique operations.

Measurement: Reading a qubit collapses its state, so algorithms must be carefully structured to get useful results.

Classic examples of quantum algorithms include Shor’s algorithm for factoring, Grover’s search, and the Deutsch– Jozsa algorithm. Even simple routines like the quantum random number generator highlight the unique logic needed in quantum programming.

Debugging and error handling in quantum code

Debugging quantum programs is fundamentally different— and significantly more challenging—than debugging classical software. In the classical world, a developer can pause execution, inspect the values of variables using a print statement or a debugger, and resume. In the quantum realm, the laws of physics intervene. Due to the ‘observer effect’, measuring a qubit to check its state collapses its superposition to a definite 0 or 1, effectively destroying the quantum information you intended to inspect. This makes the standard ‘breakpoint and watch’ approach impossible on real hardware.

The challenge of ‘blind’ execution

When running on actual quantum processing units (QPUs), the code executes as a ‘black box’. You prepare the state, run the circuit, and get a probabilistic distribution of results. If the output is wrong, you cannot easily determine if the error stems from a logic bug in your algorithm or quantum noise (decoherence and gate errors) inherent to the hardware.

To address this, researchers and developers currently rely on a multi-layered approach to debugging.

Classical simulation and state vector inspection: The first line of defence is the simulator. Since simulators (like Qiskit’s Aer or Cirq’s simulator) run on classical hardware, they are not bound by quantum collapse. They allow developers to peek at the ‘state vector’—the mathematical description of the qubits’ amplitudes—at any point in the circuit without destroying it. Tools like the Qiskit debugger or IDE extensions allow for ‘snapshotting’ the state vector to visualise the Bloch sphere (a geometric representation of qubit states) step-by step. This verifies the logic of the algorithm in an ideal, noisefree environment.

Quantum assertions: Just as classical code uses ‘assert’ to verify conditions, quantum programming is adopting quantum assertions. These are specific checks designed to verify properties of a quantum state without fully collapsing it. For example, if an algorithm dictates that two qubits should be entangled, a developer can apply a specific measurement that checks parity without revealing the individual values. If the assertion fails, the program halts, signalling a logic error.

Noise modelling and error mitigation: Once logic is verified, the challenge shifts to hardware errors. Noisy Intermediate-Scale Quantum (NISQ) devices are prone to bit-flips (0 turning into 1) and phase-flips. To debug this, developers use noise models. By importing real calibration data from a backend (e.g., FakeProvider in Qiskit), one can simulate how the circuit should behave on specific noisy hardware.

If the simulation matches the real hardware output, the issue is noise, not logic. To handle this, we employ quantum error mitigation techniques. Unlike full error correction (which requires thousands of physical qubits to make one logical qubit), mitigation involves running the circuit multiple times with slight variations (such as zero noise extrapolation) to mathematically estimate and subtract the noise from the result. This statistical approach is currently the standard for extracting accurate results from imperfect machines.

Practical exercises: Writing your first quantum program

Let’s walk through how to build and run a basic quantum coin toss in both Qiskit and Cirq.

Quantum coin toss in Qiskit





Note: The exact numbers will vary each time you run the simulation, as quantum randomness ensures that the counts of heads (0) and tails (1) are close but not necessarily equal for 100 repetitions. Both examples show how a quantum computer can simulate a fair coin toss, with results fluctuating due to quantum randomness.

The evolution of quantum software tools

The trajectory of quantum software has moved at breakneck speed, evolving from low-level hardware control to highlevel abstraction in less than a decade. Understanding this evolution is crucial for appreciating how accessible the field has become.

Phase 1: The assembly era (QASM): In the early stages of quantum computing, programming was akin to writing Assembly language. Researchers wrote OpenQASM (quantum assembly language), specifying instructions at the physical pulse level. A programmer had to know exactly which physical qubit on the chip was connected to another to perform a CNOT gate. This required deep knowledge of microwave physics and hardware topology, creating a massive barrier to entry.

Phase 2: The SDK and circuit era: The release of IBM Qiskit (2017), Google Cirq, and Microsoft Q# marked the democratisation of quantum coding. These software development kits (SDKs) introduced the concept of the ‘quantum circuit’ as a software object. Developers could now write Python code to arrange gates abstractly. Crucially, these tools introduced the transpiler (or compiler). The transpiler acts as a translator, taking an abstract circuit and mapping it to the physical constraints of a specific device, automatically handling the routing and optimisation of gates. This allowed computer scientists to focus on algorithms (like Grover’s or Shor’s) without worrying about the underlying qubit connectivity.

Phase 3: Hybrid orchestration and kernels: We are currently transitioning into an era of hybrid quantum-classical computing. It is now understood that quantum computers will not replace classical ones but will act as accelerators (similar to GPUs). Modern tools like Qiskit Runtime and AWS Braket Hybrid Jobs allow for the seamless interleaving of classical and quantum instructions. For example, in Variational Quantum Eigencovers (VQE)—an algorithm used in chemistry—a classical CPU optimises parameters while the QPU calculates energy states. The software stack now manages this loop automatically, reducing latency and enabling ‘serverless quantum computing’, where developers submit a job without provisioning the underlying infrastructure.

Phase 4: The future – domain-specific abstraction: The next frontier, already visible with tools like Classiq and Horizon quantum computing, is moving beyond gates entirely. In this emerging paradigm, a developer might define a highlevel problem—such as “optimise this financial portfolio” or “simulate this molecule”—and the software stack will automatically synthesise the optimal quantum circuit to solve it. This shift mirrors the evolution from C++ to Python/SQL, where the ‘how’ is abstracted away, leaving the user to focus entirely on the ‘what’.

Quantum programming is an exciting frontier, blending physics, mathematics, and computer science. Whether you’re a student, a seasoned coder, or simply curious, now is the perfect time to learn the language of qubits and shape the future of computing.

References

* https://www.bluequbit.io/blog/quantum-programminglanguages

* https://quantumai.google/cirq/start/basics

* https://www.spinquanta.com/news-detail/the-ultimateguide- to-quantum-algorithms

* https://quantumai.google/

* https://learn.microsoft.com/en-us/azure/quantum/qsharpoverview

* https://qiskit.github.io/qiskit-aer/

* https://qosf.org/

By: Dr Magesh Kasthuri and Dr Anand Nayyar

Dr Magesh Kasthuri is a PhD in artificial intelligence and the genetic algorithm. He currently works as a distinguished member of the technical staff (master) and chief architect at Wipro Ltd. This article expresses his views and not of the organisation he works in.

Dr Anand Nayyar is a PhD in wireless sensor networks and swarm intelligence. He works at Duy Tan University, Vietnam, and loves to explore open source technologies, IoT, cloud computing, deep learning, and cyber security.

Credit: Dr Magesh Kasthuri and Dr Anand Nayyar