HookGrace Hopper refused to keep writing in numbers
In 1952 Grace Hopper, a US Navy officer and mathematician, built the first working compiler — a program that turns human-readable instructions into the raw numbers a processor executes. Her colleagues told her it could not be done: computers, they insisted, could only do arithmetic on numbers, not translate words. She was tired of hand-writing long columns of binary machine code and looking up each instruction's numeric value by hand, and she was certain a machine could do that clerical work itself. She was right, and the entire modern software industry runs on the idea she proved: you write in a language built for humans, and a translator converts it into a language built for the CPU.
OCR's section 2.5 is that story split in two. First, the levels of language: high-level languages like Python that read almost like English, and low-level languages — machine code and assembly — that speak to the hardware directly. Second, the tools that make writing code bearable: the compiler and interpreter that do Hopper's translation, and the Integrated Development Environment (IDE) that bundles the editor, the translator, the debugger and a place to run your program into one window. Both leaves are pure Paper 2 knowledge-and-application marks, and both reward you for explaining why each tool exists, not just naming it.
ModelThe ladder of abstraction: high-level vs low-level
A high-level language (Python, Java, C#, VB) is written for people. One statement, like total = price * quantity, is close to English and maths, and a single line can stand for many machine instructions. High-level code is portable — the same program can run on different processors once it is translated for each — and it is far easier to read, write and debug. The trade-off is that it must always be translated before the CPU can run it, and the programmer has little direct control over exactly how memory and the processor are used.
A low-level language is written for the machine. There are two: machine code, the binary opcodes the CPU actually executes, and assembly language, a thin human-readable layer over machine code using short mnemonics. Low-level code is not portable — it is written for one specific processor's instruction set — and it is hard and slow to write, but it runs fast, uses memory efficiently, and gives total control over the hardware. That is why device drivers, embedded controllers and performance-critical routines are still written this way.
The rule of thumb the exam wants: as you climb from machine code to a high-level language, code gets easier for humans and more portable, but you hand more control to the translator.
The same instruction at three levels. High-level (Python): total = a + b — one clear line. Assembly (mnemonics, for one imagined CPU): LDA a loads the value of a into the accumulator; ADD b adds the value of b to it; STA total stores the result into total. Three separate steps for one high-level line. Machine code (what the CPU truly runs) is those same three steps as binary, for example the LDA might be the pattern 0001 0100 where the first four bits are the opcode and the last four are the address. A human can read the Python at a glance, struggle through the assembly, and barely parse the binary — which is exactly the ladder of abstraction, and exactly why Hopper wanted a translator.
MechanismMachine code and assembly — speaking to the CPU
Machine code is the only language a processor genuinely understands: streams of binary in which each instruction has an opcode (the operation, such as 'load' or 'add') and usually an operand (the data or the address to act on). Writing it by hand is brutal and error-prone, which is the very problem assembly language solves. Assembly replaces each binary opcode with a short mnemonic — LDA, ADD, STA, JMP — so a human can read and edit it, while keeping a one-to-one relationship with machine code: one assembly instruction becomes exactly one machine instruction.
Because of that one-to-one mapping, assembly is translated by a dedicated translator called an assembler, which simply swaps each mnemonic for its binary opcode. This is why assembly is still tied to a single processor family: the mnemonics correspond to that CPU's specific instruction set, so ARM assembly will not run on an x86 chip. Understanding this pins down the difference the exam tests — assembly is low-level and human-readable, but it is not the same thing as machine code, and it still needs translating.
A short assembly routine that adds two numbers and stores the result. LDA num1 — load the value stored at num1 into the accumulator. ADD num2 — add the value stored at num2 to the accumulator. STA answer — copy the accumulator's contents into the memory location answer. Three mnemonics, three machine-code instructions after assembling, one-to-one. Compare that with the single Python line answer = num1 + num2: the high-level compiler or interpreter would have to generate roughly this same sequence of low-level steps for you. Assembly makes each step explicit; a high-level language hides them.
ModelTranslators: compiler vs interpreter vs assembler
A translator is any program that converts source code from one language into another, and there are three types. An assembler translates assembly language into machine code, one-to-one. A compiler translates a whole high-level program into machine code in one go, producing a standalone executable file that can then be run on its own, without the compiler and without the source code. A compiled program runs fast because translation already happened, and it is easy to distribute without revealing your source — but compiling takes time up front, and errors are all reported together at the end of compilation, which can make debugging slower.
An interpreter translates and executes a high-level program one line at a time, every time it runs. There is no separate executable produced; the interpreter must be present each time. That makes interpreted programs slower to run and it re-translates on every execution, but it is excellent for development: it stops at the first error it hits and reports exactly where, so you can fix bugs line by line. Python is normally interpreted; languages like C are normally compiled. The exam's favourite question is the trade-off, so learn the contrast as pairs: speed of execution, whether an executable is produced, and ease of debugging.
A team is deciding how to ship two things. For the finished game they will sell to customers, they choose a compiler: it produces one fast executable that runs without the source code, so players cannot easily read or copy it and it runs at full speed. For the messy data-analysis script one developer is still writing and testing, they use an interpreter: it runs immediately with no compile step and halts at the first error with a line number, so bugs are quick to find. Same code could be either — the choice is driven by whether you are distributing a finished product (compiler) or actively developing and debugging (interpreter).
CaseWhat an IDE actually gives you
An Integrated Development Environment (IDE) is a single application that bundles all the tools for writing, translating, running and fixing code — IDLE and Thonny for Python (Thonny ships on the Raspberry Pi), Visual Studio, and PyCharm are all IDEs. OCR names four tool categories, and you should be able to state each and say how it helps the programmer.
The editor is where you write code, but it does more than a plain text editor: syntax highlighting colours keywords, strings and comments so mistakes stand out; auto-indentation and auto-complete speed up typing and reduce errors; and line numbers make it easy to jump to a reported fault. Error diagnostics help you find bugs: error messages name the problem and its line, breakpoints let you pause execution at a chosen line, stepping runs one line at a time, and a variable watch window shows the live value of each variable so you can see exactly where it goes wrong. The run-time environment lets you execute the program inside the IDE, without needing separate software, and see the output immediately. And the built-in translator (a compiler or interpreter) converts your code so it can run — the same translation Grace Hopper's compiler did, now one click away.
A programmer's variable is mysteriously 0 when it should be 45. Using the IDE's error-diagnostics tools: they set a breakpoint on the line inside the loop, then run — execution pauses there. They open the variable watch and see total = 0 and count = 0 on the first pass, which is expected. They step forward one line at a time and watch total: it never changes, because the line meant to add to it reads total = count (overwrite) instead of total = total + count (accumulate). The breakpoint froze the program at the scene, the watch window exposed the wrong value, and stepping revealed the exact faulty line — three IDE features doing one job. Without them, the programmer would be guessing with print statements.
VocabularyKey terms the mark scheme pays for
TrapsMisconceptions that cost marks
ExamWhat examiners want
Languages and IDEs is Paper 2 (J277/02) territory, and the marks come from linking a feature to its consequence rather than listing. If a question asks you to compare a compiler and an interpreter, do not just define them — contrast them on the axes examiners reward: speed of execution, whether a standalone executable is produced, whether the translator must be present to run, and ease of debugging. A tidy structure is 'a compiler does X, which means Y for the programmer', repeated for the interpreter.
For 'state the characteristics of a high-level / low-level language', always pair each characteristic with an effect: 'high-level code is portable, so the same program runs on different machines once translated'. Bare adjectives ('it is easier') score less than a characteristic plus its reason.
For IDE questions, the classic ask is 'describe two tools/features of an IDE and explain how each helps a programmer' — an AO2 application task. Name the tool (editor with syntax highlighting, breakpoints, a run-time environment, the built-in translator) and then say precisely what it lets the programmer do (spot a mistyped keyword, pause and inspect a variable, run code without other software, convert code so it can run). Match the number of points to the marks: a 4-mark question usually wants two features, each with an explanation.