Course 1 built a complete, working implementation of Wisp — the same toy language this course continues — as a tree-walking interpreter: source text becomes tokens, tokens become an abstract syntax tree, and running a program means recursively calling accept()/visit_*() on that tree, over and over, every single time a piece of code executes. It works. It's also not how any serious language implementation actually runs code — Python itself, Lua, the JVM, and V8 all compile to some form of bytecode first: a flat, linear sequence of simple instructions, executed by a small virtual machine instead of a recursive tree walk. This course rebuilds Wisp's own runtime that way. This chapter asks the obvious question first, honestly, instead of assuming the answer: is bytecode actually faster, and if so, why?

What Stays, What Changes

Nothing from Course 1's own front end is being thrown away. The lexer (Chapter 1) and the recursive descent parser (Chapters 2-3) already do their job correctly — they turn Wisp source text into an AST, and that part of the pipeline doesn't care what happens to the tree afterward. What changes is everything downstream of the AST.

Measuring the Real Cost of Tree-Walking

Before assuming bytecode is faster, it's worth actually building the smallest honest version of both and timing them. Here's a tree-walking evaluator matching Course 1's own shape — dataclass nodes, double dispatch through accept()/visit_*() — next to a bytecode compiler and a minimal stack-based VM for the same arithmetic:

Both were run on the exact same expression — a 17-node tree computing ((1+2)*3-4)/5 + ((6-1)*2+3) — evaluated 300,000 times, timing the median of 9 runs to cancel out system noise.

The Same Comparison at Real Program Scale

A 17-node arithmetic expression isn't a realistic Wisp program, though — a real script has loops, function bodies, and expressions nested far deeper than one line. Repeating the exact same measurement on a much larger expression (a 201-node chain, then a 601-node one) tells a genuinely different story:

The Other Cost: Recursion Depth Itself

There's a second, sharper problem with recursive evaluation that has nothing to do with speed: it can simply fail, on a program that's done nothing wrong except be deeply nested. Python's own call stack has a limit — sys.getrecursionlimit(), 1000 by default — and every accept()/visit_*() pair the tree-walker uses to evaluate one level of nesting consumes two of those frames, not one.

A real Wisp program can absolutely produce nesting this deep — a long chain of string concatenation, a deeply recursive data structure literal, or (as Course 1's own Chapter 7 measured directly) a recursive Wisp function calling itself: exactly 163 levels at Python's default recursion limit, since each nested WispFunction call also rides Python's own call stack. That's a different code path than the expression-nesting case above, but the same underlying cause: recursive evaluation ties Wisp's own limits to the host language's stack, in a way a Wisp programmer has no way to reason about or predict.

Where This Connects

The Road Ahead

Hands-On Exercises

Chapter 1's own VM was a sketch — instructions as Python tuples like ('PUSH', 2.0), opcodes as strings, just enough to make an honest measurement. Nothing about that format is how a real bytecode VM actually represents a program. This chapter replaces it with the real thing: a chunk — a flat array of small-integer opcodes with a separate table for constant values — plus a disassembler for actually reading it, and a fetch-decode-execute loop that runs it. By the end, this VM will reproduce Chapter 1's own verified 14.0 result for the exact same expression, on the real representation the rest of this course builds on.

A Real Instruction Format: the Chunk

A Chunk holds three parallel pieces: the instruction bytes themselves, a separate list of the actual values the program uses (its constant pool), and a list recording which source line each byte came from, for error messages later.

code is a Python bytearray, not a list — every element must be a small unsigned integer, 0-255. That's a deliberate constraint, not an oversight: real bytecode is exactly this, a dense run of single bytes, which is what makes it compact and fast to scan compared to a list of arbitrary Python objects.

Opcodes as Small Integers

Chapter 1 used the string 'ADD' as an opcode. A real chunk uses the integer 1 instead — a value that fits in a single byte of code, matching how CPython's own compiled functions, the JVM, and Lua all represent an opcode: one small number, not a string comparison.

Constants Live Separately

An arithmetic literal like 2.0 doesn't fit in one byte — so instead of embedding it directly in the instruction stream (Chapter 1's own approach), OP_CONSTANT takes a one-byte index into the chunk's own constants list. The value itself lives once, in the constant pool; the instruction stream only ever holds small integers.

A Real Limitation, Found by Actually Hitting It

A single-byte operand for OP_CONSTANT means the constant-pool index has to fit in one byte too — which caps how many distinct constants a single chunk can hold.

Debugging Bytecode: a Disassembler

A bytearray of small integers is unreadable on sight. A disassembler turns it back into something a person can check by eye — essential for verifying the compiler in Chapter 3 is actually emitting what it's supposed to.

Hand-building a chunk for -((1.2 + 3.4) / 2), all on source line 3, and disassembling it:

The VM: Fetch, Decode, Execute

The VM itself is one loop: read the byte at the instruction pointer, advance the pointer, act on what was read. No recursion, no call stack growth per instruction — exactly the property Chapter 1 verified matters once expressions get deep.

What Happens When Bytecode Is Wrong

Chapter 3 will generate chunks automatically, so hand corruption should never occur in practice — but deliberately breaking a chunk on purpose is the fastest way to find out what this VM actually does with bad input, rather than assuming.

Adding one guard fixes it:

Where This Connects

Hands-On Exercises

Every chunk so far has been hand-assembled — a real, correct instruction format (Chapter 2), but built by literally writing emit_constant and chunk.write calls in the right order, by hand, every time. That doesn't scale to a real Wisp program. This chapter builds the actual bridge: a compiler that walks the exact same AST Course 1's lexer and parser already produce, and emits a chunk automatically — replacing hand-assembly for good, everywhere from here on.

Reusing Course 1's Own AST — With One Naming Correction

Chapters 1 and 2 of this course used small, standalone Literal/Binary classes for isolated experiments, with a shorthand op field. Course 1's own real AST — the one the actual lexer and parser build, and the one this compiler has to work against for real Wisp programs — uses a different field name, operator, and includes two more node types this course hasn't touched yet: Grouping (a parenthesized sub-expression) and Unary (the - prefix operator). This chapter switches to the real classes, field name and all.

The Compiler as a Visitor

The shape is deliberately familiar — the same accept()/visit_*() double dispatch Course 1's own Evaluator used. The difference is what each visit_* method does. The Evaluator computed and returned a Python value. The Compiler computes nothing — it emits instructions into a Chunk as a side effect, and returns nothing meaningful at all.

The pattern in every branch is the same: compile the children first, then emit this node's own instruction last. That's not a stylistic choice — it's what makes a stack machine work at all. By the time visit_binary emits OP_ADD, both operands are already sitting on the VM's own stack, pushed there by the two self.visit(...) calls that ran before it. The tree's own shape — which the parser already built correctly, honoring every precedence rule from Course 1, Chapter 2 — becomes the instruction order for free, just by visiting children before parents.

Verified Against Three Independently-Built Trees

Grouping Disappears at Compile Time

Grouping exists in the AST because (2 + 3) needs to be a distinct node from a bare 2 + 3 during parsing — without it, the parser has no way to represent "this sub-expression was explicitly parenthesized." But by the time the tree reaches the compiler, that information has already done its job.

The Compiler Trusts the Tree It's Given

One thing the compiler deliberately does not do: check whether the tree's own shape is correct. It has no way to know that. It just walks whatever Binary/Unary/Literal/Grouping structure it's handed and emits matching instructions.

Where This Connects

Hands-On Exercises

Every chunk so far has computed one throwaway value and returned it — nothing has been able to remember anything between instructions. Course 1's own Environment (Chapter 5) solved this with a dict per scope, chained to its parent. This chapter solves it twice, on purpose: globals, looked up by name at runtime, much like Course 1's own approach — and locals, which this chapter resolves entirely differently: not by name, not at runtime, but by position, worked out once, at compile time.

Six New Opcodes

A minimal OP_PRINT is also added here, purely so a multi-statement program can actually show something observable — Course 1's own PrintStmt node needs somewhere to compile to.

Globals: Looked Up by Name, at Runtime

A top-level var x = 10; compiles to: compile the initializer, then OP_DEFINE_GLOBAL with an operand pointing at the constant pool, where the variable's own name — the string "x" — lives as a constant, exactly like any other literal.

At runtime, the VM keeps one plain Python dict, self.globals. OP_GET_GLOBAL reads the name out of the constant pool and looks it up; OP_SET_GLOBAL overwrites an existing entry, matching Course 1's own rule that assignment never implicitly declares.

Locals: Resolved by Position, at Compile Time

A local variable gets no runtime lookup at all — not by name, not by any kind of table. The compiler works out, while compiling, exactly which stack slot a local will occupy, and bakes that slot number directly into the instruction as a plain integer operand.

The trick that makes this work at all: a local's value never moves anywhere new. Once its initializer is compiled, the result is already sitting on the VM's own operand stack — the exact same stack arithmetic uses — at exactly the slot it needs to stay at. declare_local doesn't emit a single instruction; it just remembers, at compile time, which position that value now occupies. Locals aren't stored anywhere separate from the rest of the VM's own working stack.

Leaving a Block: OP_POP, Once Per Local

When a block ends, every local declared inside it has to actually come off the stack — otherwise the stack keeps growing forever and every slot number calculated afterward would be wrong.

Two things happen for every local going out of scope, and both matter: an OP_POP is emitted so the VM's own stack actually shrinks back down at runtime, and the entry is removed from self.locals so any later resolve_local call can no longer find it — which is exactly the mechanism behind the shadowing test above.

A Real Performance Difference, Honestly Measured

A dict lookup by string name and a plain list index by integer are both, in the abstract, "fast" — but they're not the same cost, and it's worth actually measuring rather than assuming.

Same Ceiling, Different Reason

OP_GET_LOCAL/OP_SET_LOCAL encode a slot number as a single operand byte, the same way OP_CONSTANT encodes a constant-pool index — which means Chapter 2's own 256 ceiling shows up again here, for an entirely different quantity.

Where This Connects

Hands-On Exercises

Every chunk compiled so far has run start to finish, one instruction after the next, with no way to skip anything or repeat anything. Real programs branch and loop. This chapter breaks the "compile children, then emit this node's own instruction" rule Chapter 3 established — on purpose — because if and while need something no earlier chapter needed: an instruction whose own operand can't be known until code that comes after it has already been compiled.

First, Something Worth Branching On

Every value compiled through Chapter 4 has been a plain number — always truthy under Wisp's own rule (only nil and false are falsy). A condition that's always true isn't a condition. Three small comparison opcodes fix that, plus is_truthy, reused directly from Course 1, Chapter 4's own rule:

Nothing new needed for boolean or nil literals — Literal(True) and Literal(None) already flow through Chapter 3's own visit_literal for free, since it treats a constant's Python value generically. Only the comparisons that actually produce a boolean needed new opcodes.

The Problem: a Jump Target That Isn't Known Yet

Compiling if (cond) { thenBranch } means emitting something like "if cond is false, skip past thenBranch." That skip instruction has to say how far to jump — but at the point the compiler is ready to emit it, thenBranch hasn't been compiled yet. Its size in bytes literally doesn't exist until after it's compiled. There's no way to know the jump distance in advance.

Backpatching: Emit a Placeholder, Fix It Later

The fix is to emit the jump instruction with a fake, obviously-wrong operand, remember exactly where those bytes live in the chunk, compile whatever comes next, and then — now that its real size is known — go back and overwrite the placeholder with the correct value.

Compiling if/else

Disassembling the no-else case for if (1 < 2) { print 100; } shows the backpatch landed exactly where it should:

OP_JUMP_IF_FALSE was written at offset 5 with a placeholder, back when nothing after it existed yet. Only once OP_PRINT at offset 10 had actually been compiled — making the chunk exactly 11 bytes at that point — did patch_jump compute the real distance, 3, and overwrite the two placeholder bytes with it.

Compiling while: Jumping Backward

A loop needs the opposite direction too — after the body runs, control has to go back to re-check the condition. OP_LOOP handles that: same 2-byte offset, but the VM subtracts instead of adds.

loop_start needs no backpatching at all — unlike a forward jump's target, it's already known the moment the loop begins, since nothing about where the condition starts depends on anything compiled later.

Disassembling a smaller loop (var i = 0; while (i < 2) { i = i + 1; }) shows both directions in one program:

OP_JUMP_IF_FALSE at offset 9 jumps forward, past the whole loop body, to offset 23 once i < 2 goes false. OP_LOOP at offset 20 jumps backward to offset 4 — not offset 0, deliberately: offset 4 is where the condition check begins (OP_GET_GLOBAL i), skipping back over the one-time var i = 0; initialization, which only needs to run once.

Nested Control Flow: Backpatches Don't Interfere With Each Other

Proving the 2-Byte Offset Is Necessary, Not Just Cautious

For Loops Need Zero New Compiler Code

Course 1, Chapter 6 made a specific, verified choice: for is desugared at parse time into existing node types — a var declaration, a while loop, and a block — rather than getting its own ForStmt class. That decision pays off here for free.

Where This Connects

Hands-On Exercises

Chapter 1 of this course made a promise it hadn't yet delivered on: Course 1's own tree-walking interpreter measured a real, hard ceiling of 163 levels for recursive Wisp function calls, because every nested call rode Python's own recursive call stack. This chapter is where that promise gets kept — real function declarations, real calls, and an explicit call frame stack that replaces Python's own recursion entirely. By the end, a Wisp function will be able to call itself tens of thousands of levels deep without Python's interpreter ever noticing.

A Wisp Function Is a Separately-Compiled Chunk

Every chunk so far has held one flat program. A function needs its own chunk — its body is a separate unit of code that only starts running when called, possibly many times, possibly never.

Two things worth noticing. First, a WispFunction is just another value in a constant pool — the same mechanism that already stores numbers and strings now stores whole compiled programs. Second, the function's own Compiler starts at scope_depth=1, not 0 — which means Chapter 4's own if scope_depth == 0: global check is automatically false for everything declared inside a function body, parameters included. A function's own locals are locals from the very first line, with no extra scoping code needed.

The Call Convention: Function, Then Arguments, on the Stack

By the time OP_CALL runs, the stack looks like [..., function, arg0, arg1, ...] — the function value sitting just below its own arguments.

Call Frames: an Explicit List, Not Python's Own Stack

This is the actual fix. Instead of the VM calling a Python function to run a Wisp function (which is exactly what would tie Wisp's own depth to Python's own recursion limit), the VM keeps a plain Python list of frames, and its own run() method is one loop, reading whichever frame is currently on top.

OP_CALL doesn't call anything, in the Python sense. It appends one more CallFrame to a list and lets the same while loop keep running — the next iteration just happens to read frame.function.chunk from the newly-pushed frame instead of the caller's. Nothing about the Python call stack changes at all, no matter how many Wisp-level calls are active.

A Necessary Fix: Locals Are Frame-Relative Now

Chapter 4's own OP_GET_LOCAL/OP_SET_LOCAL read stack[slot] directly — correct back then, because only one frame (the top-level script) ever existed, so a local's slot number and its actual stack position were the same number. With more than one frame possibly active, that's no longer true.

The fix is one word of arithmetic in two places:

frame.base was set the moment the call happened, to len(stack) - arg_count — exactly the position of the first argument, which is exactly where slot 0 is supposed to point. Every local reference now resolves relative to whichever frame is currently active, so the identical slot number 0 correctly means something different in every simultaneously-active call.

OP_RETURN's Real Meaning

Through Chapter 5, OP_RETURN just meant "the program is done, hand back whatever's on top of the stack" — true only because there was ever exactly one chunk running. Now it has to actually tear down a frame and hand control back to whoever made the call.

finished_frame.base - 1 is deliberate — it removes the callee's own function value too, not just its arguments and locals, since that value has no further use once the call is over. What's left afterward is exactly what a normal expression evaluation expects: one value, sitting where the call itself used to be.

The Payoff: 50,000 Levels of Real Recursion

This is what all of it was for.

Multiple Functions, Not Just Recursion

Where This Connects

Hands-On Exercises

Course 1's own tree-walking interpreter got closures for free — a WispFunction just kept a reference to the Environment active when it was declared, and Python's own garbage collector kept that object alive for as long as anything still pointed at it. This course's own VM has no such luxury. Chapter 4 made locals live directly on the shared value stack, and Chapter 6's own OP_RETURN deletes a function's locals the instant it returns. If an inner function captured one of those locals, what happens to it?

The Problem, Concretely

By the time counter() is called the first time, makeCounter has already returned. Its own call frame is gone. Per Chapter 6's own OP_RETURN, count's stack slot was deleted along with everything else makeCounter ever pushed. But increment's own body still says count = count + 1 — referring to a slot that, by any of the last six chapters' own rules, no longer exists.

Upvalues: an Indirection That Can Outlive Its Own Slot

The fix is an object that starts by pointing at the live stack slot, and later — the instant that slot is actually about to be destroyed — switches to holding its own private copy instead. Every read or write goes through this same object either way; the closure using it never has to know which state it's in.

A function value now needs to carry its own captured upvalues alongside it, so WispFunction (the compiled code, shared across every call) is wrapped by a new Closure object (created fresh every time the fun statement actually runs, holding that particular call's own captured upvalues).

Compile-Time: Resolving a Name Across Function Boundaries

Chapter 6's visit_variable already checked "is this a local?" before falling back to a global. This chapter inserts a third possibility in between: "is this a local of an enclosing function?" Each Compiler now keeps a reference to the compiler for the function it's nested inside.

The is_local flag distinguishes two genuinely different situations: capturing a variable that's a plain local one level up (grab a stack slot directly), versus a variable an enclosing function itself already had to capture as an upvalue from somewhere further out (just forward that same upvalue along, unchanged). visit_variable/visit_assign now check resolve_local first, then resolve_upvalue, and only fall back to a global if neither finds anything — new opcodes OP_GET_UPVALUE/OP_SET_UPVALUE for the middle case.

OP_CLOSURE: Building the Real Runtime Object

A function statement no longer just pushes a bare WispFunction constant — it emits OP_CLOSURE, followed by one (is_local, index) pair per upvalue the function's own compiler discovered it needed.

capture_upvalue checks whether an Upvalue already exists for that exact stack slot before creating a new one — necessary so that two closures capturing the same variable in the same scope end up sharing one object, not two independent ones that would silently drift apart.

Closing Upvalues at the Right Moment

Two different events can destroy a stack slot an open upvalue is still pointing at: the block it was declared in ending (Chapter 4's own end_scope), or the whole function returning (Chapter 6's own OP_RETURN). Both now close any upvalues affected, before the slot actually disappears.

Verified: a Closure Outlives Its Own Creator

Verified: Two Closures Sharing the Same Live Variable

The Classic Bug: Closing Over a Loop's Own Counter

Course 1, Chapter 6 desugars for (var i = 0; i < 3; i = i + 1) { ... } into a var i declared once, outside a while loop — not redeclared fresh each iteration. If a closure inside the loop body captures i, every iteration's closure captures the same upvalue, because there's only ever one i.

This isn't a bug this chapter's own upvalue mechanism introduced — it's an honest, correct consequence of how for was desugared back in Course 1, faithfully reproduced. Wisp programmers hit the same trap real JavaScript programmers did before let existed.

The Fix: a Genuinely Fresh Local, Every Iteration

Verified: Capture Two Function Levels Out

Where This Connects

Hands-On Exercises

Chapter 7 gave objects a way to outlive the call that created them — a closure keeps its captured upvalues alive indefinitely, for as long as anything still needs them. Nothing so far has ever gotten rid of one. Closure and Upvalue objects have been piling up in memory since Chapter 6, with nothing ever asking whether a given one is still needed. This chapter builds a real collector to answer that question — and along the way, finds a genuinely surprising reason it's needed at all, in a VM hosted inside a language that already has its own garbage collector.

An Honest Framing, First

What's on the Heap

Only two kinds of object get created dynamically, during execution, potentially many times, with a genuine question of whether each one is still needed later: Closure and Upvalue. Both allocation points from Chapter 7 now record into an explicit self.heap list.

Roots: Where Reachability Starts

An object is garbage only if nothing reachable from the program's own currently-live state points to it, directly or indirectly. That live state — the roots — is everything currently on the value stack, every value stored in globals, the closure each active call frame is running, and any upvalue still open (backing a live stack slot right now).

Mark: Following References Transitively

A root is only the start. A closure can hold upvalues; a closed upvalue can hold a value that's itself a closure (a closure captured by another closure, stored as its own upvalue's frozen value). Marking has to follow those references outward, not just mark the roots themselves.

Sweep: Discarding What Isn't Marked

Verified: a Real Collection Cycle

The Twist: This Collector Isn't Actually Redundant

The honest framing at the top of this chapter said Python would keep this VM memory-safe with or without a collector of its own. Checking that directly turns up something worth correcting.

Where This Connects

Hands-On Exercises

Course 1, Chapter 8 built classes on top of what its own tree-walking interpreter already had — a callable value (calling a class constructs an instance, exactly like calling a function runs its body), plus this bound via a fresh Environment and a fresh WispFunction on every single property access. This chapter builds the same feature set — declaration, instantiation, fields, methods, single inheritance — on top of what this course already has: chunks, call frames, locals, and closures. The mechanism ends up genuinely lighter, and one real bug surfaced while getting there.

Three New Runtime Types

find_method is line-for-line the same recursive walk Course 1's own WispClass used — this chapter changes nothing about how inheritance is resolved, only how the resulting method gets bound to a specific instance once found.

this Is Just Slot 0 — No Special-Casing Anywhere

Course 1's own chapter made a point of it: this "isn't a keyword with special evaluation rules — it's parsed straight into Variable('this')." This chapter takes that literally. Compiling a method declares a synthetic local named "this" before its real parameters:

Every reference to this inside a method body now resolves through resolve_local — the exact same code Chapter 4 wrote for any ordinary local, and Chapter 7's resolve_upvalue for a nested function closing over this. Nothing new had to be built for name resolution at all.

A Real Bug: Methods Need a Different Frame Base Than Functions

The first attempt reused Chapter 6's own call convention unchanged: new_base = len(stack) - arg_count, with the receiver simply overwriting the callee's own stack slot the way Chapter 6 never needed to. Running this.name = name; inside init immediately raised RuntimeError: Only instances have fields.

The fix: a CallFrame tracks two positions, not one — base (where slot 0 actually lives, used by OP_GET_LOCAL/OP_SET_LOCAL) and origin (the callee's own original position, used only to know how much to discard on return). For a plain function call, base = origin + 1. For a method or constructor call, base = origin — the receiver is slot 0.

Compiling a Class Declaration

OP_CLASS pushes a new, empty class. An optional superclass expression is compiled and consumed by OP_INHERIT. Each method compiles through the same compile_function used above, wrapped in OP_CLOSURE (methods can capture upvalues too, exactly like any nested function), then attached via OP_METHOD — all while the class itself sits on the stack, untouched, underneath.

Property Access: Get and Set

That last line is the whole method-binding mechanism. No new environment, no new closure, no re-wrapping of anything — just a receiver and a method, held together. a.increment() compiles as an ordinary Get feeding an ordinary Call: nothing about method calls needed a dedicated opcode at all, since a BoundMethod flows through the exact same OP_CALL every other callable value uses.

Verified: Independent Instances, and a Bug This Design Can't Reproduce

init Always Returns this — Decided at Compile Time

Course 1 solved this at runtime: WispFunction.call() checks self.is_initializer after catching a ReturnException and substitutes this for whatever the return actually carried. This chapter's own compiler can make the identical guarantee earlier — by never compiling the return value the programmer wrote in the first place.

A Fair, Isolated Performance Comparison

Chapter 1 already established that a naive Python-hosted VM doesn't automatically outrun a tree-walking interpreter — comparing two entirely different execution models is easy to get wrong. A fairer question for this chapter specifically: within the same VM, how much does the lightweight BoundMethod pairing actually save over allocating a fresh closure the way Course 1's own bind() does — an Environment-equivalent plus a WispFunction-equivalent, every single property access?

Where This Connects

Hands-On Exercises

Course 1 finished with a working tree-walking interpreter and one deliberate, unresolved promise: "the language stays the same. How it runs changes completely." This course spent nine chapters keeping that promise — a compiler, a stack-based VM, call frames, closures, garbage collection, classes. This capstone runs Course 1's own capstone program, unchanged, through everything Course 2 built, confirms it produces identical output, and then finally does the one thing Chapter 1 could only forward-reference: a real, honest, measured answer to whether the bytecode VM this course spent nine chapters building is actually faster.

Two Small, Honest Gaps — Closed Right Where They're Needed

Course 1's own capstone program uses >= (checking a task's priority against a threshold) and != (checking a linked-list node against nil). Neither exists in this course's own VM — Chapter 5 only ever built <, >, and ==, because nothing before now needed the other two. Two more comparison opcodes, OP_GREATER_EQUAL and OP_NOT_EQUAL, close both gaps — the same pattern this course has followed throughout: build what's needed when something concrete needs it, not before.

The Same Program, Verified Byte-for-Byte Identical

Course 1's own Task/UrgentTask/TaskNode/TaskQueue program — a linked-list task queue built entirely from classes, single inheritance overriding describe(), a closure factory (makeUrgencyChecker) capturing a threshold, and a higher-order function (countMatching) taking a callback — compiled here exactly as written, no changes, through this course's own Chapters 2-9 pipeline.

The Real Comparison: Scaling Up

Course 1's own capstone program runs once, on four tasks — too small to measure anything meaningful. A scaled version — 2,000 tasks, alternating Task and UrgentTask instances, then one countMatching pass using a real closure — exercises class instantiation, inheritance, property access, and closures at a scale actually worth timing.

Not Every Workload Behaves the Same Way

Chapter 1 of this course measured the opposite result — a single, deeply-nested arithmetic expression (201+ nodes), evaluated repeatedly, ran roughly 1.7× faster under the bytecode VM than under tree-walking. That finding and this chapter's own 0.49× result aren't in conflict — they're measuring genuinely different things.

The honest conclusion isn't "bytecode is faster" or "bytecode is slower" — it's that performance in a Python-hosted VM depends on the specific shape of the work, and only one of the three shapes this course actually measured favors the design it spent nine chapters building. That's not a disappointing result to report; it's the same rigor this course applied to every other performance claim, from Chapter 1's own first honest finding onward, held to at the very end instead of quietly abandoned for a triumphant close.

Where Every Piece Came From

What This Course Doesn't Cover

Course 2's own VM inherits every scope boundary Course 1 already documented (no arrays, no string formatting, no super.method(), no break/continue, no static members, no standard library beyond print) and adds a few of its own: no line-numbered error reporting or multi-frame stack traces (Course 1's own Chapter 9 was never rebuilt at the bytecode level — a runtime error here is a plain Python exception, with none of Course 1's own [line N] attribution or call-stack trace), no automatic GC triggering (Chapter 8's own collector runs only when explicitly called, never on an allocation threshold the way a real VM would), and no bytecode-level optimizations a production VM would add (constant folding, inline caching, or clox's own OP_INVOKE fast path for method calls, which Chapter 9 named directly and chose not to implement). None of these are oversights — each is a deliberate line drawn so the course stayed teachable rather than becoming a production language runtime.

Closing Both Courses Together

Twenty chapters, two courses, one language. Course 1 built a real interpreter and measured its real limits — 163 levels of recursion, a visitor pattern that beat isinstance chains, a division-by-zero bug caught by actually testing it. Course 2 rebuilt the same language's runtime from the ground up and measured its own real limits in turn — 50,000 levels of recursion where Course 1 found 163, a genuine memory leak in the collector's own bookkeeping, a lightweight method-binding design 2.27× cheaper than the alternative, and, at the very end, an honest admission that the faster design isn't uniformly faster. Nothing in either course was asserted without being run first.