Language Translators

intermediate25 min

Learning 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

CompiledInterpreted
Speed once runningFast — already fully translatedSlower — translated on the fly, every run
Error detectionWhole program checked before it can run at allOnly reaches an error once execution gets to that exact line
Development/testing speedSlower to test — must recompile after every changeFast to test — run a single changed line immediately
DistributionShip the compiled executable; source code isn't requiredMust 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:

  1. A professional video game where every frame's performance matters and the final product will be sold to millions of players.
  2. A beginner programmer testing small changes to a Python script one at a time in an interactive session.
  3. 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.

Test yourself

Check your understanding with exam-style questions.

Go to Exam Practice
Log in to track this lesson on your progress dashboard.
Log in