デバッガー型マイクロワールドでインタープリターの動きを知る

Seeing a hard-to-read mechanism by making it move

A microworld is an intentionally limited environment where you can experience the system you want to learn. This chapter applies that idea to a programming-language interpreter. An interpreter is a mechanism that runs a program.

In the talk, the speaker tried to understand how his programming language worked. However, the formal explanation of a Prolog interpreter felt complicated when read on its own. So he asked Claude to build a temporary debugger that showed the interpreter's internals one step at a time.

This debugger was not a complete product with every feature needed for production. It was a learning UI made so the speaker could understand the mechanism. In other words, it was a tool for building a working model in the learner's mind, not for using a finished product.

Scrubbing the timeline to see state

In this UI, the interpreter's execution is represented as a timeline, a sequence of steps over time. The learner can scrub the timeline. Scrubbing means moving a handle or position to move backward or forward through the execution. The learner can then inspect the interpreter's state at each step.

Here, state means the information the machine holds at a given moment. As a supplement, the processing in progress and the information on the stack are examples of state. In this demo, the program clauses, stack, timeline, and notes area appear on the same screen. As the steps advance, the highlighted line, stack contents, timeline position, and step number change.

Figure 1. This interactive debugger places the program, stack, timeline, and notes side by side. In the nearby frames, the highlighted line and stack contents change with the steps. However, the code and variable names are small, so their details cannot be read accurately. Therefore, this image supports the layout for following execution one step at a time; it does not prove the contents of each code line. [Source video at 13:04]

The important point of this method is not to read the source code from beginning to end. It is to observe what happens during execution. For example, if you pause the flow of processing a query one step at a time, you can follow which clause is examined and how the stack and other state change. This is a teacher-created example that supplements the explanation. It does not infer the fine details of the actual screen.

When internal state is visible, it becomes easier to see the interpreter not as a "black box" that only returns a result, but as a machine that advances while changing state. This does not show the entire interior. Even so, seeing previously hidden intermediate changes provides a foothold for thinking about the mechanism.

Building a feel for the machine by fixing a bug

The speaker also fixed a narrow bug in this microworld. The point was not to leave the fix to Claude and receive only the result. While fixing it, he checked for himself how the surrounding machine worked.

This difference matters. If you ask an agent, "Fix this bug," the immediate problem may be solved. But you may still not know why it works after the fix or which state will change at the next step. In contrast, if you pause the process in the debugger and compare the state before and after the fix, you develop intuition for how the interpreter moves.

This does not mean that he gained a complete model of the machine. The displayed state is only a selection made for learning. Still, observing internal changes repeatedly creates "peripheral vision" around the codebase. Even without memorizing every implementation, you gain a basis for considering where something is likely happening.

Using timeline comments as a foothold for your future self

This debugger also has a feature for adding comments to points on the timeline. The speaker can leave an observation or question at the step where it occurred to him. When he reviews the same execution later, the comment helps him remember what he was thinking at that moment.

In the talk's explanation, comments are a memory aid that connects one-time understanding to future understanding. The timeline stores a record of the execution, while comments store the speaker's thoughts. Together, they mean he does not have to investigate everything again from zero each time he learns.

However, the fine details of the comment UI are difficult to see in the video. The exact interaction and display cannot be established from the screen alone. Here, the role described by the speaker—leaving a thought at a point on the timeline—is treated separately from the layout that can be confirmed on screen.

Figure 2. The same debugger displays a Prolog program, an execution stack, a step timeline, and text notes. This shows a layout where thoughts can be recorded while watching the flow of execution. Later frames have an icon overlaid to indicate pausing, but the underlying screen layout is the same. Because the image does not show the fine details of the comment feature, its exact interaction cannot be inferred. [Source video at 13:16]

Learning to "get inside" through a temporary debugger

As a supplement, this debugger has a different role from a typical production debugger. A production debugger is used to investigate various problems during development. This temporary debugger provided the views the speaker needed to understand one interpreter.

Therefore, a microworld's value is not determined by the number of features. What matters is that the learner can interact with it, see intermediate state, and compare a prediction with what actually happens. If the result differs from the prediction, the learner goes back on the timeline and examines the state changes. Through this small repetition, the learner develops a feel for the machine that is hard to gain by reading an explanation alone.

This is not a claim that people should fix every bug by hand. Agents can write code, and they can also build learning UIs. The important point is not to hand over the entire repair and place people outside the loop. It is to create an environment where people can observe the mechanism and participate in the next decision.

Just as the interactive figures in the previous chapter showed relationships that could not be seen, this debugger shows state during execution. In this way, a microworld for understanding becomes an entrance back into the code.