How a Program Runs: The Interpreter

What is it?

A script is just text until something runs it. For languages like Python and PowerShell, that something is an interpreter: a program that reads your script and carries out each instruction, one at a time, in order — normally top to bottom. Each line (a statement) is executed, then the next, and so on. The interpreter keeps track of the current state (the values of variables) as it goes. So a program's behaviour is the cumulative result of its statements running in sequence.

Why it matters

You cannot predict or debug a script without knowing the order its lines run in. 'Why is this variable empty here?' or 'why did this run before that?' are answered by tracing execution top to bottom. Understanding sequential execution is the foundation for reading any code and for every later concept (control flow only makes sense once you know the default is line-by-line).

Where you see it

In running any script (python script.py, a PowerShell .ps1), in reading code top to bottom, and in a REPL / interactive shell where you see each line execute and its effect immediately.

What normal looks like

Statements executing in written order, each building on the state left by the previous one; a value is available only after the line that created it has run. The output matches a top-to-bottom trace of the code.

What suspicious looks like

For debugging: behaviour that seems to violate order usually means you mis-read the sequence — using a variable before the line that sets it, or expecting a later line's effect earlier. An error like 'name is not defined' is often 'you used it before it was created'.

How analysts investigate

By tracing a script the way the interpreter does: start at the top, execute each line, and track how the state (variable values) changes after each one. Reading code is simulating the interpreter in your head — and the first question for any bug is 'in what order do these lines actually run?'

Common beginner mistakes

Reading code as a whole 'description' rather than an ordered sequence. The order is everything: a line only sees the state produced by the lines above it, not below.
Assuming a later line's change applies retroactively. If line 5 changes a value, lines 1–4 already ran with the old value — changing it later doesn't reach back in time.

You write a script as text and save it in a file. On its own, that file does nothing — it's just characters. To make it run, an interpreter (the Python interpreter, or PowerShell) reads the file and carries out its instructions one line at a time, from the top down. This is the single most important idea for reading code: a program is a sequence, and the interpreter walks it in order, remembering the state as it goes. Once you can trace that walk, you can predict what any straight-line script does.

   THE INTERPRETER RUNS A SCRIPT TOP -> BOTTOM, tracking state

   line                          after the line runs, state is:
   1  price = 100                price=100
   2  tax = 15                   price=100, tax=15
   3  total = price + tax        price=100, tax=15, total=115
   4  print(total)               (outputs: 115)

   Each line sees ONLY the state produced by the lines ABOVE it.
   Line 3 works because price and tax already exist (lines 1-2).

The interpreter executes statements in order, updating the state (variable values) after each. A line can use only what the lines above it have already created.

# The interpreter runs these lines in order, top to bottom.
price = 100          # 1: create price
tax = 15             # 2: create tax
total = price + tax  # 3: uses price & tax (already exist) -> total = 115
print(total)         # 4: outputs 115

A straight-line Python script. Line 3 can add price and tax only because lines 1–2 created them first — order is everything.

Two rules follow from top-to-bottom execution, and they explain most beginner confusion. First, a line can only use what already exists. Line 3 (total = price + tax) works because price and tax were created on lines 1 and 2. If you tried to use total on line 2 — before line 3 created it — the interpreter would stop with an error, because at that moment total simply doesn't exist yet. Second, changes don't reach backwards. If a later line changes price to 200, the lines that already ran used the old value of 100 — running order is also time order, and you can't retroactively change what already happened. Reading code, then, is simulating the interpreter: start at the top, execute each line in your head, and update your mental picture of the state after each one. That single habit — trace top to bottom, tracking state — lets you predict what a script prints and is the first move in debugging any 'why did it do that?'.

Tracing a script that surprises a beginner

A colleague expects this script to print 200, but it prints 100. Trace it as the interpreter to explain why. price = 100 print(price) price = 200

Execute line 1.
Line 1, price = 100, creates the variable price holding 100. State after line 1: price = 100. Nothing is printed yet. So far, straightforward.
Execute line 2 with the CURRENT state.
Line 2, print(price), outputs the value price has RIGHT NOW. Right now — after line 1, before line 3 — price is 100. So it prints 100. This is the crux: print uses the state as it exists at the moment line 2 runs, and line 3 hasn't executed yet, so its change hasn't happened. The interpreter can't look ahead.
Execute line 3 and explain the surprise.
Line 3, price = 200, now changes price to 200 — but this happens AFTER the print already ran. The output was decided at line 2, using the value at that moment (100); line 3's change is too late to affect it. The colleague's mistake was reading the code as a whole and seeing '200 is assigned' without tracking WHEN. Decision/lesson: trace top to bottom and track state at each step — the print on line 2 sees 100 because that's the value when it runs, and a later assignment can't reach back to change what was already printed.

Quick check

How does an interpreter run a straight-line script?

A quick self-check — it doesn't affect your XP or progress.

Quick check

A script does `print(x)` on line 2, and `x = 5` on line 3. What happens?

A quick self-check — it doesn't affect your XP or progress.

Trace this script as the interpreter and say exactly what it prints, tracking the value of count after each line: count = 1 count = count + 1 count = count + 1 print(count)~4m

Each `count = count + 1` uses the current value of count (from the line above) and stores the result back. Walk it: what is count after each line?
It prints 3. Trace: line 1 sets count = 1 (state: 1). Line 2, count = count + 1, takes the current count (1), adds 1, stores 2 back (state: 2). Line 3 does the same with the new current value: 2 + 1 = 3 (state: 3). Line 4 prints count, which is now 3. The key is that each line uses the value produced by the line above it — count = count + 1 reads the current value, computes, and updates the state, and the interpreter carries that state forward line by line. That's sequential execution with state, exactly as the interpreter runs it.