The Philosophy of Programming Languages

Abstract

Every programming language is an argument about how people should think. Perl declared “there’s more than one way to do it”; Python answered that “there should be one — and preferably only one — obvious way.” Ruby optimized for programmer happiness; Go optimized for the reader over the writer; Rust for safety over convenience; APL for notation over familiarity. These slogans are not marketing afterthoughts; they are design constitutions that shaped every feature decision, and they gave language communities something close to religious identities, complete with proverbs, virtues, schisms, and holy wars. This article reads the major languages as what they secretly are: value systems compiled into syntax.

A Language Is an Argument

A programming language cannot avoid taking positions. Should the machine trust the programmer or protect them? Is code written once and read many times, or the reverse? Is expressiveness worth ambiguity? Language designers answer these questions in the grammar itself, and the most influential designers answered them explicitly, in slogans that their communities adopted as creeds.

The pattern is old. Kenneth Iverson’s 1979 Turing Award lecture, “Notation as a Tool of Thought,” made the strongest form of the claim: a well-designed notation doesn’t just record thinking, it changes what can be thought, the thesis behind APL, where an algorithm shrinks to a line of symbols. Lisp made the same argument differently: McCarthy’s code-as-data homoiconicity taught generations that a language should be able to reason about itself.

Freedom: Perl and TMTOWTDI

Larry Wall (trained as a linguist) designed Perl on the principle that programming languages should work like natural languages: redundant, contextual, forgiving, and expressive. The community motto, TMTOWTDI (“There’s More Than One Way To Do It,” pronounced “Tim Toady”), elevated pluralism to doctrine. Wall’s Programming Perl also canonized the three virtues of a programmer (laziness, impatience, and hubris) a joke with a real design consequence: Perl optimized for the writer’s convenience in the moment of writing.

The cost surfaced at scale: ten Perl programmers could solve the same problem ten syntactically alien ways, and maintenance became archaeology. “Write-only language” became the standing accusation, and the foil against which the next philosophy defined itself.

Discipline: Python and the Zen

Guido van Rossum’s Python took the opposite position, and its community wrote the counter-creed down. The Zen of Python (19 aphorisms composed by core developer Tim Peters and canonized as PEP 20) is displayed by the interpreter itself via the easter egg import this:

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Readability counts.
There should be one-- and preferably only one --obvious way to do it.

The fifth line is a direct, deliberate answer to TMTOWTDI. Python bet that code is read far more often than it is written, and that a language enforcing visual uniformity (down to mandatory indentation) lowers the cost of every future reader. The bet paid off in exactly the communities Perl lost: scientists, teachers, and beginners, for whom Python became the lingua franca.

Happiness: Ruby and MINASWAN

Yukihiro Matsumoto made the most radical move: he declared the machine irrelevant. Ruby’s stated design goal is programmer happiness (“Ruby is designed to make programmers happy”) governed by the principle of least surprise. The community layered on its own ethic, MINASWAN: “Matz is nice and so we are nice,” making kindness an official community value in a field notorious for flame wars. Ruby’s culture produced correspondingly unusual artifacts, none stranger or more beloved than why the lucky stiff’s cartoon-fox textbook.

Languages as Communities of Belief

Language slogans function like confessions of faith: they select who joins. Perl attracted system administrators who prized cleverness; Python attracted scientists who prized clarity; Ruby attracted web developers who prized joy; Go attracted engineers running huge codebases who prized uniformity. The “language wars” that rage on forums are rarely about semantics; they are identity conflicts between value systems. This is also why unsourced spiritual one-liners (“the language Buddha would have written in”) circulate as community folklore: members experience language choice as something closer to conversion than to tool selection.

Simplicity: Unix, Go, and the Proverbs

The ancestral simplicity creed is the Unix philosophy, distilled by Doug McIlroy: write programs that do one thing and do it well; write programs to work together; write programs to handle text streams, a universal interface (see The Unix Story).

Its modern heir is Go (co-designed by Unix veterans Rob Pike and Ken Thompson) which deliberately removed features (inheritance, exceptions, even generics for its first decade) to keep every codebase legible to every engineer. Pike codified the ethic in the Go Proverbs (2015), consciously modeled on koans:

“Clear is better than clever.”
“A little copying is better than a little dependency.”
“Don’t communicate by sharing memory, share memory by communicating.”

Where Python’s Zen governs how code looks, Go’s proverbs govern how teams scale: the language is openly optimized for the thousandth engineer reading the code, not the first one writing it.

Safety: Ada, Erlang, and Rust

A third family holds that the deepest value is what the language refuses to let you do. Ada encoded the Pentagon’s conviction that software failure is a safety failure. Joe Armstrong’s Erlang inverted conventional wisdom with “let it crash”: don’t write defensive code, write isolated processes, let the failing one die, and let a supervisor restart it; reliability comes from the architecture, not from programmer vigilance. Rust compiled the ethic into the type system itself (the borrow checker as institutionalized distrust of human memory management) under the banner of “fearless concurrency.” Each says the same thing: happiness, freedom, and brevity are worth sacrificing for the class of bug that can no longer be written.

Worse Is Better

The most unsettling document in language philosophy is Richard Gabriel’s “Worse Is Better” (from his 1989–91 essays on Lisp’s decline). Gabriel contrasted the MIT approach (correctness and interface elegance above all: Lisp, Scheme) with the New Jersey approach (implementation simplicity above all: C and Unix), and reached a heretical conclusion: the “worse” philosophy wins in the market, because simple implementations spread like viruses and improve later, while perfect designs arrive late and expensive. Half a century of history (C over Lisp, Unix over Multics, PHP over almost everything) keeps confirming a thesis its own author repeatedly tried to argue himself out of.

Dead End: The One True Language

Repeatedly, institutions concluded that this pluralism of values was waste, and tried to end it: IBM’s PL/I (1964) merged FORTRAN, COBOL, and ALGOL into one language for all purposes; the DoD’s Ada mandate ordered a single language for all defense software; countless “universal” successors were announced as the language to end languages.

Why It Failed

Every attempt failed the same way (Ada’s mandate most instructively: repealed in 1997). A language is a set of trade-offs, and different domains genuinely need different trade-offs, an embedded flight controller and a weekend web prototype should not share values. PL/I got the union of features and the intersection of enthusiasm. The ecosystem keeps choosing a portfolio of opinionated languages over one neutral one, because the opinions are the value: a language with no philosophy gives its users no leverage on their thinking. The full arc is traced in The Evolution of Language.