How Software Actually Runs
By the end of this lesson
Describe the path from the code you type to instructions a processor carries out, and name the parts involved.
You type text into a file. Somehow a processor ends up doing work. The steps in between are worth knowing, because a surprising number of confusing errors are really one of those steps failing.
Four things are involved, and they are often confused with each other:
- Source code
- The text you write. It is for humans. A processor cannot execute it directly.
- Compiler
- A program that reads your source code and translates it into a form suited to execution. It also refuses to continue if your code does not make sense, which is the first line of defence against bugs.
- Runtime
- The software that runs your translated program: it allocates memory, cleans up values you no longer use, and provides ready-made building blocks such as file access.
- Process
- Your program while it is actually running, with its own slice of memory. Close it and that memory goes away, which is why data has to be saved somewhere if you want it to survive.
Why the compiler is your ally
Beginners often read compiler errors as rejection. They are closer to proofreading. The compiler has spotted something that could not possibly work and is telling you now, while it costs you thirty seconds, rather than later when a customer finds it.
A compile error is the cheapest kind of error there is. The expensive kind is the program that runs happily and produces a wrong number.
Two categories of problem, with very different costs:
| Compile-time error | Run-time error | |
|---|---|---|
| When you find out | Before the program runs at all | While the program is running, possibly in production |
| Typical cause | Misspelled name, wrong type, missing bracket | Missing file, no network, unexpected input, division by zero |
| Cost to fix | Low — the compiler points at the line | Higher — you must work out what the conditions were |
| Can it be fully prevented? | Yes, by fixing the code | No, but it can be handled deliberately |
Memory, in one paragraph
While your program runs, its values live in memory. Memory is fast and temporary. When the process ends, everything in it is gone. If a value needs to outlive the program — a saved order, a user account — it has to be written to a file or a database. This is the distinction between a program that calculates and a system that remembers, and it catches many people the first time they close an application and find their data missing.
Summary
- Source code is translated by a compiler into something executable, then run by a runtime inside a process
- Compile-time errors are cheap and specific; run-time errors depend on conditions and cost more to diagnose
- Memory is temporary and belongs to the process — persistence must be added deliberately
Practice
Attempt each one before opening the solution. Getting it wrong first is how the idea sticks.
Think about it
Think about it
A program adds up a list of prices and shows the total. You close it and reopen it, and the total is gone. Nothing is broken. Why is this the expected behaviour?
Show solution
The total lived in memory, which belongs to the process. When the process ended, that memory was released.
To keep the total, the program would have to write it somewhere that survives independently — a file, or a database. Persistence is something you add deliberately; it is never automatic.
Knowledge check
Nothing is recorded and there is no score. The explanation appears either way.
Saved in this browser only.