How code actually runs

A computer does not read your text; so what does it run?

The file you save is plain text; as far as the disk is concerned it is no different from a note. The processor does not read that text. What a processor executes is a set of very simple numeric instructions: take this number from memory, add that one to it, put the result over there, and if it came out zero jump to that point. This is called machine language and nobody works directly in it today.

So between your text and the processor there is always a translation stage. It has three links and the order never changes: the text you wrote, the program that reads and checks and translates it, and the translated form that finally runs. No language escapes this chain. Languages differ on only two things: when the translation happens, and whether its result is kept.

One point that becomes useful very quickly: the translation stage checks syntax before anything else, meaning whether your text obeys the rules of that language at all. If it does not, work stops right there and not one line of your program runs, not even a line that was fine and came before the mistake. The fourth section of this page shows that with two real files.

What is the difference between compiled and interpreted?

The simplest version: in an interpreted language the text is handed to the language engine as it is and runs from top to bottom; in a compiled language the text is first transformed into another form and that form is what runs. Mozilla puts it in exactly those terms, that in interpreted languages the code is received in its text form and processed directly from it, while compiled languages are transformed into another form before they are run.

Now the awkward part. That split is not a clean line any more. On the same page Mozilla adds that most modern JavaScript interpreters use a technique called just-in-time compiling, turning the source into a faster binary form while the script is being used; and it still counts JavaScript as interpreted, because that compilation happens at run time rather than ahead of time.

So the question is it compiled or interpreted is slowly losing its usefulness. Two better questions: when does the translation happen, and is its result kept or rebuilt from scratch every time? Those two answers explain why a C program has a separate build step before it can run, and why a Python script that imports a module starts a little faster the second time.

Where do Python, JavaScript and PHP sit in this chain?

The table below puts the two questions from the previous section against four languages. The third column is the important one, because that is where languages actually differ, not in their label.

Put the first three rows side by side and a pattern appears: all three translate at run time, and they differ only in where they put the result. Python on disk, PHP in memory, JavaScript nowhere. The fourth row is here on purpose so you can see the genuinely different case: in C, if you do not compile the program, there is nothing to run at all.

One practical consequence you can use straight away: in JavaScript, PHP and Python you change the file and see the effect next time. In C you have to build again. If someone tells you they changed the file and nothing changed, the first question is which row of this table their language is in, and the second question is the subject of section five.

Why does nothing run sometimes, and half the program other times?

Make two small files and run each on its own. The first is bad.py, with an unclosed bracket on line two:

print("first line")
print("second line"

The real output is this:

  File "bad.py", line 2
    print("second line"
         ^
SyntaxError: '(' was never closed

The second is boom.py, whose syntax is fine but which asks for something impossible:

print("first line")
print(1/0)

And its output:

first line
Traceback (most recent call last):
  File "boom.py", line 2, in <module>
    print(1/0)
          ~^~
ZeroDivisionError: division by zero

Look at the difference, because this one thing is half of your debugging. In the first file the words first line were never printed, even though line one was perfectly correct and came before the mistake. In the second they were printed and then the program fell over halfway. The reason is the chain from the first section: the syntax check runs over the whole file before any execution, so an unclosed bracket on line two takes line one down with it. But a division by zero is not discovered until the moment we actually reach it, because until then nobody knows the divisor is zero.

These two cases have names: a syntax error and a runtime error. Their practical value is that you can tell them apart from the output alone, even without knowing the language. If something was printed before the error message, the program had started running and you are dealing with a runtime error; if nothing was printed, it very likely never ran at all.

The file you saved is not the thing that runs

Now the interesting part of the chain. The result of translation does not only live in memory; very often it is kept so it does not have to be built again next time. Python does this right in front of you. Make two files, tools.py and a main.py that imports it, then:

python3 main.py
ls __pycache__/

A folder called __pycache__ appears with exactly one file inside it: tools.cpython-312.pyc. Nothing was written for main.py. Python's own documentation explains both halves: Python caches the compiled version of each module in the __pycache__ directory, and for the module loaded directly from the command line it always recompiles and does not store the result.

PHP does the same job with one difference: it does not put the result on disk, it keeps it in server memory. That layer is called opcache, and its behaviour has one setting that drives beginners mad: how often to check whether the file on disk has changed. PHP's own manual describes the setting in exactly those words, how often to check script timestamps for updates, in seconds. Which means there is a gap between saving a file and the save taking effect, and the gap is deliberate.

So that familiar sentence, I changed the file and nothing happened, has three common answers and all three live in this chain: either the file you changed is not the file that runs, or an old translated copy is still in memory, or the output is coming from a cache layer further forward and never reached your program at all. The section from our own work at the bottom of this page gives the number for that setting on our own server.

When the program does not work, where do you look first?

Read the error message from the bottom, not the top. The last line names the type of error and it is the most important word on the screen; the line above it usually says where. In the example in section four the last line was ZeroDivisionError: division by zero and the line above pointed at the exact expression that blew up. Beginners usually start at the top, where only file paths are written, and then say the error is incomprehensible.

Once you have read it, name the layer. There are only four. Syntax: nothing ran, the message came before any output. Runtime: something was printed and then it fell over. Environment: the program is fine but something it needs is not installed, is a different version, or cannot be found. Logic: there is no error at all, the program runs to the end and gives the wrong answer.

Here is our position and it is a simple one: before you change a single character, say the name of the layer out loud. Most of the hours beginners lose go into changing code in a layer where the problem is not, such as rewriting a perfectly good function when the library was never installed. The fourth layer is the worst of them, because it raises no error at all; the only way to catch it is to guess what the output should be before you run, then compare that against what came out.