From text to execution: compilers and interpreters
On This Lesson 11 topics
Lesson Overview
In Module BEG-002 you learned that software is a set of instructions. In BEG-001 you met the CPU, the part that follows instructions. This lesson connects the two with a question that sounds simple: people write code as text, but the CPU cannot read text. How does the text become something the CPU can run?
The answer is translation. There are two main ways to translate: a compiler translates the whole program before it runs, and an interpreter translates and runs it as it goes. We will use one analogy for this whole module: translating a book. A translator can translate the entire book once, up front, and then anyone can read the translated copy. Or an interpreter can sit beside a reader and translate each sentence out loud, every time.
Why this matters: the next lessons explain how Java translates code, how you build and run it from the terminal, and how to tell apart mistakes found early from mistakes found late. All of that rests on the two ideas here.
This lesson builds on BEG-001 (CPU and instructions) and BEG-002 (what software is). It needs no Java knowledge.
Learning Objectives
By the end of this lesson you will be able to:
- Define source code and machine code, and explain why the CPU needs the second one.
- Explain what a compiler does and what an interpreter does.
- Compare the two approaches using the translated-book analogy.
- State when a mistake is found with a compiler and when with an interpreter.
- Distinguish a compile-time error from a runtime error, using one example of each.
- Explain why "it compiled" does not mean "it works".
Written Explanation
Source code is text for people
Source code is the text a programmer writes. It uses words, numbers, and symbols chosen to be readable to humans. Here is a tiny piece of Java source code:
int total = 2 + 3;You can open it in any text editor, because it is just text. A person can read it and guess that it adds two numbers and keeps the result under the name total.
Machine code is what the CPU runs
In BEG-001 you learned that a CPU follows very small instructions and that everything inside a computer is stored as bits. The instructions a CPU can follow directly are called machine code: sequences of binary numbers, each of which tells the CPU to do one small step such as adding two values or moving data. Machine code is specific to a kind of CPU. Instructions for one CPU family are not valid for another, and the operating system format around them also differs.
So there is a gap:
| Source code | Machine code | |
|---|---|---|
| Who it is for | People | The CPU |
| Form | Text | Binary instructions |
| Can you read it easily? | Yes | No |
| Can the CPU run it directly? | No | Yes |
Something has to translate from the left column to the right column. That something is a translator program: a compiler or an interpreter.
The translated-book analogy
Imagine you wrote a book in English, and your reader only reads Spanish. You have two options.
- Translate the whole book first. A translator works through the full manuscript once and produces a finished Spanish book. After that, anyone can read the Spanish copy as often as they like, without the translator. If the translator finds a sentence that makes no sense, they report it before any reader gets the book.
- Interpret as you read. A translator sits next to the reader and translates one sentence at a time, out loud, every time the reader reads. Nothing is prepared in advance. If sentence 40 is nonsense, the reader only finds out when they reach sentence 40.
Option 1 is a compiler. Option 2 is an interpreter.
What a compiler does
A compiler reads the whole program and translates it into another form before the program runs. The result is a separate file that you run later.
The compiler works in a separate step, called compile time. Because it reads everything first, it can reject programs that break the language's rules. In the book analogy: the translator refuses to publish a manuscript with a broken sentence.
Typical shape:
source code --> [ compiler ] --> output file --> run it
(text) once, ahead of timeRunning the output file afterwards does not need the compiler any more.
What an interpreter does
An interpreter reads the program and carries out its instructions while it reads, translating as it goes. There is no separate output file to run: the interpreter itself is the thing you run, and you give it your source.
source code --> [ interpreter ] --> runs now, translating as it goesThe interpreter has to be present every time the program runs. A mistake can stay hidden until the interpreter reaches the line that contains it.
Comparing the two
| Question | Compiler | Interpreter |
|---|---|---|
| When is the program translated? | Before it runs, as a separate step | While it runs |
| Is there a separate output file? | Yes | Usually not |
| When are rule-breaking mistakes found? | Early, at compile time | When that line is reached |
| Is the translator needed to run the result? | No | Yes, every time |
These are the textbook definitions, and real tools often blend them. Some systems compile to an in-between form and then interpret or further compile that form. Java works this way, and the next lesson shows how. For now, keep the two pure ideas clear, because the vocabulary of the whole module rests on them.
Two moments for two kinds of errors
Because translation and running are separate moments in the compiled approach, mistakes fall into two groups.
- A compile-time error is found while the program is being translated, before it runs. It breaks the rules of the language, for example a missing semicolon in Java. The program cannot be built until you fix it.
- A runtime error happens while the program is running. The program was valid enough to be built, but something goes wrong when a certain line is executed, for example dividing a number by zero.
A third kind exists, a logic error: the program builds and runs without any error, but gives the wrong answer, such as adding when you meant to subtract. The translator cannot catch it, because the instructions are valid. They just do not do what you intended.
The key lesson: a program that compiles is not necessarily correct. The compiler checks that the text follows the language's rules. It does not check that the program does what you wanted, or that the data it meets later will behave.
Examples
Example 1: the translated book (simple)
You write a 300-page manuscript with a broken sentence on page 212.
- With a translator who works first, the broken sentence is reported before the book is released. No reader ever sees a half-translated book.
- With an interpreter at the reader's side, readers get through pages 1 to 211 happily, then the interpreter stumbles at page 212.
This is the central difference: a compiler gives you early feedback on rule-breaking mistakes, and an interpreter tells you as it reaches them.
Example 2: two small mistakes (practical)
Both lines below are about the same idea, "split a bill between friends", written in a Java-like style. Study when each would be noticed.
int share = 90 / people // line A: no semicolon at the endint people = 0;
int share = 90 / people; // line B: valid text, but people is 0- Line A breaks a rule of the language (a statement must end with
;). A compiler finds it before anything runs: compile-time error. - Line B follows every rule, so it translates fine. The trouble only appears when the program runs and the value of
peopleis actually 0: runtime error.
Notice that fixing A did not need to run anything, while discovering B required running the program with that data.
Example 3: a web service in two situations (realistic)
A team builds a backend service that calculates order totals. They send it to a build step that translates it.
- A developer mistypes a word in the code. The build step fails and reports the file and line. Nothing is deployed. This is a compile-time error, caught cheaply and early.
- A different developer makes no typing mistakes, the build passes, and the service goes live. A week later a customer submits an order with zero items and the program divides by that count. The service reports an error for that request. This is a runtime error, which appeared only because of real data.
- A third change passes the build and never crashes, but a discount is applied twice, so customers are undercharged. This is a logic error. Neither the compiler nor the running service complains.
Each is found at a different moment, which is why teams add tests as well as compilers.
Backend Insight
Backend work leans heavily on the idea of a build step. Backend code is usually compiled or packaged by an automated process before it is deployed to a server. Catching a mistake at build time is far cheaper than catching it in production, where real users are affected and the service may be restarted at 3 a.m.
Two practical consequences: do not trust "it compiled" as proof of quality, because runtime and logic errors only appear with real input (so teams test zero, empty, and very large values); and know which stage failed, because a build log points at your code's text while a runtime report points at the data and situation.
Later modules (build tools, and how the JVM executes code) build directly on this vocabulary.
Common Mistakes
Mistake 1: Thinking the CPU can run source code
- Incorrect: "The computer reads my Java file and runs it."
- Correct: "Some translator turns my source into instructions the CPU can follow. The CPU never reads your text directly."
Mistake 2: Thinking "compiled" means "correct"
A compiler only checks that your code follows the language rules. A program can compile and still crash on certain data, or quietly do the wrong thing. Treat "it compiled" as the first checkpoint, not the finish line.
Mistake 3: Treating compilers and interpreters as strictly opposite
The two ideas are clear in theory, but real language tools often mix them. Java is an example: you will see in the next lesson that it uses both a compile step and a running program that executes the result. Do not memorise "Java is compiled, therefore never interpreted"; learn the pipeline instead.
Exercises
Try each exercise yourself before opening the solutions.
Level A: Foundation
A1. In one sentence each, define source code and machine code.
Show solution A1
A1. Source code is the human-readable text a programmer writes. Machine code is the binary instructions a particular CPU can follow directly.
A2. In the translated-book analogy, who is the compiler and who is the interpreter?
Show solution A2
A2. The compiler is the translator who translates the whole book first and hands over a finished copy. The interpreter is the translator who sits beside the reader and translates sentence by sentence while they read.
A3. Which is found first: a compile-time error or a runtime error? Explain in one sentence.
Show solution A3
A3. The compile-time error, because it is found while the program is being translated, before it can run at all. A runtime error can only appear once the program is running.
Level B: Application
B1. A tool translates your entire program into a separate output file before you run anything, and you can run that file on another computer without the tool. Is the tool a compiler or an interpreter? Why?
Show solution B1
B1. A compiler. It translates the whole program ahead of time into an output file, and that file does not need the translator afterwards. An interpreter would have to be present each time you run the program.
B2. Classify each as compile-time error, runtime error, or logic error: (a) a statement missing its closing semicolon; (b) a program that asks for the average of zero scores and divides by the count; (c) a program that prints the total price but adds the tax twice.
Show solution B2
B2. (a) Compile-time error: it breaks a language rule and is found when translating. (b) Runtime error: the text is valid, the problem happens when the program divides by zero. (c) Logic error: the program runs without an error, but the result is wrong.
B3. A teammate says: "The build passed, so my feature works." Write two sentences that explain, politely, why this is not guaranteed.
Show solution B3
B3. A passing build only means the code follows the language rules. It says nothing about whether the program handles all data correctly or whether it does what the feature is meant to do, so the feature still needs to be run and tested.
Level C: Challenge
C1. A language tool runs your source directly, line by line, with no build step. A script has 200 lines, and line 150 contains a rule-breaking typo. Lines 1 to 149 each print something. What does the user see, and how does that differ from the compiled case?
Show solution C1
C1. The user sees the output of lines 1 to 149, and the problem appears only when line 150 is reached. In the compiled case, the whole program is checked first, so the typo is reported before any line runs and nothing is printed.
C2. Design a short test plan (three inputs) for a program that computes "price per person" from a total and a number of people. Say what each input is meant to reveal and which kind of error it targets.
Show solution C2
C2. Example plan: (1) total 90, people 3: confirms the normal case gives 30 and targets logic errors. (2) total 0, people 3: checks a boundary value, again a logic check. (3) total 90, people 0: reveals what happens on division by zero, a runtime error. Any similar plan with a normal, a boundary, and an unusual input is acceptable.
Mini Challenge
Choose a task from daily life, such as following a recipe or giving directions to a taxi driver, and describe it in two ways:
- Compiled style: write all the steps in a final form, check them once for mistakes, and then hand them over to be followed without further changes.
- Interpreted style: describe giving the steps one at a time while the other person acts on each.
Then write three short sentences: one compile-time-style mistake (a step that makes no sense and could be spotted by reading the whole list), one runtime-style mistake (a valid step that fails in a certain situation, such as "turn left" on a road that is closed), and one logic-style mistake (all steps work but lead to the wrong place).
Check your work: each mistake belongs to the right category, and the first one could be found without leaving your chair.
Summary & Next Lesson
Key takeaways
- Source code is text for people. Machine code is binary instructions for a particular CPU. A translator bridges the gap.
- A compiler translates the whole program before it runs. An interpreter translates and runs as it goes.
- Compile-time errors are found before running. Runtime errors happen while running. Logic errors produce no error message but give a wrong result.
- "It compiled" means only that the language rules were followed.
- Real tools sometimes combine both approaches, which is exactly what Java does.
Next lesson
You now know the two classic translators. The next lesson, "Java's approach: bytecode and the JVM", shows how Java uses a compile step and a running program together, and why one compiled file can run on different operating systems.
Self-check
- Why can the CPU not run source code directly?
- Which translator finds rule-breaking mistakes before the program runs?
- Is dividing by zero found at compile time or at runtime?
- Name the third kind of error, the one with no error message.
- Why is "it compiled" not enough to say a program works?
Show answers
- The CPU only follows machine code, which is binary instructions. Source code is text meant for people.
- The compiler, because it reads the whole program before it runs.
- At runtime, when the program actually executes the division with a zero divisor.
- A logic error: the program runs, but the result is wrong.
- Compiling only confirms that the language rules were followed. The program can still fail on certain data or do the wrong thing.
References
- Oracle, The Java Language Specification, Java SE 21, section 15.6 (Normal and Abrupt Completion of Evaluation). It states that integer division by zero throws an
ArithmeticExceptionat run time, which supports the runtime-error example. - Oracle,
javaccommand reference, JDK 21. It describesjavacas reading source files and compiling them into class files ahead of running, which supports the compiler description. - The translated-book analogy, the three-error classification, and the build-step discussion are this course's own teaching framing, not claims from a cited source.
Practice
Apply this lesson with the module's lab, exercises and quiz.
Marking a lesson complete is optional and you can undo it any time. Your progress stays in this browser.