A Lisp Programmer's Unofficial Motto

Level 1: Saying Exactly What You Mean

Say you tell a friend, "grab the red ball and the bat from the garage." Did you mean a red ball and any bat, or a red ball and a red bat? People argue about sentences like that all the time — so the safest move is to spell it out: "grab (the red ball) and (the bat from the garage)." The first person in the meme is angrily insisting everyone should always spell it out so computers never guess wrong. The funny part is the reply: there's a famous programming language, Lisp, where spelling everything out with parentheses isn't advice — it's the law, and it has been since 1958. The angry commenter thought they were sharing a clever personal trick, and the reply gently reveals they've just reinvented one of the oldest ideas in computing.

Level 2: What the Table Actually Does

Operator precedence is the rulebook a language uses to decide grouping when you don't write parentheses. Just like math class taught 2 + 3 × 4 = 14 (multiply first), programming languages keep a ranked table of operators:

int result = 2 + 3 * 4;        // 14, not 20 — * outranks +
int trap   = 1 << 2 + 1;       // 8, not 5! '+' outranks '<<'
int safe   = (1 << 2) + 1;     // 5 — parentheses end the debate

The danger is that real tables cover dozens of operators — bitwise, logical, comparison, shifts — and very few humans remember the full ranking across the several languages they use in a week. Code that depends on obscure precedence rows still works; it just becomes a trap for the next reader. Wrapping sub-expressions in parentheses forces the grouping you intend and documents it for free.

Lisp is a family of languages (one of the oldest, from 1958) that sidesteps the issue with a different shape entirely: every operation is a parenthesized list with the operator first — (+ 2 (* 3 4)). These nested lists are called s-expressions. New developers usually meet Lisp as "the language that's all parentheses" — the punchline of this thread — without realizing those parentheses are doing exactly what the first commenter demanded: making order of operations impossible to get wrong.

Level 3: Debt-Free Since 1958

The screenshot's two-beat structure is perfect Reddit economics: bautin delivers the battle-worn pragmatism —

"The proper order of operations is as follows: Put fucking parentheses around everything to force the order and stop being a bitch."

— at 1.9k upvotes, and Nebuli2 lands the scalpel reply, "Ah, a Lisp programmer," for 584. The joke works because the first comment thinks it's giving advice about a language, and the reply points out it has accidentally specified a language.

Experienced developers upvote the first comment because precedence bugs are a genuinely nasty class: they parse cleanly, type-check, and run — they just compute the wrong thing, silently. The classics scar everyone eventually: if (x & MASK == FLAG) in C (equality binds tighter than bitwise AND, so you've masked with a boolean), mixing &&/|| without grouping, Python's not a == b reading nothing like it evaluates in your head at 2 AM. Code review culture has converged on the same rule the comment states crudely: explicit beats implicit, and redundant parentheses cost nothing while a misremembered precedence table costs an incident review. Nobody has ever been paged because an expression had too many parens.

The reply's smugness is earned, though. Lisp (and its descendants Scheme, Clojure, Racket) made this trade at the language level: all structure is explicit, always, by prefix notation — (+ 1 (* 2 3)). The price is the aesthetic complaint that launched a thousand jokes ("Lost In Stupid Parentheses"), and the dividend is that no Lisp programmer in 67 years has ever had a precedence bug, because the concept doesn't exist there. Precedence tables are syntactic debt a language assumes so users can type fewer characters; Lisp declined the loan. The thread is funny because both commenters are right, and the second one merely reveals that the first's hard-won pragmatism was a functional programmer's worldview wearing a trench coat.

Level 4: The Grammar That Refused to Exist

Operator precedence is, formally, a property of a language's grammar — and it's an expensive one. To parse a + b * c "correctly," a compiler needs precedence and associativity rules baked into its parser: stratified grammar productions in recursive descent, precedence-climbing (Pratt parsing), or shift/reduce conflict resolution in LR parser generators like yacc/bison. Every infix language carries a hidden table — C's has fifteen levels, and at least two of them (& binding looser than ==, the ternary's right-associativity) are acknowledged by its own designers as mistakes frozen forever by backward compatibility.

Lisp's answer in 1958 was to skip the parsing problem entirely. John McCarthy's s-expressions were originally meant as an internal representation — the human-friendly M-expression syntax was planned but never shipped, because programmers discovered they didn't mind writing the parse tree directly. That's the profound bit: (+ a (* b c)) isn't "code with lots of parentheses," it's the AST written down literally. There is no precedence table because there is no ambiguity to resolve; the grammar is essentially expr := atom | (expr*), parseable by a read function a student writes in an afternoon.

This collapse of syntax into structure is what enables homoiconicity: Lisp code is a Lisp data structure (lists), so programs can construct, inspect, and rewrite programs — the foundation of its macro system, which is still the high-water mark for syntactic abstraction. Infix languages that want macros (Rust, for instance) must haul around token trees and hygiene machinery precisely because their surface syntax diverged from their AST. The top comment's profane advice — force the order, trust no table — is therefore not just a style tip; it's a one-sentence rediscovery of why McCarthy's "temporary" notation outlived every prettier alternative.