Tech & AI, Explained

what-is-a-program

7 min read

What is a program?

Status: đźź© COMPLETE Last updated: 2026-06-20 Plain-English tagline: A recipe a computer follows. Written by a human in a language a computer can be made to understand, then turned into instructions the CPU runs.

In plain English

A program is a set of instructions a computer follows to accomplish something. Just like a recipe tells a cook “chop the onion, then sauté it for 5 minutes,” a program tells a computer “read this number, add 2 to it, store the result, then print it on the screen.”

The difference is scale and speed. A recipe has maybe 20 steps. A program might have millions. The cook takes minutes per step; the CPU does billions of steps per second. The result is software — the apps, websites, games, and tools you use every day.

When you “write a program,” you’re writing the recipe in a programming language — JavaScript, Python, Go, Rust, whatever. The computer doesn’t understand that language directly; another program (a compiler or interpreter) translates it into instructions the CPU can execute.

You don’t see the final instructions — they’re tiny, low-level operations like “load this byte from memory” or “compare these two numbers.” The whole point of programming languages is that you don’t have to think at that level. You write if (user.isLoggedIn) showDashboard() and the language tools turn it into thousands of CPU instructions for you.

Why it matters

This is the conceptual layer underneath every other entry in this encyclopedia. “JavaScript runs in the browser” makes sense once you grasp:

  1. JavaScript is a programming language.
  2. The browser includes a JavaScript engine that interprets it.
  3. The engine turns your JavaScript into CPU instructions.
  4. The CPU runs them.

Same for Next.js running on Vercel: your code is JavaScript/TypeScript, Vercel’s servers have Node.js installed, Node interprets your code into CPU instructions, the CPU runs them, the output is sent back over the network.

Once “what is a program” is solid, you stop being mystified by how all of this works and start being mystified only by which program does what in any given setup.

Source code vs running code

A program has two forms:

Source code — what you read and write. Text in a programming language:

function greet(name) {
  return `Hello, ${name}!`;
}

Editable. Comments, formatting, meaningful names. The file might be called greeting.js.

Running code — what the computer executes. Either:

  • Bytecode or machine code (very low-level, unreadable to humans)
  • Or, for interpreted languages, the source itself fed line-by-line through an interpreter

Two main pathways:

ApproachExamplesWhat happens
CompiledC, C++, Rust, GoA compiler converts source code → machine code (an .exe file or similar) ahead of time. Fast at runtime.
InterpretedJavaScript (in older engines), Python, RubyAn interpreter reads source code and runs it on the spot. Slower but more flexible.
Hybrid / JITModern JS engines (V8), Java, C#Source compiles to bytecode, then a “just-in-time” (JIT) compiler turns hot paths into machine code at runtime. Best of both.

JavaScript is technically interpreted, but modern engines (V8 in Chrome and Node.js) do JIT compilation. Your code runs fast because the engine watches what’s used a lot and optimizes it on the fly.

What “running” actually means

When you double-click an app icon or type npm run dev:

  1. The OS finds the program file on disk
  2. Loads it into RAM
  3. Tells the CPU “start executing here”
  4. The CPU reads each instruction in turn, does what it says
  5. The program may interact with: memory (RAM), files (disk), the network, the screen, input devices
  6. When the program is done, it exits — the OS reclaims its memory

A running program is called a process. The OS shows you them in Task Manager / Activity Monitor / ps. A computer typically has hundreds of processes running at once — most of them invisible OS services keeping things humming.

Code vs data

Programs deal with two things:

  • Code — instructions. What to do.
  • Data — values. What to do it to.
const name = "George";       // data
console.log("Hi", name);     // code (instructions that act on data)

The line between them blurs in interesting ways:

  • Code is stored as data in memory while it’s not executing
  • Some languages let programs generate code and run it (e.g. eval() in JavaScript — usually a bad idea)
  • AI models are data (the weights) running through generic code (matrix multiplication)

But at the base layer: code is the recipe, data is the ingredients.

A concrete example

Tiny program. Different views:

Source code (JavaScript):

const numbers = [1, 2, 3, 4, 5];
const sum = numbers.reduce((total, n) => total + n, 0);
console.log("Sum:", sum);

What it does, in English:

  1. Start with a list of five numbers.
  2. Add them up one by one, starting from zero.
  3. Print “Sum:” followed by the total.

What the CPU eventually does (simplified, in pseudo-instructions):

LOAD register0, address_of_numbers
LOAD register1, 0           ; initialize total to 0
LOAD register2, length      ; loop counter
loop_start:
  COMPARE register2, 0
  JUMP_IF_ZERO loop_end
  LOAD register3, [register0]
  ADD register1, register3
  ADD register0, 8          ; move to next number
  SUB register2, 1
  JUMP loop_start
loop_end:
  CALL print, "Sum:", register1
EXIT

Hundreds of those simple CPU instructions per JavaScript statement. The CPU does them in microseconds. You see: Sum: 15.

Common gotchas

  • “Bug” doesn’t mean “your computer is broken.” A bug is a mistake in the program — the recipe says the wrong thing. Computers do exactly what they’re told; the bug is usually in the telling.

  • Compiled and running aren’t the same. A program that compiles without errors can still crash at runtime. Compilation checks the recipe’s grammar, not whether it works.

  • Programs don’t “know” their data. A program written to sum numbers will dutifully try to sum strings if you give it strings — and produce nonsense (or an error). The program has no understanding; only instructions.

  • Languages have ecosystems. JavaScript is more than just the language; it’s also npm (the package manager), Node (the runtime), and thousands of conventions. “I know JavaScript” usually means knowing both the language and its ecosystem.

  • Most code you “write” is glue. A typical webapp is maybe 1% original code and 99% calling libraries that other people wrote. This is normal and good — reusing tested code is faster and safer.

  • A program is not a webapp / mobile app / etc. Those are programs, yes, but specific kinds. Plenty of programs have no UI (servers, batch jobs, automation scripts). Plenty of UI programs aren’t apps in the colloquial sense.

  • Running programs cost resources. Each open program uses RAM, CPU cycles, possibly disk. That’s why your computer slows down when 50 tabs are open — each one is a process using memory.

  • Programs can call other programs. A web browser is one program; the JavaScript engine inside it runs other programs (your webpage’s scripts). Composition is everywhere.

See also

Sources

Graph View

Backlinks