Translators & Language Levels (Years 10–11) — Computer Science

High-level vs low-level languages, machine code and assembly, and the translators (compiler, interpreter, assembler) plus the tools an IDE provides.

You write a line like print("Hello") and a computer somehow obeys it. But the CPU has never seen the word "print" in its life. Deep down it understands only binary — patterns of 0s and 1s. Something must sit in the middle, turning the language you can read into the language the machine can run. That something is a translator.

Why this matters: Every program you will ever write is translated before it runs. Knowing which translator does what — and why we bother writing in a readable language at all — explains what really happens between pressing "Run" and seeing a result on screen.

Languages sit on a ladder: readable at the top, raw binary at the bottom.

High-level and low-level languages

A high-level language (Python, Java, C#) is written to suit people. It uses recognisable words and one line can do a lot. A low-level language is written to suit the machine. At the very bottom is machine code — pure binary the CPU runs directly. Just above it sits assembly language, which swaps the binary for short mnemonics like ADD and MOV — still very close to the hardware, but a little kinder to read. Think of it as the difference between a recipe in plain English and the same steps written as terse chemical formulae: both describe the dish, but one is meant for humans and one for machines.

Feature	High-level	Low-level
Readable to humans?	Yes, English-like	Hard (assembly) or impossible (binary)
Needs translating?	Yes, always	Assembly yes; machine code no
Works on any CPU?	Usually portable	Tied to one processor type
Easy to write & fix?	Yes	Slow and fiddly

Compiler vs interpreter

A compiler makes a finished executable; an interpreter works line by line.

A high-level program can be translated two ways. A compiler translates the whole program in one go into an executable file of machine code. Translating takes time up front, but the finished executable then runs quickly every time with no translator present — like getting a whole book professionally translated and printed. An interpreter instead translates and runs the program one line at a time, every time it runs. It is slower, and needs the interpreter present to run — but because it stops the instant it hits a bad line, it is far easier to debug. That is like a live interpreter at a talk, speaking each sentence as it is said.

Assemblers and the IDE

Whatever the translator, the goal is the same: machine code the CPU can run.

There is a third translator: an assembler, whose only job is turning assembly language into machine code — a straightforward, almost one-to-one swap. Most of the time you write and translate inside an IDE (Integrated Development Environment): a single toolbox that bundles an editor (with helpful highlighting), a debugger and error diagnostics to catch mistakes, and a run/translate button so you can test in one click.

An IDE gathers the editor, debugger and run button into one place.

Worked example: You are writing a small game and want to test it after every tiny change, spotting bugs as you go. Which translator suits you? — An interpreter: it runs line by line and stops right at the first error, so debugging is quick. Once the game is finished and you want it to run fast for players, a compiler produces a single speedy executable.

Common mistake: A compiler does not run your program — it only produces the executable, which you then run separately. An interpreter, by contrast, translates and runs at the same time.

Tip: remember the trade-off — compiled = slow to build, fast to run; interpreted = quick to test, slower to run. And every high-level language must be translated to machine code before the CPU can do a thing with it.