Programming Languages and Translators

All programming languages sit on a spectrum from low-level (close to the hardware) to high-level (close to human language).

Low-level languages

Machine code

• Binary instructions the processor executes directly
• Every operation is a specific bit pattern: opcode + operand(s)
• No translation required — the CPU runs it directly
• Completely hardware-specific: code for one processor family will not run on another

Assembly language

• Uses human-readable mnemonics instead of binary: LDA, ADD, STO, JMP
• One mnemonic maps to exactly one machine code instruction (one-to-one)
• Still hardware-specific: tied to a particular instruction set architecture

High-level languages

• Closer to natural language and mathematical notation
• Imperative high-level languages specify step-by-step what the computer must do (sequence, selection, iteration)
• Machine-independent: the same source code can be compiled for different hardware
• Examples: Python, Java, C++, JavaScript, Pascal

	Low-level	High-level
Execution speed	Fast — directly controlled hardware operations	Slower — compiler/interpreter overhead; optimiser may bridge the gap
Hardware control	Direct — can access specific registers and memory addresses	Limited — abstracted away by the language runtime
Program size	Small — no runtime or standard library overhead	Larger — runtime libraries included
Readability	Poor — mnemonic codes and binary are hard to read	Good — code resembles English / mathematics
Writability	Difficult — programmer manages every detail	Easy — built-in data types, functions, abstractions
Portability	None — code tied to specific hardware	High — recompile for a new platform
Debugging	Hard	Easier — compilers report line-level errors

When to use low-level: embedded firmware, device drivers, OS kernel code, time-critical inner loops where maximum performance and direct hardware access are needed.

Source code is the human-readable program written by a developer. Before a computer can run it, it must be translated into object code (executable machine code). The program that does this translation is called a translator.

Assembler

Translates assembly language source code into machine code.

• One-to-one translation: each mnemonic becomes exactly one machine instruction
• Output: object code ready to execute

Compiler

Translates an entire high-level source program into machine code (or bytecode) before execution.

Steps:

1. Lexical analysis — tokenises the source
2. Syntax analysis — builds a parse tree; checks grammar
3. Semantic analysis — checks type compatibility, scope
4. Code generation — produces machine code or bytecode
5. Optimisation — improves speed or reduces size

Key properties:

• Translation happens once; the compiled program runs without the source code or compiler present
• Faster execution than interpretation (no translation overhead at runtime)
• Errors are reported as a complete list after the whole program is analysed
• Object file is hardware-specific (unless producing bytecode)

Interpreter

Translates and executes the source code line by line at runtime.

Key properties:

• No separate compilation step — run the source directly
• Slower execution — each line is re-translated every time it is reached (e.g. inside a loop)
• Easier to debug interactively — errors are reported immediately at the failing line
• Source code must be present on the target machine
• Useful for scripting, rapid development, and cross-platform environments

Bytecode

Some compilers (notably Java's javac) do not produce machine code directly. Instead they produce bytecode: an intermediate representation that is:

• More compact than source code
• Not tied to any specific hardware
• Executed by a virtual machine (VM) at runtime (e.g. the Java Virtual Machine, JVM)

This gives a middle ground: compile once to bytecode; the VM interprets or JIT-compiles it on any platform.

	Compiler	Interpreter
Translation time	Before execution (once)	At execution (each run)
Execution speed	Fast	Slow
Error reporting	All at once after compilation	Immediately at each failing line
Source code at runtime	Not required	Required
Output file	Executable object code	No output file
Typical use	Production programs	Scripting, development, education

Choosing a translator:

Scenario	Best choice	Why
Final production software	Compiler	Runs faster; no source needed at runtime
Development / debugging	Interpreter	Immediate feedback; test small changes
Cross-platform deployment	Bytecode compiler + VM	Compile once; run anywhere (JVM, CLR)
Embedded/assembly code	Assembler	Direct one-to-one translation to machine code

Source code vs object code: source code is written by developers and is human-readable. Object code (compiled machine code) is binary — understood by the processor, not by humans. A compiled program ships object code; an interpreted program ships source code (or bytecode).

Bytecode and the JVM: Java source (.java) → javac compiles to bytecode (.class) → the JVM interprets or JIT-compiles the bytecode at runtime. This is why Java programs run on any platform with a JVM installed, without recompilation.

1. Claiming interpreters are "better" or "worse" than compilers

Neither is universally better. Compilers produce faster programs; interpreters enable easier debugging and development. The right choice depends on the context — production vs development, scripting vs systems programming.

2. Thinking an interpreter produces an executable file

Interpreters do not produce an output file. The source code is re-translated every time the program runs. Only compilers produce standalone executables.

3. Confusing bytecode with machine code

Bytecode is not machine code — it cannot be executed directly by the processor. It requires a virtual machine (JVM, CLR) to run it. Bytecode is an intermediate form between source code and machine code.

4. Stating assembly language is machine code

Assembly language uses human-readable mnemonics. Machine code is binary. They have a one-to-one correspondence, but they are distinct: an assembler is required to convert one to the other.