Pseudocode

Based on Wikipedia: Pseudocode

The Language That Doesn't Exist

Here's a curious thing about computer programming: sometimes the best way to write code is to write something that isn't code at all.

Pseudocode is a kind of fictional programming language. It looks like code. It reads like code. But no computer on Earth can run it. And that's precisely the point.

When a programmer sits down to solve a complex problem, they often don't start typing in Python or JavaScript or any real programming language. Instead, they reach for pseudocode—a flexible, informal notation that lets them sketch out their ideas without worrying about semicolons, brackets, or the dozens of other finicky details that real programming languages demand.

What Pseudocode Actually Looks Like

Imagine you wanted to describe how to find the largest number in a list. In pseudocode, you might write something like this:

Set the biggest number to the first item in the list. Then look at each remaining item. If it's larger than the biggest number you've seen so far, that becomes the new biggest number. When you've looked at everything, return the biggest number.

That's it. No special syntax. No compilation errors. Just plain description of what needs to happen, step by step.

But pseudocode can also look much more like actual programming. Some writers borrow heavily from languages like C or Python, using familiar keywords like "if," "while," and "for." Others mix mathematical notation with programming concepts. Still others write something closer to structured prose.

There's no wrong way to write pseudocode, because there's no compiler to tell you you're wrong.

Why Bother With Fake Code?

This might seem like an unnecessary step. Why not just write the real code directly?

The answer lies in how human brains work. When you're wrestling with a difficult algorithm—say, figuring out the optimal route for a delivery truck visiting twenty addresses—you need to focus on the logic of the solution. Real programming languages force you to simultaneously think about syntax, data types, memory management, and a dozen other implementation details.

Pseudocode strips all that away.

It lets you think about the problem at a higher level of abstraction. You can focus on the "what" before you worry about the "how." And because pseudocode is designed for human readers rather than machines, you can be as explicit or as hand-wavy as the situation demands.

There's something almost paradoxical here: the way to write better code is often to start by not writing code.

The Universal Translator

Pseudocode serves another crucial purpose: communication.

The programming world is fragmented into dozens of languages, each with its own syntax and conventions. A Python programmer might struggle to read Haskell. A JavaScript developer might find C++ bewildering. But pseudocode transcends these tribal boundaries.

This is why you'll find pseudocode everywhere in computer science textbooks and academic papers. When researchers describe a new algorithm, they rarely write it in any specific programming language. Instead, they use pseudocode that any trained programmer can understand and then translate into their language of choice.

The classic algorithms textbook by Thomas Cormen and his colleagues, "Introduction to Algorithms," is a perfect example. Its pseudocode has been translated into virtually every programming language in existence. The same algorithm description works whether you're coding in Rust, Ruby, or Racket.

From Sketch to Blueprint

Professional programmers often use pseudocode as part of a "top-down" development process.

It works like this: First, you sketch out the broad strokes of your solution in pseudocode, identifying the major steps and how they connect. Then you refine each step, breaking it down into smaller sub-steps. You keep refining until the pseudocode becomes detailed enough to translate directly into real code.

This approach has a name: stepwise refinement. It's been taught in computer science courses since the 1970s, and it remains valuable today. The idea is that you move gradually from the abstract to the concrete, making sure your logic is sound at each level before diving into implementation details.

There's something almost architectural about this process. You design the building before you start laying bricks.

The Mathematical Flavor

In certain fields, pseudocode takes on a distinctly mathematical character.

Numerical analysts and mathematicians often write pseudocode that mixes programming constructs with mathematical notation. They might use the capital sigma symbol—that tall, angular Greek letter that means "sum up all of these"—right alongside conventional loop structures. Or they might employ matrix notation to describe operations on arrays of numbers.

This hybrid notation is sometimes called "pidgin code," a playful reference to pidgin languages—those simplified tongues that emerge when speakers of different languages need to communicate. Pidgin ALGOL, pidgin Fortran, pidgin Pascal: these terms describe the informal mathematical pseudocodes that have evolved in various technical communities.

For mathematically trained readers, this notation is remarkably compact. A single line of mathematical pseudocode might expand into dozens of lines of actual program code. But for readers without that mathematical background, it can be impenetrable.

The Formalization Spectrum

Pseudocode exists on a spectrum from extremely informal to nearly formal.

At the informal end, you have prose descriptions that barely resemble programming at all. These are useful for communicating broad ideas to non-programmers or for the earliest stages of problem-solving.

In the middle, you have the classic textbook style: structured blocks, clear indentation, keywords borrowed from various programming languages, but with natural language filling in the gaps where precise syntax would be tedious.

At the formal end, pseudocode starts to blur into actual programming languages. Some standards organizations use highly structured pseudocode that's so precise it approaches executable code. The Moving Picture Experts Group, better known as MPEG—the organization that created the ubiquitous video and audio compression standards—defines their algorithms using a formal, C-like pseudocode. Understanding these standards requires understanding the pseudocode in exacting detail.

The Skeleton Program Connection

Pseudocode has a close cousin: the skeleton program.

A skeleton program is real code, but it's incomplete. It compiles without errors, but it doesn't actually do anything useful. The structure is there—the functions, the classes, the control flow—but the bodies of the functions are empty or contain only placeholder comments.

Programmers create skeleton programs as a way to plan out the architecture of their software before filling in the details. It's pseudocode's more formal sibling, one that the computer can at least parse and validate.

Some programming languages and development environments have taken this idea even further. Languages like HAGGIS—designed specifically for teaching—attempt to bridge the gap between pseudocode and executable code, making the transition from planning to implementation as smooth as possible.

Visual Alternatives

Pseudocode isn't the only way to plan algorithms without writing real code.

Flowcharts have been around since the 1920s, originally used to document industrial processes. They found their way into computing in the 1940s and became wildly popular in the following decades. With their diamond-shaped decision boxes, rectangular process boxes, and arrows showing the flow of control, flowcharts offer a visual representation of algorithmic logic.

The Unified Modeling Language, or UML, provides an entire suite of diagram types for describing software systems: class diagrams, sequence diagrams, state diagrams, and more. These graphical notations can express some ideas more clearly than text-based pseudocode.

DRAKON charts, developed in the Soviet space program during the 1980s, represent another visual approach, optimized for clarity in safety-critical applications.

But all these visual notations share a drawback: they're space-hungry. A flowchart that describes a moderately complex algorithm might sprawl across an entire wall. Pseudocode, by contrast, remains compact enough to include in a textbook or research paper without taking over the page.

Natural Language Programming

If pseudocode is informal code written for human understanding, what happens when you try to make real programming languages more human-friendly?

Several attempts have been made. HyperTalk, the language behind the pioneering HyperCard system in the late 1980s, let programmers write commands like "put the first word of the third line of field 'userName' into temp." AppleScript continues this tradition on modern Macs, with syntax that reads almost like English sentences.

Structured Query Language, or SQL, the standard language for database queries, has a famously English-like syntax: "SELECT name FROM employees WHERE salary > 50000." Even Python, one of the world's most popular programming languages, was designed with readability as a core principle, favoring English keywords over cryptic symbols.

But here's the thing: the resemblance to natural language is often more cosmetic than genuine. SQL might look like English, but it has strict grammatical rules that no natural language follows. AppleScript's verbose syntax doesn't make it any easier to learn; in some ways, it makes things harder, because the apparent naturalness creates false expectations.

Natural language is messy, ambiguous, and context-dependent. Programming requires precision. The gap between them may be unbridgeable.

The Untested Code Problem

Pseudocode's greatest strength is also its greatest weakness.

Because pseudocode doesn't run on any computer, it can never be tested. You can't feed it sample inputs and verify that it produces correct outputs. You can't use debugging tools to step through its execution. You can only read it, think about it, and hope you haven't made any logical errors.

And here's the uncomfortable truth that experienced programmers know: untested code is almost always wrong.

Not dramatically wrong, usually. Not obviously wrong. But somewhere in the logic, there's an edge case that wasn't considered, a boundary condition that triggers unexpected behavior, an assumption that doesn't hold in certain circumstances. These bugs only emerge when code actually runs.

Pseudocode, by definition, never runs. Its bugs can hide forever.

This is why pseudocode works best as a planning tool, not as a final product. The real verification comes when the pseudocode is translated into executable code and subjected to rigorous testing. The pseudocode sketch is just the first step in a longer process.

The Convenience of Invention

One researcher put it beautifully: no executable programming language "can beat the convenience of inventing new constructs as needed and letting the reader try to deduce their meaning from informal explanations."

This captures something essential about pseudocode's enduring appeal. When you're describing an algorithm, sometimes you need a concept that doesn't exist in any programming language. Maybe you want to say "do these operations in parallel" or "repeat until the result is good enough" or "somehow find the optimal solution."

In real code, each of these would require pages of implementation details. In pseudocode, you just write what you mean and trust your reader to fill in the gaps.

This freedom is intoxicating. It's also dangerous. The reader might fill in those gaps differently than you intended. The informal explanation might be less clear than you thought. The invented construct might hide a fundamental difficulty.

But used wisely, this flexibility makes pseudocode an unparalleled thinking tool. It lets you explore algorithmic ideas at the speed of thought, unencumbered by the constraints of any particular programming language.

A Bridge Between Minds

Perhaps the most important thing about pseudocode is what it represents: a bridge between human thinking and machine execution.

Computers are literal and unforgiving. They do exactly what they're told, nothing more and nothing less. If your instructions contain an error, the computer will faithfully execute that error. There's no room for interpretation, no benefit of the doubt.

Humans are the opposite. We communicate through implication and context. We understand intent even when the words are imprecise. We fill in gaps automatically, often without even realizing we're doing it.

Pseudocode occupies the space between these two modes of communication. It's more precise than casual conversation but more flexible than executable code. It's structured enough to be unambiguous about the algorithm's logic but informal enough to gloss over implementation details.

In a sense, pseudocode is where human programmers do their real thinking. The translation to executable code is just transcription—important, certainly, and requiring its own skills, but fundamentally a clerical task. The creative work happens in the pseudocode, where ideas take shape before they're cast into the rigid mold of actual programming languages.

Learning to Think Algorithmically

There's a reason pseudocode remains central to computer science education despite being technically "fake."

When students learn to program, they're actually learning two things at once: the syntax of a particular programming language and the underlying logic of algorithmic thinking. These are different skills, and they can interfere with each other. A student struggling with Python's indentation rules might lose track of the algorithm they're trying to implement.

Pseudocode separates these concerns. Students can focus on the logic—loops, conditionals, data structures, algorithmic patterns—without simultaneously fighting with syntax errors. Once the algorithmic thinking becomes fluent, the syntax of any particular language is relatively easy to learn.

This is why many computer science courses still ask students to write pseudocode solutions on paper exams. It's not an anachronism; it's a deliberate pedagogical choice. The exam is testing algorithmic thinking, not typing speed or memorization of syntax details.

The Informal Standard

Here's one final irony about pseudocode: despite being intentionally non-standardized, certain conventions have emerged.

Academic institutions often publish pseudocode guidelines for their exams and assignments. These specify which keywords to use, how to structure control flow, how to indicate the beginning and end of loops and conditionals. Within these contexts, pseudocode becomes almost as formal as a real programming language.

But step outside that context, and everything is negotiable again. The pseudocode in one textbook might look completely different from the pseudocode in another. A researcher's personal style might be instantly recognizable to their students and completely foreign to everyone else.

This lack of standardization is frustrating if you want pseudocode to serve as a universal medium of communication. But it's liberating if you understand pseudocode's true purpose: to make thinking visible.

The best pseudocode isn't the pseudocode that follows the most rules. It's the pseudocode that most clearly expresses the idea in the writer's mind. And that, by definition, can't be standardized.