Every programming language you use sits somewhere on a spectrum between “translated entirely before running” and “translated as it runs.” Most engineers know the labels - compiled, interpreted - but treat them as trivia rather than something with real engineering consequences.

They’re not trivia. The position a language occupies on this spectrum shapes its startup time, runtime performance, deployment model, when errors are caught, and how useful the tooling can be. Understanding it doesn’t require a compiler course. It requires a mental model.

The core question: when does translation happen?

Your source code is not what the CPU executes. As the previous article in this series covered, the CPU sees binary instructions. Something has to bridge that gap. The question is when.

A compiler does it upfront. You hand it source code; it produces an executable. The translation is complete before the program ever runs. When you run the program, the CPU gets machine code directly.

An interpreter does it at runtime. The interpreter reads your source, understands what it means, and carries out those instructions - without ever producing a standalone executable. The interpreter itself is a compiled program; it executes your code on your behalf.

That’s the essential difference. Everything else follows from it.

What you get with compilation

The compiler has the luxury of time. Before producing output, it can analyze the entire program, catch inconsistencies, and apply optimizations that only make sense when you can see everything at once.

Errors surface early. A type error, an undefined variable, a missing return - these are caught before the program runs. In a compiled language, a program that compiles is at least structurally sound. You still write bugs, but an entire class of mistakes is eliminated at build time.

The output is fast. Machine code runs directly on the CPU with no translation layer. There’s no interpreter in the way. Languages like C, Rust, and Go produce programs that start immediately and run at close to the hardware’s theoretical maximum.

Deployment is a binary. You ship a file. The machine that runs it doesn’t need a language runtime, a specific version of an interpreter, or anything else you wrote. This matters for CLIs, embedded systems, and any environment where you can’t control what’s installed.

The tradeoffs: compilation takes time (long build cycles in large C++ projects are legendary), and the output is architecture-specific. A binary compiled for Linux x86-64 doesn’t run on macOS ARM without recompilation.

What you get with interpretation

The interpreter has a different set of advantages.

Portability. Source code runs wherever the interpreter runs. Python code written on Windows runs unchanged on Linux, because the interpreter handles the platform differences. There’s no recompilation step when you move to a different machine.

Immediacy. There’s no build step. Write code, run code. This makes interpreted languages natural for scripting, for REPLs, for environments where rapid iteration matters more than raw speed.

Runtime flexibility. Because the interpreter is present at runtime, the language can do things that compiled languages struggle with: executing code from strings (eval), adding methods to objects dynamically, reloading modules without restarting the process. This is how Rails can reload code in development, and how Python notebooks execute cells independently.

The tradeoffs: interpreted code is slower than compiled code - sometimes by an order of magnitude - because every operation goes through the interpreter’s dispatch loop. Errors that a compiler would catch at build time surface only when that line of code actually runs.

The blurry middle: bytecode and JIT

The compiled/interpreted binary is increasingly a simplification. Most modern language runtimes sit somewhere between the two poles, and understanding where changes your expectations.

Bytecode compilation is a middle step. Python, Ruby (modern versions), and Java all compile source code to an intermediate representation - bytecode - before running it. Bytecode is not machine code; it’s a compact, structured format designed for a virtual machine to execute efficiently. CPython compiles your .py files to .pyc bytecode files; the interpreter runs those. The compilation is fast and happens automatically, but you still need the runtime to run anything.

The practical effect: slightly faster startup than pure line-by-line interpretation, no machine code for the CPU to run directly.

Just-in-time (JIT) compilation goes further. A JIT compiler starts by interpreting (or running bytecode), watches which parts of the code run most frequently, and compiles those hot paths to native machine code on the fly. Java’s HotSpot JVM, JavaScript’s V8 engine, and LuaJIT all work this way.

The consequence is counterintuitive: a JIT-compiled program can eventually run faster than an equivalent program compiled ahead of time, because the JIT has profiling information the static compiler doesn’t. It knows which branches are taken 99% of the time, which types are always integers, which functions are called in tight loops. It uses that information to generate aggressively optimized machine code.

The cost is warm-up time. A Java server is slow for the first few minutes of its life while the JIT compiles. A JavaScript function that runs once in your build script never gets optimized. This is why JIT runtimes shine under sustained load and struggle with short-lived processes.

Why this matters for decisions you actually make

Cold start and CLI tools. If you’re building a command-line tool that runs and exits quickly, a JIT runtime is a liability. Node.js and Python start in tens to hundreds of milliseconds - fine for a web server, painful for a CLI that runs on every keystroke in an editor. Go and Rust produce binaries that start in single-digit milliseconds. This is one reason tools like ripgrep, esbuild, and fd are written in compiled languages.

Serverless functions. Lambda cold starts under a Python or Node runtime add latency that a compiled Go function avoids. If your function is triggered rarely, the JIT never warms up anyway - you’re paying the interpretation cost without the optimization payoff.

Long-running services. For a web server processing thousands of requests per second, JVM and V8 are competitive with compiled languages after warm-up, and often more productive to write. The runtime overhead amortizes over the process lifetime.

Error detection. Choosing a compiled, statically-typed language means catching more bugs at build time - a meaningful difference in large codebases where a runtime error in a rarely-executed path might not surface for weeks.

None of this dictates language choices by itself. Ecosystem, team experience, library availability, and hiring all matter more in most situations. But knowing the runtime model of the language you’re using means you understand why the performance profile looks the way it does, why cold starts are slow in one environment and not another, and why adding TypeScript’s type checker to a JavaScript project catches a class of bugs that tests alone don’t.

The labels “compiled” and “interpreted” are shorthand. The underlying question - when does translation happen, and what does the runtime environment know? - is what actually determines the tradeoffs.