What Does It Mean for Software to Run?

Learning Question

What does it mean for software to run?

To run software means to turn a stored representation into live behavior through an execution environment.

More precisely, the execution environment acts on the stored representation so that runtime state exists and behavior unfolds over time.

That definition has four parts:

stored representation
execution environment
runtime state
observable behavior

The rest of this chapter uses a small Python file to make each part concrete. The Python example is not the subject by itself. It is a way to see what the general definition means.

Start with a small file:

print("hello")

Save it as hello.py.

Before anything runs, hello.py is only a stored file. It has bytes on disk. Those bytes can be opened in an editor, copied, renamed, deleted, committed to Git, or sent to someone else. None of that means the program is running.

Now run:

python hello.py

The visible result is small:

hello

But several things had to happen before that one line appeared.

From File to Run

The command does not make the text file act by itself.

The shell reads the command line and identifies python as the program to start. The operating system starts a process for the Python interpreter. That process receives hello.py as an argument.

Then the Python interpreter reads the file. It treats the file contents as Python source code, not as arbitrary text. It parses the source, prepares executable runtime material, executes the top-level statement, calls print, writes bytes to standard output, and eventually exits.

The file stayed mostly the same. The run was the temporary activity created around it.

That difference is the first boundary:

hello.py on disk
python process reading hello.py
Python runtime state while executing it
terminal output produced by the run

Those are related, but they are not the same object.

What Exists During the Run

During the run, there is state that did not exist merely because the file existed:

• a Python interpreter process
• command-line arguments
• loaded Python runtime code
• internal representation of the source
• stack frames and values used during execution
• standard output connected to the terminal
• an exit status when the process finishes

Some of that state exists only briefly. After the process exits, hello.py can still remain on disk, but the running instance is gone.

This is why “the file exists” and “the program is running” are different claims.

Returning to the General Answer

For this example, running means:

a stored Python source file
is read by a Python interpreter process
which creates runtime state
and produces behavior over time

The behavior is not stored in the file as an event. The file describes what can happen when the right execution environment reads it.

The same idea applies beyond Python. A C executable, a Java class file, a shell script, and a web server all need some execution environment to turn stored representation into live behavior.

So the general answer is:

To run software means to turn a stored representation into live behavior through an execution environment.

More precisely, the execution environment acts on the stored representation so that runtime state exists and behavior unfolds over time.

What This Chapter Does Not Explain Yet

This chapter does not explain Python internals in depth. It does not teach bytecode, object layout, operating-system process tables, CPU instructions, or terminal implementation.

The Boundary This Chapter Establishes

It only fixes the first mental boundary:

stored representation != running behavior

When someone says “the software runs”, ask what concrete thing is being read, what process or runtime is reading it, what state now exists, and what behavior can be observed.