What is a compiler vs an interpreter
We write code in human words like "add," "if," and "name." But what a machine understands deep down is only tiny instructions at the level of on and off. There's a big gap between human language and machine language, and compilers and interpreters are what bridge it.
Human words and machine words are different
The "add" and "if" we write are words that are easy for people to read.
But what a machine really knows is only tiny instructions made of strings of on and off.
There's a big gap between the text we write and the work the machine does, so our text can't run as it is.
On top is one line we wrote; below are the tiny instructions the machine knows. Press "see the gap" to show the distance between them.
The top and the bottom are very different.
Human words read at a glance, while machine words are hard to make out.
Someone has to cross this gap on our behalf, and there are two ways to do it.
Two ways to build the bridge
Crossing the gap takes someone to translate.
One way is to translate the whole text ahead of time; the other is to read one line at a time on the spot and run it right away.
The first is a compiler, and the second is an interpreter.
Press compiler and then interpreter, and you'll see "translate everything first" and "one line at a time, on the spot" drawn differently.
They cross the same gap in quite different ways.
One works ahead of time; the other works on the spot.
Let's start with a closer look at translating everything in advance, which is how a compiler works.
Compiling: translating it all in advance
A compiler reads our text from beginning to end and turns it, all at once, into a finished product the machine can use directly.
The translation happens just once, in advance, and the result can then be run quickly many times.
If something's wrong, it can even warn you before you run it.
It's like translating an entire book ahead of time and then handing it to readers.
Press compile and the whole text turns into a finished product; press run and that product runs quickly in one go.
Because everything was translated in advance, running it is lean and fast.
The trade-off is that you have to wait until the translation is done at the start.
So is there a way to start right away without waiting? That's the interpreter.
Interpreting: one line at a time, on the spot
An interpreter doesn't make a separate finished product.
It reads one line of our text from the top, does that job right away, then reads the next line and does that, working on the spot.
So you can start immediately without waiting, and trying things out is easy.
It's like an interpreter standing beside a speaker, translating one sentence at a time.
Press run and it reads one line, does it right away, and moves on to the next. It proceeds step by step, on the spot.
Starting right away and going one line at a time feels natural to work with.
The trade-off is that every run reads the lines again from the start.
Compiling is ahead of time and fast; interpreting is on the spot and easy.
So which one is better?
Not better or worse, but a trade-off
Neither one is always better; it's a trade-off.
Compiling starts slowly but runs fast and catches errors ahead of time.
Interpreting starts right away and makes testing easy, but it reads the lines again every time.
In practice, the two are often mixed, and you choose based on what matters most.
Tap an item to see how start, run speed, error timing, and output differ between the two.
Now we've seen how our text becomes a machine's work.
But while it runs, where exactly do the values and objects we made live?
And what does it mean for "this to point to that"?
In the last lesson of this section, we'll look inside that place.