1st Principles

Programming · 21 min read

What Is a Program?

A program is a precise description of a process a computer can execute step by step. Source code is the human-readable form; running it transforms inputs into outputs under fixed rules.

Why this exists

Tools and tutorials jump straight to syntax. That hides the object you are making: a reliable process, not a file full of magic words.

Knowing what a program is separates 'I edited text' from 'I defined behavior the machine will repeat exactly.' That mindset carries across every language and runtime.

Axioms & primitives

  1. 01A program specifies behavior, not just data sitting on disk.
  2. 02Computers execute instructions mechanically; they do not infer intent.
  3. 03The same source can be translated into lower-level forms before it runs.
  4. 04Programs interact with memory, input, and output through a defined model.
  5. 05Correctness is about matching the intended process, not about looking like other code.

Learning objectives

After this lesson you should be able to:

  • Distinguish source code, compiled or interpreted execution, and running process.
  • Explain why computers need unambiguous step-by-step instructions.
  • Describe inputs, outputs, and state in a simple script-sized example.
  • Identify when a bug is a logic error versus a misunderstanding of execution order.

Progressive depth

Read the layers in order for a full explanation. Or open the layer you need.

01

Intuition

A program is a list of instructions with no room for guesswork. 'Add A to B' means fetch A, fetch B, add, store the result. If you skip a step, you get wrong answers every time.

You already use programs when a calculator computes tax or a maps app routes you. The visible app is built from many smaller programs coordinating.

Learning syntax is learning how to write the recipe in a language the toolchain accepts.

02

Formal shape

Source code is text in a programming language. A toolchain parses it, checks rules, and either interprets it step by step or compiles it to machine code or bytecode.

Execution maintains program state (variables, call stack, heap objects depending on the language). Control flow selects which instruction runs next.

Termination, errors, and I/O are part of the program's contract with the environment. Non-functional behavior (time, memory use) still follows from the same process.

03

Worked examples

Pseudocode: read x; read y; print x + y. Inputs are two numbers; output is their sum; state holds x and y while running.

Bug example: print then increment versus increment then print changes observable output order.

Web server program: loop forever, wait for request, compute response, send bytes. Same pattern at larger scale as a tiny script.

04

Edge cases

Concurrent programs interleave steps from multiple logical flows. Reasoning gets harder; the basic 'precise process' idea stays.

Declarative languages describe what should hold, not every step. The runtime still executes a concrete process underneath.

Hardware faults and cosmic rays can flip bits; ordinary programming assumes reliable machines until you work at scale or in safety-critical systems.

Mental models

  • Recipe

    Ingredients are inputs. Steps are instructions. The dish is the output. The cook does not improvise unless the recipe says so.

  • State plus rules

    Memory holds values. Each step updates state according to fixed rules.

  • Translator chain

    Humans read source. Runtimes or compilers turn it into forms the hardware can execute.

Common misconceptions

  • Myth

    The computer understands what you meant.

    Reality

    It follows instructions. Ambiguity becomes a bug or a crash.

  • Myth

    A program is the same as a file.

    Reality

    The file stores text or bytes. The program is the behavior that text defines when executed.

  • Myth

    Printing 'Hello' is too trivial to be real programming.

    Reality

    Even tiny programs exercise the full chain: source, runtime, I/O, and termination.

Exercises

Work these without looking up answers first. Check yourself against the intent notes.

  1. Exercise 01

    Write pseudocode for converting Fahrenheit to Celsius. Label inputs, outputs, and each state change.

    What good looks like

    Shows program as IO plus ordered updates without syntax noise.

  2. Exercise 02

    Why is 'sort these names' not a complete program by itself on a computer?

    What good looks like

    Missing algorithm steps, data representation, and I/O details.

  3. Exercise 03

    Give an example where two programs produce the same output but differ in internal state during execution.

    What good looks like

    Output alone does not capture full behavior; counters or logs differ.

Sources & further reading

External references. Prefer primary documents and clear explainers.