Lisp’s parentheses stuck after Steve Russell made a paper’s notation executable

Lisp’s familiar parentheses survived a plan to replace them. The replacement kept waiting while programmers used what actually ran.

John McCarthy’s account places the beginning of implementation in fall 1958. A compiler was the original idea. Getting conventions for subroutines, stacks, and storage right was a substantial job, so the team began with hand-compiled functions and routines that could read and print lists.

The intended programming notation looked more conventional. McCarthy describes M-expressions designed to resemble FORTRAN, including assignment statements and jumps. Brackets around function arguments kept parentheses available for list constants. The eventual language could have looked less like somebody spilled punctuation into the keyboard drawer.

Even that plan had a physical snag. The handwritten notation included characters unavailable on the IBM 026 keypunch. A notation on paper can be neat; a machine-readable language has to survive the device used to enter it.

McCarthy then needed a compact way to describe a universal Lisp function in a paper. That function, eval, takes an expression and an environment of variable assignments and computes a value. Representing Lisp functions as Lisp data provided a way to write the explanation down.

Russell recognized that the function could become an interpreter and hand-coded it. McCarthy recalls that the unanticipated working interpreter tended to freeze the language’s form. People could now run programs in the internal notation while the more polished external notation still required further design.

This is the creator’s retrospective account, including his admitted uncertainties. He explicitly says he cannot remember exactly when the external parenthesized data notation was chosen. That makes a tidy claim that one afternoon invented every parenthesis especially tempting, and especially wrong. The interpreter accelerated adoption of decisions already gathering around the implementation.

McCarthy was candid about consequences he disliked. Some decisions made for the paper became awkward in practice, including deeply nested conditionals and the interpretation of zero. A working implementation can preserve rough edges with the same enthusiasm it preserves useful ideas. Compatibility has excellent long-term memory.

The planned M-expression language never reached a precise, final definition, and nobody formally announced its funeral. McCarthy writes that it receded while a generation appeared that preferred the internal notation. That’s a very different software history from a committee selecting the final syntax and everyone following the diagram.

The story makes a prototype rollout worth examining carefully. Once people write real work against an interface, a promised replacement has to compete with that work. Better notation on a whiteboard has no migration tools, no running applications, and a suspiciously flexible delivery date. The next temporary interface still gets its own chance to become permanent.