Computing & Programming Foundations
Understand computers, files, terminals, networks, program structure, debugging, and version control before choosing any programming specialization.
How a computer executes a program
Objective Identify the distinct roles of an application, process, operating system, CPU, RAM, storage, input, processing, and output.
Core explanation
A computer is a physical machine that follows instructions to transform information. A program is a stored description of those instructions together with the data they use. When you launch a program, the operating system—the software that manages shared computer resources—creates a running instance called a process. The central processing unit (CPU) performs the process’s instructions, such as copying or comparing values. Random-access memory (RAM) holds the instructions and working values needed now; this working state normally disappears when power ends. Persistent storage keeps deliberately saved files across restarts. An application is a program made for a user task, such as a browser or text editor. Input is information entering the application; processing is the work it performs; output is the result it exposes. Some output is only visible now, while other results are written to storage and remain later. This simplified chain—input, application process, CPU and RAM work, output, optional storage—gives a beginner five distinct places to observe instead of treating “the computer” as one unexplained box.
From a physical machine to an observable result
A computer is a physical machine whose electronic components can represent and transform information. At the lowest useful level for a beginning programmer, a processor repeatedly fetches an instruction, decodes what operation it names, performs that operation, and advances to another instruction. The instruction may copy bytes, compare values, add numbers, or choose which instruction comes next. Billions of these small steps produce the behavior that looks like opening a document, playing audio, or drawing a Web page. Programming does not require memorizing processor circuitry, but it does require understanding that every visible feature eventually becomes finite instructions acting on finite data.
The result is observable only because several components cooperate. Input devices and network interfaces introduce data. Memory keeps instructions and working values close to the processor. Display, audio, files, and network responses expose output. When a program appears frozen, one of these boundaries may be waiting, overloaded, denied, or incorrect. Thinking in boundaries is more useful than saying “the computer is broken,” because it gives you a sequence of places to inspect.
CPU, memory, and storage have different jobs
The CPU is an executor, not a permanent notebook. It has a small amount of extremely fast internal state and accesses main memory for the code and data of running programs. RAM is working space: it holds variables, decoded images, open documents, and operating-system bookkeeping while the machine is powered. Persistent storage keeps files across restarts. Storage is normally much slower than RAM, so programs read data into memory before working with it and deliberately write durable results afterward.
This distinction explains common surprises. Saving a document means requesting a durable write; merely seeing edited text on screen proves only that the new state exists in memory. Closing an unsaved application can discard it. Conversely, deleting a shortcut or stopping a process does not necessarily delete stored data. When designing a program, ask which state may be temporary, which state must survive, when it is written, and what happens if power ends halfway through the write.
The operating system creates a controlled execution environment
Applications do not normally control hardware directly. The operating system owns shared resources and exposes controlled services for files, memory, windows, clocks, devices, identities, and networking. When you launch an application, the operating system creates a process with an address space, permissions, open resources, and one or more threads of execution. It schedules that work alongside many other processes. Isolation prevents an ordinary mistake in one process from freely reading or overwriting every other process.
A program requests services through system interfaces. Opening a file can succeed, fail because the path is wrong, or fail because the identity lacks permission. Allocating memory can fail when resources are exhausted. A network operation can pause because the remote system is slow. Robust programs treat these outcomes as part of normal execution rather than assuming every request succeeds. Error messages often name the boundary that rejected the request.
Programs, processes, and data are related but not identical
A program is a stored description of instructions and supporting data. A process is one running instance of that program. Opening the same editor twice may create two processes from one installed program, each with separate working state. Data is the information those processes read and produce. This vocabulary matters: updating a program file affects future launches, stopping a process ends current execution, and editing a data file changes an input or durable result.
Modern applications often use several processes. A browser may isolate tabs, graphics work, extensions, and network services so one failure has a smaller effect. A server may start multiple worker processes to use several processor cores or contain faults. Do not infer architecture solely from one visible window. Use operating-system process tools, application diagnostics, logs, and resource monitors as evidence.
Trace one action through the whole system
Suppose a learner enters a URL and presses Enter. The keyboard event becomes input to the browser process. Browser code validates and interprets the text, asks operating-system networking services to communicate, receives bytes, stores active representations in memory, and runs parsing and layout instructions on the CPU. The graphics system turns the result into pixels. Cache or history may be written to persistent storage. Each arrow is a contract with possible delay or failure.
Practice this trace with ordinary actions: saving a photo, playing a song, or searching a local document. Name the input, executing program, temporary state, operating-system services, output, and durable state. Then imagine power loss, a full disk, no network, or denied permission. This habit becomes the foundation for debugging, performance analysis, security reasoning, and reliable design.
Laboratory: observe a running program instead of guessing
Choose a harmless application such as a text editor and begin with a written prediction. Predict whether launching a second window creates another process, how memory will change after opening a large file, and which state will remain after the program closes. Open the operating system’s process monitor, record the process identifier, CPU use, memory use, and window count, then perform one action at a time. The exact numbers matter less than the relationship between action and observation. A brief CPU increase while searching means work was executed; sustained memory after opening a document suggests an in-memory representation; disappearance after quitting distinguishes running state from the stored program and document.
Next create a tiny text file, open it, change one line, and pause before saving. The visible edit is now application state in memory. Save it and inspect the file modification time. Make another unsaved change, close the window, respond deliberately to the save prompt, then reopen the file and compare the durable content with your prediction. Write a trace labeled input, process, memory, operating-system request, observable output, and persistent result. Finish by predicting what a read-only file, full disk, or interrupted write would change. State which boundary should fail and what evidence you would seek. The professional habit is to make a falsifiable prediction, collect evidence, and revise the model rather than click randomly.