Turning text into machine work: compilers and interpreters

Human words and machine words differ

The 'add', 'if' we write are words easy for humans to read.
But what a machine truly knows
is only tiny instructions made of on and off.
Between our text and what the machine does is a big gap.
So our text can't run as it is.

Top is our line, bottom is the machine's tiny instructions. Tap the gap between.

The top and bottom are so different.
Human words read at a glance; machine words are unreadable.
Someone has to cross this gap for us.
There are two ways to do that job.

Two ways to build the bridge

To cross the gap you need someone to translate.
There are two ways.
One: translate the whole text all in advance.
The other: read and run it line by line on the spot.
The former is a compiler, the latter an interpreter.

Tap the two paths. 'Translate all first' and 'line by line on the spot' look different.

They cross the same gap, yet quite differently.
One ahead of time, one on the spot.
Shall we look closely at the 'translate it all in advance' side first?
This is how a compiler works.

Compile: translate it all in advance

A compiler reads our text from start to end
and turns it all at once into a finished product the machine can use directly.
The translation happens once, up front; then you run that result fast, many times.
If something's wrong, it often tells you before you run.
It's like translating a whole book in advance and handing readers the finished version.

Press 'compile' to turn the whole text into a finished product; 'run' executes it fast all at once.

Translating everything in advance makes the run lean and fast.
In exchange, you wait until the upfront translation finishes.
So, conversely, is there a way to start right away without waiting?
That's the interpreter.

Interpret: line by line, on the spot

An interpreter doesn't make a separate finished product.
It reads our text from the top, one line, and does that thing right away,
then reads the next line and does it too, going on the spot like this.
So you start immediately with no wait and can try things lightly.
It's like a live interpreter translating one sentence at a time as you speak.

Press 'run': read a line, do it, then the next. It proceeds in turn, on the spot.

Starting right away and going line by line feels handy.
In exchange, each run reads through line by line from the start again.
Compile is ahead-and-fast; interpret is on-the-spot-and-easy.
So which one is better?

Not one being better, but a give-and-take

Neither is flatly better; they give and take.
Compile is slow to start but fast to run, and warns of errors up front.
Interpret starts right away and is easy to try, but rereads line by line each time.
So in practice the two are often mixed as suits the case.
You choose by what you value more.

Tap an axis. See how start, run speed, error timing, and output split between the two.

Now we've seen how our text becomes machine work.
But while it's running like that,
where do the values and objects we made actually live?
And what does 'this points to that' even mean?
In the next and final lesson, we'll look into that place.