Source Files Are Inputs, Not Running Programs

Learning Question

Why is a source file an input rather than a running program?

A source file is a stored representation written for a language tool or runtime to read. It can describe possible behavior, but the behavior does not exist until some execution environment reads the file and creates runtime state.

For example:

int main(void) {
    return 0;
}

This C source file can be opened, edited, copied, or compiled. None of those facts means it is running.

The source file becomes useful for execution only when a C toolchain reads it and produces another artifact, usually object code and eventually a native executable.

Source Text Needs a Reader

The same rule applies even when the source file is used directly at launch time.

This Python file:

print("hello")

can be launched with:

python hello.py

But hello.py still did not become a process by itself. The operating system starts a Python interpreter process. The interpreter reads hello.py, parses it, creates internal runtime structures, executes the statement, and writes output.

The source file is the input. The interpreter process is the running container.

Why This Boundary Matters

If a source file were already a running program, then merely saving the file would create behavior. That is not what happens.

A source file can exist in many inactive states:

• on disk
• in a Git commit
• in an editor buffer
• inside a zip file
• attached to a message
• copied to another machine

Those states preserve representation. They do not create a run.

Running requires a reader that treats the file as language input and then creates runtime state.

Source Files Can Have Different Next Steps

Different source files are aimed at different readers:

Source file	Usual next reader	Usual next result
main.c	C compiler	object file or executable pipeline input
Main.java	Java compiler	.class file
hello.py	Python interpreter	runtime execution inside interpreter process
script.sh	shell	command execution inside shell process

The important distinction is not whether the next reader is called a compiler or interpreter. The important distinction is that the source file must be read by something that knows the language.

What This Chapter Does Not Claim

This chapter does not claim every language must produce a permanent executable file.

Some languages compile ahead of time. Some interpret source. Some compile to bytecode. Some mix interpretation and runtime compilation. Some tools cache generated artifacts that the user may never inspect.

Those differences matter later.

The shared boundary is simpler:

source file != running behavior

The source file is one possible input to a run. It is not the run itself.

Mental Model

When you see a source file, ask:

Which language is this written for?
Which tool or runtime reads that language?
Does that reader produce another artifact, start execution, or both?

That question keeps the source file in its proper role: a representation waiting for the next layer.