Source Code, Compiled Code and Interpreted Code
By the end of this lesson
Distinguish compiled and interpreted execution, and explain where C# sits between them.
Languages differ in when translation happens, and that single difference explains a lot about how they feel to work with.
The two classic approaches:
| Compiled ahead of time | Interpreted as it runs | |
|---|---|---|
| When translation happens | Before you run it, as a separate build step | Line by line, while running |
| Errors in your syntax | Reported before anything runs | Often reported only when that line is reached |
| Typical speed | Faster, translation already done | Slower, translation repeated at run time |
| Feedback loop | Build, then run | Run immediately |
C# sits in between, and that is deliberate
C# is compiled, but not directly into instructions for your particular processor. It is compiled into an intermediate form. When you run the program, the runtime translates that intermediate form into native instructions for whatever machine it happens to be on.
This two-stage approach is why the same compiled output can run on Windows, Linux and macOS. It also means the runtime can optimise based on what your program is actually doing, which occasionally makes it faster than a single ahead-of-time translation would be.
The practical consequences for you:
- You get real errors before running, which catches typos and type mistakes early
- The same build artifact runs on different operating systems
- There is a build step, so "it did not pick up my change" usually means you did not rebuild
- Startup does a little work before your first line runs, which matters for very short-lived programs
Summary
- Compiled languages translate before running; interpreted languages translate while running
- C# compiles to an intermediate form, which the runtime turns into native instructions on the target machine
- The build step is what allows errors to be caught before execution — and why stale results usually mean a missing rebuild
Practice
Attempt each one before opening the solution. Getting it wrong first is how the idea sticks.
Think about it
Think about it
Why might a language that reports errors before running be easier to work with on a large project, even though it adds a build step?
Show solution
On a large project, most code is not executed on any given run. An interpreted language may not reach a broken line for weeks, whereas a compiler checks everything every build.
Renaming something is the clearest case: a compiler lists every place that needs updating immediately, instead of leaving you to discover them one crash at a time.
Saved in this browser only.