Topic 02

Compiled vs Interpreted, Runtimes & the Build

Concept

The code a person writes is for humans to read. A computer doesn't run that text directly — something has to translate it into the simple instructions the machine actually understands. How that translation happens splits languages into two broad styles: compiled and interpreted.

Knowing the difference matters because it explains a word you'll meet constantly — "the build" — and what it produces. You don't need the deep mechanics, just the shapes.

A quick analogy: a compiled language is like a book translated and printed in advance — all the translation done up front, before anyone reads it. An interpreted language is like a live interpreter translating sentence by sentence as you speak.

Two routes from source code to running
Compilede.g. Go, Rust, C++
A compiler translates the whole program to machine code ahead of time. Slower to build, fast to run; many errors are caught before it ever runs.
Interpretede.g. Python, JavaScript
An interpreter reads and runs the source as it goes. Quick to try and change; some errors only surface once that line actually runs.

Compiled

A compiled language is translated, ahead of time, into machine code — the low-level instructions the processor runs directly. This translation step is called compiling, and it happens before the program is ever run. The payoff is speed (the translating is already done) and early error-catching (the compiler refuses to finish if the code is badly broken). C, Rust, and Go work this way.

Interpreted

An interpreted language is translated as it runs, line by line, by another program called an interpreter. You don't compile it yourself up front — you run the source directly. This is more flexible and quicker to start tinkering with, but generally slower at runtime, since translation happens while the program executes. Python and JavaScript are classic examples — though modern versions of both quietly compile parts of the code behind the scenes to run faster, which blurs the line (more on that just below).

Runtimes and Bytecode

Many languages sit in between. They compile to a middle form called bytecode, which then runs on a runtime — a program that executes the bytecode on whatever machine it's on. Java's runtime (the JVM), .NET, and the JavaScript engine in your browser all work this way. The runtime is why the same program can run on different computers without being recompiled for each. Compiled-versus-interpreted is really a spectrum, not a strict pair.

The Build

All of this rolls up into the build: the step that turns the source a person wrote into something runnable — compiling it, bundling its pieces together, and packaging it up. The build is a real step that can succeed or fail, and its output is a deployable thing (often called an artifact). You'll meet "the build" again and again in the shipping chapter; this is what it means.

Cadence has two builds. Its backend is compiled and packaged into an artifact the team can deploy to a server. Its frontend JavaScript is bundled together into files the browser downloads and interprets as the page loads. Two halves of one app, two different build steps — and "run the build" is a sentence the team says every single day.

Common Confusions
  • "Compiled and interpreted is a strict either/or." Many languages are hybrids that compile to bytecode and run on a runtime. It's a spectrum, not two sealed boxes.
  • "The build is just another way of saying 'run the code'." The build is a distinct step that turns source into a runnable artifact, and it can pass or fail on its own before anything runs.
  • "Interpreted means no errors are caught until runtime." Modern tooling catches plenty of mistakes in interpreted languages before you run them; the line between the two styles keeps blurring.
Why It Matters
  • "The build" appears constantly in continuous integration and shipping — knowing it produces a runnable artifact makes those later chapters click.
  • The compiled-versus-interpreted distinction explains real tradeoffs you'll hear discussed, like startup speed versus runtime performance.
  • Understanding runtimes demystifies why the same program can run on many machines, which underlies a lot of how software is shipped.

Knowledge Check

What is a compiled language?

  • One translated into machine code ahead of time, before it ever runs
  • One translated line by line by an interpreter while it is actually running
  • One that is simply newer than the older interpreted languages
  • One that can only ever run while connected to the internet

What does "the build" produce?

  • A runnable, deployable thing made from the source the team wrote
  • A written document describing what the software should ultimately do
  • A report of how real users feel about the finished app
  • A list of all the bugs that exist in the source code

What is a runtime, in the bytecode model?

  • A program that runs the bytecode on whatever machine it lands on
  • The original human-written source code before any translation
  • A physical hardware chip built into every single computer's processor
  • The total amount of time a finished program takes to run

Why is "compiled versus interpreted" called a spectrum rather than a strict pair?

  • Many languages are hybrids that compile to bytecode and run on a runtime
  • The terms compiled and interpreted have no real meaning at all
  • Every modern language now avoids both compiling and interpreting entirely
  • Because it only describes how quickly the final program runs

You got correct