From Code to a Running Program

Code, as the last two topics showed, is text a person wrote — a list of instructions in some programming language. A program, on the other hand, is something the computer actually runs. Those are not the same thing, and getting from one to the other takes a step that is easy to miss.

The gap is real: a computer can't run human-written text directly. The instructions have to be translated into something the machine itself can carry out. That translation happens in one of two common styles, and knowing which one a tool uses explains a surprising amount of everyday tech behavior.

Source codetext you wrote

→

Translatecompile or interpret

→

Running programit does its job

Why a translation step is needed at all

The CPU — the part of the computer that does the actual work — understands only its own very simple set of instructions, made of numbers. Human-written code, even when it reads almost like English, means nothing to it. Something has to stand in the middle and convert one into the other.

That converting is the whole subject of this topic. There are two long-standing ways to do it, and they differ mainly in when the translation happens: all at once, before the program runs, or bit by bit, while it runs.

Compiling: translate the whole thing first

In the first style, called compiling, a tool reads all of your code at once and translates it into a finished, runnable file before anyone runs it. That step is the "build." Once it's done, you have a program the machine can run on its own, with the original code no longer needed to start it.

Think of a book translated from one language to another. A translator works through the whole book once, and afterward anyone can pick up the translated copy and read it freely, as fast as they like, without the translator in the room. Compiling is that up-front translation: do the work once, then run the result as often as you want.

The trade-off is that you pay the translation cost before the program can run, and you have to redo it whenever you change the code. In return, the finished program tends to start fast and run fast, because all the translating is already behind it.

Interpreting: translate while it runs

The second style, called interpreting, skips the up-front build. Instead, a tool called an interpreter reads your code and translates it line by line, on the spot, every time the program runs. There's no separate finished file — the original code is what runs, with the interpreter doing the translation as it goes.

This is the live interpreter at a meeting, rather than the translated book: someone listens to each sentence and renders it into the other language right then, every time the meeting happens. Nothing is prepared in advance, which is convenient, but the translating work is repeated on each run.

So an interpreted program usually starts without a build step and is quick to change and try, but it carries the translation cost every time it runs, which tends to make it a little slower than a compiled one. This is the simplified picture — real tools blur the line, and the deep-dive language courses fill in the rest.

Why this matters to you

The split explains why some programs arrive as a single file you just open, while others need extra tools installed before they'll run. A compiled program often ships as that one ready-to-run file; an interpreted one needs its interpreter present on the machine to translate the code each time.

It also explains the word "build," which turns up constantly later. When you hear that software was "built," or that a Docker image is "built," that's this compile-style translation step producing a runnable result ahead of time — the same idea you've just met, under a name you'll see everywhere.