Interpreter
A way of running code by executing its meaning step-by-step, rather than producing a standalone executable ahead of time.
Definition
An interpreter is a way of running code by reading it (or an intermediate form of it) and executing its meaning step-by-step, rather than producing a standalone executable ahead of time.
In many systems, the interpreter is itself a program that:
- parses source code (or reads bytecode/IR),
- evaluates it using an execution loop,
- and calls into runtime libraries as needed.
Synonyms and related terms
- Related: VM, bytecode, evaluator, REPL
- Often paired with: JIT compilation
What interpreter-based execution implies
- There is always a program doing the interpreting - the interpreter itself is a program.
- Startup and performance characteristics can differ from ahead-of-time compiled code, depending on how much translation and optimization happens at runtime.
- The runtime environment must include the interpreter and any runtime libraries it depends on.
Interpreter vs JIT vs AOT
- JIT compilation can exist inside an interpreter-based system to speed up hot paths.
- AOT compilation produces code ahead of time, so less translation work happens at startup/runtime.
Common misconceptions
- “Interpreted means slow” is not universally true. Many interpreter-based systems use JITs and sophisticated optimization.
- “Interpreted means no compilation” is also not true. Compilation may happen to bytecode or to machine code at runtime.
Operational considerations
Interpreter-based systems often place more weight on:
- consistent runtime availability across environments
- startup/warmup behavior (especially with JITs)
- memory and CPU characteristics of the runtime
Mini-scenario
A “script” runs fine on a developer laptop but fails in a minimal container image because the interpreter runtime (and its native dependencies) aren’t present. The artifact that needs to be deployed is not only the source code. It also includes the interpreter and libraries required to execute it.