compiled versus interpreted execution

There are two basic ways to get a computer to run a program you wrote in a human-friendly language. The first is to translate the whole thing up front into the machine's own language and then run the result - like having a book translated once and printing it. The second is to translate and act on it line by line as it runs - like a live interpreter standing beside you, turning each sentence into the other language on the spot. The first is compiled; the second is interpreted.

In compiled execution, a program called a compiler reads your source code and produces a standalone file of machine code ahead of time. You run that file directly; the original source is no longer needed at run time, and the CPU executes the machine instructions natively, which is usually fast. In interpreted execution, a program called an interpreter reads your source and carries out its meaning step by step every time you run it - there is no separate machine-code file, and the interpreter must be present each time. This is usually slower but more flexible and easier to run anywhere the interpreter exists.

Why it matters - and the honest nuance: the split is real but not a clean either/or. The same language can be both, and most modern systems blur the line. Java and C# compile to an intermediate bytecode that a virtual machine then interprets or just-in-time compiles to machine code while running. CPython interprets bytecode; many JavaScript engines interpret then JIT-compile hot code. The useful takeaway is the trade-off it captures: compiling trades up-front translation time for fast, portable-only-after-rebuild execution; interpreting trades run-time speed for flexibility and immediacy. C, the language of this domain, is firmly compiled.