Compiled vs Interpreted: It's Just a Question of When Your Code Gets Translated
Your code is text a CPU can't run — something has to translate it, and compiled-vs-interpreted is just a question of when. A compiler translates the whole program up front into a fast executable; an interpreter translates it line by line at runtime.
Compiled languages (C, C++, Rust, Go) translate the whole program up front into a machine-code executable that runs fast. Interpreted languages (Python, Ruby) translate and run it line by line at runtime — instant to start and portable, but slower. Most interpreted languages actually compile to bytecode and JIT-compile the hot paths on the fly (V8, the JVM, PyPy), so in practice it is a spectrum, not two separate boxes.
Transcript
Your code is just text — a CPU can't run it. Something has to translate it into machine instructions, and WHEN that happens sorts languages into two camps — on the surface. Compiled, or interpreted. Think of translating a book: all at once, up front — or live, sentence by sentence? That one choice shapes speed and portability.
A compiled language translates the WHOLE program ahead of time. A compiler turns your source into machine code — typically a standalone executable — before it ever runs. Like paying a translator to render the entire book once. Running it is then blazing fast: it's already the CPU's native language. That's C, C++, Rust, Go.
An interpreted language skips that step. In the classic form, an interpreter reads your source and runs it directly, at runtime — no separate machine-code executable. Like a live interpreter, translating as you read. Start instantly, run anywhere the interpreter's installed — but it works through your code every run, so it's slower. Python, Ruby.
Here's where the tidy split breaks down. Most of these languages first compile your source to BYTECODE — and then some runtimes go one step further. A JIT watches which code runs HOT, compiles those paths to real machine code on the fly, and caches them — near-native speed. That's JavaScript's V8 and the JVM.
So it's a spectrum, not two boxes. Compiling ahead of time wins on raw speed and shipping one binary — great for systems and performance-critical code. Interpreting wins on fast iteration and portability — no build step, run it anywhere. And a JIT quietly gives you both, translating the hot parts as it learns them.
Same job — turn your text into something the CPU runs. The only real difference is WHEN the translation happens: all up front, live, or lazily on the hot paths. So next time someone calls a language 'compiled' or 'interpreted', ask the sharper question: when does it actually translate your code — up front, live, or on the hot paths?