EducationOctober 4, 20264 min read

Compiled vs Interpreted Languages: What Happens to Your Code Before It Runs

A compiler translates a whole program before it runs; an interpreter works through it as it goes. How each works, where Python and Java fit, and why it matters.

The short version: a compiled language is translated into machine instructions before the program runs, while an interpreted language is read and carried out by another program, the interpreter, as it goes. The longer version is more interesting, because most modern languages mix both approaches, and "compiled or interpreted" really describes a particular implementation rather than the language itself.

Why translation is needed at all

A processor understands only machine code: long sequences of numeric instructions specific to its chip family. Nobody wants to write that by hand. Programming languages exist so people can write instructions in something closer to English and mathematics. Something has to bridge the gap, and there are two classic ways to do it.

What a compiler does

A compiler reads the entire source code, checks it, and produces a separate output file, often an executable, containing machine instructions. That translation happens once. Afterwards, the executable can run without the compiler and without the original source. C, C++, Rust and Go are typically used this way.

What an interpreter does

An interpreter takes the source code and executes it directly, working through it statement by statement while the program runs. There is no standalone executable; the interpreter must be present every time. Classic scripting languages grew up this way, which is why running a script usually means typing the interpreter's name followed by the file name.

Side by side

Aspect	Ahead-of-time compiled	Interpreted
When translation happens	Before running, in a separate build step	While the program runs
What you share with users	A ready-made executable for their system	The source code, plus the need for an interpreter
When many mistakes appear	At compile time, before anything runs	Often only when the faulty line is reached
Speed of trying a change	Rebuild first, then run	Edit and run immediately
Typical run speed	Generally fast, since translation is already done	Generally slower for heavy computing, though often fast enough
Portability	A build targets a specific platform	Runs wherever the interpreter is installed

The blurry middle: bytecode and just-in-time compilation

Real-world languages rarely sit neatly in one column.

Java and C# are compiled, but not into machine code. They become bytecode, an intermediate format run by a virtual machine. The virtual machine turns that bytecode into machine code as the program runs, usually spending extra optimisation effort on the parts used most.
Python, in its standard implementation, quietly compiles source files into bytecode first and then interprets that bytecode. The cache folders that show up beside imported Python modules hold that bytecode.
JavaScript was long described as interpreted, yet modern browser engines use just-in-time (JIT) compilation, translating hot sections of code into machine instructions on the fly.

So when someone asks "is Python compiled or interpreted?", the honest answer is "both, in stages, but it behaves like an interpreted language from the user's point of view": you run the source file directly and there is no separate build step.

What it changes for a beginner

Day to day, the difference shows up in three places.

The feedback loop. Interpreted languages let you type a line into an interactive prompt and see the answer instantly, which is one reason many first courses start there.
When errors surface. A compiler refuses to build a program with certain mistakes, such as a mistyped keyword or, in strictly typed languages, a number passed where text was expected. In an interpreted language, the same mistake may only be reported when that line runs. Either way, learning how to read an error message calmly is the skill that pays off most.
The tooling. Compiled languages add a build step, and development environments usually hide it behind a single run button. The guide to IDEs and code editors covers what that button actually triggers.

Misconceptions worth dropping

"Interpreted means not a real language." Huge amounts of production software run on languages usually labelled interpreted.
"Compiled code is always faster." It often is for heavy computation, but the slow part of many programs is waiting for a network or a disk, which no compiler can fix.
"The language decides." Implementations decide. The same language can have a compiler and an interpreter, and some do.

Short answers

Is a compiler the same as an assembler?

No. An assembler translates assembly language, a thin human-readable layer over machine code, almost one instruction at a time. A compiler handles a much higher-level language and does far more analysis and rearranging along the way.

Which kind should a first language be?

It matters less than sticking with one language long enough to finish a few small projects, a point made in the advice on becoming a computer programmer. Many people start with an interpreted language for the instant feedback and meet compiled languages later, when the build step feels like a small extra rather than a hurdle.

Do I need to understand machine code?

Not to get started. Knowing that a translation step exists, and roughly when it happens, is enough to make sense of build buttons, error timing and why some programs need an interpreter installed.