How Do C, Java, and Python Choose Different Execution Paths?

Learning Question

How do C, Java, and Python choose different execution paths?

The Python path from the earlier chapters looked like this:

hello.py
-> python hello.py
-> Python interpreter process
-> Python runtime executes the source-derived code
-> output appears

That is one execution path, not the universal shape of all software.

Different language ecosystems choose different agreements about what gets stored, what gets translated ahead of time, what the operating system starts, and what runtime must exist.

Python: Source Read by an Interpreter Runtime

For a small Python file:

print("hello")

the usual path is:

Python source file
-> Python interpreter process
-> internal runtime material
-> interpreter-managed execution

The operating system starts the interpreter process. The interpreter reads the source file and owns Python-level execution.

There may be bytecode caches or packaged forms, but the ordinary mental model is still interpreter-centered: the Python runtime is present at execution time and manages the program’s language behavior.

C: Source Translated to a Native Executable

A similar C program might look like:

#include <stdio.h>
 
int main(void) {
    printf("hello\n");
}

The common path is:

C source file
-> compiler and linker
-> native executable file
-> operating system starts a process from that executable
-> machine instructions execute

The operating system does not normally start a C source file. It starts a native executable produced earlier by the toolchain.

That executable is still a stored representation before it runs. It has to be loaded into a process and executed on a target platform.

So C is not “the file runs by itself.” The translation step is earlier and produces a different kind of file for the operating system to load.

Java: Source Translated to JVM-Loadable Artifacts

A small Java program might look like:

class Hello {
    public static void main(String[] args) {
        System.out.println("hello");
    }
}

The common path is:

Java source file
-> javac produces class files
-> java starts a JVM process
-> JVM loads class data
-> JVM executes bytecode and manages runtime behavior

The operating system starts a java process. The JVM inside that process loads and executes JVM artifacts.

Java source usually does not become a native executable in the same direct way as a C program. It becomes material for the JVM execution environment.

The Comparison That Matters

The key question is not “which language is more real” or “which one really runs.”

They all run when stored representation becomes live behavior. They differ in where translation happens and what reader owns the next step.

Language path	Common stored input before run	What the OS starts	Main runtime owner
Python	source file or package	Python interpreter	Python runtime
C	native executable built from source	native executable process	OS and machine execution, with libraries
Java	class files or JAR	JVM process	JVM runtime

This table is simplified, but it preserves the important boundary: language-level source, executable artifacts, runtime processes, and observed behavior are different layers.

Avoiding the Wrong Expectation

If you expect every language to run like Python, C’s compiler and linker can look like extra ceremony.

If you expect every language to run like C, Python can look unfinished because the interpreter is still needed.

If you expect every language to run like Java, the distinction between operating-system process and managed runtime can blur.

Each ecosystem chooses a different execution contract:

what representation is stored
what tool reads it
what artifact or runtime material is produced
what process the operating system starts
what runtime manages behavior

The execution contract is not a moral ranking. It is the practical path from representation to behavior.

What This Chapter Leaves to Later Collections

This chapter does not teach C compiler phases, executable formats, JVM class loading, bytecode verification, JIT compilation, or Python interpreter internals.

Those topics belong to deeper collections.

The point here is the starting comparison: C, Java, and Python choose different paths, but all three still require readers, runtime state, and behavior over time.