Quantum Programming & SDKs
Turning everything you've learned into code that runs on real or simulated hardware
By the end of this topic you'll be able to
Everything covered in the preceding tracks — states, gates, circuits, algorithms — has a direct, fairly literal translation into working code. Turning the mathematics into something you can actually run is the last step in making any of it feel real.
The major SDKs — Qiskit from IBM, Cirq from Google, PennyLane from Xanadu, and Braket from Amazon — all share essentially the same underlying model: build a circuit object gate by gate, run it either on a local classical simulator or on real cloud-accessible quantum hardware, and retrieve measurement statistics back.
A local simulator computes the exact state vector for small qubit counts, which is invaluable for learning and debugging, since you can check every intermediate step by hand against what the simulator reports before ever touching real, noisy hardware.
The choice between SDKs mostly comes down to which hardware ecosystem is being targeted, and which programming style feels most natural — the underlying quantum concepts of state vectors, gates, and measurement are identical across all of them, since every SDK is ultimately describing the same physics.
This archive's own Compare SDKs page is built specifically to make that equivalence concrete: it shows one and the same circuit expressed across several different frameworks, side by side, so the surface syntax differences stop obscuring how similar the underlying model really is.
The most direct way to close the loop between the theory in this curriculum and working code is this archive's own Quantum Sandbox: a full in-browser circuit simulator with real complex-amplitude state vectors, Bloch-sphere visualization, and entanglement analysis, which also exports any circuit built in it directly to Qiskit — build visually, then read off exactly what Python would reproduce it.
For working, runnable examples spanning much of the Algorithms track in multiple frameworks, this archive's Code Snippets page is the natural next stop, and Tools & Practice rounds out the software side with further hands-on exercises.
Try It Yourself
Using the standard SDK workflow (build → simulate/run → read statistics), sketch the steps to build and run the Bell-state circuit (H on qubit 0, then CNOT from qubit 0 to qubit 1) that first appeared in Entanglement & Bell States.
- 1Create a circuit object with 2 qubits — e.g. QuantumCircuit(2) in Qiskit-style pseudocode.
- 2Add gates to the circuit object in time order: circuit.h(0), then circuit.cx(0, 1) — exactly the same two-gate H-then-CNOT recipe from Entanglement & Bell States, just expressed as code instead of a diagram.
- 3Add measurement instructions for both qubits, e.g. circuit.measure_all().
- 4Choose where to run it: a local simulator (exact amplitudes, ideal for debugging against hand calculations) or real cloud hardware, and submit the circuit with some number of repeated 'shots' — since, as The Quantum Circuit Model covered, a single run only ever returns one measurement outcome.
- 5Read back the returned counts: across many shots, expect roughly half '00' and half '11', confirming the Bell state's perfect correlation and the complete absence of '01' or '10'.
The same build → add gates → measure → choose backend + shots → read counts pattern applies almost identically across Qiskit, Cirq, PennyLane, and Braket — only the exact method names differ.
Reference
| Qiskit | Widest ecosystem, direct access to IBM Quantum hardware | |
| Cirq | Close to Google's own superconducting hardware model | |
| PennyLane | Strong focus on differentiable circuits and quantum ML | |
| Braket | Hardware-agnostic cloud access across multiple vendors |
Quick Check
What do Qiskit, Cirq, PennyLane, and Braket all have in common?
What can the Quantum Sandbox export a built circuit to, directly?