Language Translators
intermediate25 minLearning objectives
- Distinguish between compilers, interpreters and assemblers
- Explain how source code becomes executable code
- Evaluate suitable translators for different programming languages
Learn
AQA 4.6.5 — Language translators
Retrieval: every program you've written in this course's Coding Lab has been Python — source code, written for humans to read. This lesson asks the question that connects everything back to Fetch–Decode–Execute: how does that human-readable source code actually turn into the machine code a processor can fetch and execute at all?
Key vocabulary
- Source code — a program as originally written, in a human-readable programming language.
- Machine code — instructions in the processor's own binary instruction set, ready to be fetched and executed directly.
- Compiler — translates an entire program into machine code before it runs, producing a standalone executable file.
- Interpreter — translates and executes a program one line (or instruction) at a time, every time it runs, with no separate executable produced.
- Assembler — translates assembly language (a human-readable near-1:1 representation of machine code) directly into machine code.
Understand — two fundamentally different strategies
A compiler reads the whole program once, translates it completely into machine code, and produces a finished executable file — running that file afterwards needs no further translation at all, so it runs at full processor speed. An interpreter never produces a standalone executable: it reads and translates the source code one instruction at a time, every single time the program runs, executing each instruction immediately before moving to the next — which makes testing and debugging fast and immediate, at the cost of repeating the translation work on every run.
Visualise — two different pipelines
Compiled:
Source code ──[Compiler]──▶ Machine code (.exe) ──▶ runs directly, every time, at full speed
Interpreted:
Source code ──[Interpreter reads + runs one line at a time]──▶ output
(translation happens again, from scratch, on every single run)
Compare — the genuine trade-offs
| Compiled | Interpreted | |
|---|---|---|
| Speed once running | Fast — already fully translated | Slower — translated on the fly, every run |
| Error detection | Whole program checked before it can run at all | Only reaches an error once execution gets to that exact line |
| Development/testing speed | Slower to test — must recompile after every change | Fast to test — run a single changed line immediately |
| Distribution | Ship the compiled executable; source code isn't required | Must ship (or the user must have) the interpreter and often the source itself |
Apply it — translator-selection scenarios
For each scenario, recommend compiler, interpreter, or assembler, and justify your choice:
- A professional video game where every frame's performance matters and the final product will be sold to millions of players.
- A beginner programmer testing small changes to a Python script one at a time in an interactive session.
- Safety-critical firmware for a pacemaker, where every individual instruction's exact timing and behaviour must be verified before the device is manufactured.
(1: compiler — maximum runtime speed matters most, and translation only needs to happen once before shipping. 2: interpreter — immediate line-by-line feedback is exactly what fast, iterative testing needs. 3: assembler — assembly gives precise, predictable control over exactly which machine instructions run, essential when instruction-level timing is safety-critical.)
Explain — why Python isn't purely one or the other
It's tempting to call Python "purely interpreted" — but CPython (the version of Python this Coding Lab runs) actually compiles your source code to an intermediate bytecode first, and only then interprets that bytecode, rather than interpreting your original source text directly. This hybrid approach is a genuine middle ground: it avoids the cost of re-parsing raw source code on every single run, while still keeping the fast, no-separate-executable-needed development experience interpreted languages are known for.
Common mistake
Assuming a language is inherently "a compiled language" or "an interpreted language" as a fixed, permanent property. In reality, the same source language can often be translated either way depending on the specific implementation — what actually matters for choosing a translator is the trade-off a given situation needs, not a fixed label attached to the language itself.
Challenge
Explain, in your own words, why a hybrid approach like Python's (compile to bytecode, then interpret the bytecode) might be a deliberately better fit for a teaching and general-purpose language than either a pure compiler or a pure interpreter alone.
Looking ahead: Sequence 9 (Communication, Networking & Responsible Computing) moves beyond a single machine entirely — to how separate computer systems, each running their own processor, memory and operating system exactly as covered in this sequence, communicate with each other at all.