Part III: Other Frameworks
"There is no single best programming language, only languages that made different trades. The professional skill is not loyalty. It is fluency, and the judgment to know which trade you need."
Every framework in this part is a bet about what quantum programming fundamentally is.
Qiskit bets it is circuit construction plus compilation for a specific hardware family. Cirq bets it is scheduling — that the moment-by-moment timing and the physical placement of qubits are part of the program, not an afterthought for a compiler. Q# bets it is a language problem, that quantum data deserves a real type system and quantum control flow deserves real syntax. PennyLane bets it is differentiation, that a quantum circuit is a function you take gradients of. Amazon Braket bets it is a portability problem, that the interesting question is running the same program on a trapped-ion machine and a superconducting machine and comparing.
Those bets produce tools that feel genuinely different, and reading all five will change how you think about the one you use daily. That is the real argument for this part. The stated argument — that a professional should be able to work in more than one framework — is also true, and Chapter 40 will show you that job listings ask for exactly this. But the deeper value is that you cannot see Qiskit's design decisions as decisions until you have seen someone decide otherwise.
The device: one algorithm, five times
Part III is organized around a single running comparison. A three-qubit Grover search for the marked state |101⟩ appears in every chapter of this part: in Cirq, in Q#, in PennyLane, in Braket, and — from Chapter 21 — in Qiskit. Chapter 18 puts all five side by side on the same page.
The comparison is instructive in a way that a "hello world" comparison never is. Grover needs an oracle, a diffusion operator, multi-controlled gates, and a specific number of iterations. Every framework handles those four things differently, and the differences are exactly where each framework's philosophy shows.
It also exposes something the frameworks do not agree on and rarely document loudly: bit ordering. "The marked state is |101⟩" means different source code in different frameworks. Chapter 18 makes that explicit, and it is the most practically useful page in the part.
What You Will Learn
Chapter 14 — Google Cirq. Qubits as objects with positions, circuits as sequences of moments, and what it means for a framework to refuse to hide the hardware. Noise channels, parameter sweeps, and when Cirq is the right answer.
Chapter 15 — Microsoft Q#. The only purpose-built quantum programming language: a real type
system for quantum data, automatically generated adjoint and controlled variants, within/apply
for uncomputation, and the resource estimator that will tell you — soberingly — what your algorithm
would actually cost on a fault-tolerant machine.
Chapter 16 — PennyLane. Quantum circuits as differentiable functions. QNodes, devices, the parameter-shift rule, and integration with PyTorch and JAX. This chapter is the gateway to Part VI.
Chapter 17 — Amazon Braket. One SDK, three qubit technologies. The same circuit on a trapped-ion device and a superconducting device, and what the difference in results tells you about the hardware. Hybrid jobs, analog Hamiltonian simulation, and a frank treatment of what it costs per shot.
Chapter 18 — Framework Comparison and Interoperability. The five-way comparison, the conversion paths between frameworks, what OpenQASM preserves and what it silently drops, and a decision table you can actually use.
How This Part Fits
Part III depends on Parts I and II and is depended on by Part VI (which is PennyLane throughout) and Chapters 37 and 39. Chapters 14, 15, and 17 are otherwise fairly self-contained — you can read any one of them alone if you have a specific need.
If you are on the 🤖 Quantum ML path, Chapter 16 is required and the rest is optional. If you are on the 🔐 Security path, skim Chapter 15 for the resource estimator; it is the tool that produces the numbers you will need to quote about RSA.
Time Investment
| Chapter | Title | Difficulty | Est. hours |
|---|---|---|---|
| 14 | Google Cirq | Intermediate | 6 |
| 15 | Microsoft Q# | Intermediate | 7 |
| 16 | PennyLane | Intermediate | 7 |
| 17 | Amazon Braket | Intermediate | 6 |
| 18 | Framework Comparison and Interoperability | Intermediate | 5 |
| Part III total | ~31 hours |
The Project in This Part
vqelab gets a plugin architecture. Chapters 14, 16, and 17 each add a backend — Cirq, PennyLane,
Braket — behind the same interface Chapter 7 established, so that the identical ansatz can be
evaluated on any of them. Chapter 15 adds a Q# implementation and, more usefully, a resource
estimate of the H₂ circuit: what would it cost to run this on a fault-tolerant machine? Chapter 18
adds a round-trip conversion test that catches the class of bug where a circuit survives export and
import but no longer means the same thing.
That plugin layer is not busywork. It is the reason the project can be benchmarked across hardware technologies in Chapter 30 and priced across platforms in Chapter 39.
Turn to Chapter 14.