M: Make a detailed argument for how the language used in legal documents is essentially a programming language. Direct particular attention towards comparing 18th century and early 19th century law to early linear programming before the advent of the OOP paradigm. Assume an intelligent reader who is not necessarily well-versed in the lexicon of the legal world. Focus on English and later American law.

G: TL;DR (core thesis up front)
Legal documents—especially English and early American law—function like a programming language: they define a symbolic system, specify permissible operations, encode conditionals and exceptions, and rely on interpretation layers analogous to runtimes and compilers. 18th–early-19th-century law closely resembles early linear / procedural programming: sequential, text-heavy, globally scoped, and dependent on human interpreters to resolve ambiguity—well before anything like modular abstraction or object-oriented encapsulation emerged.

日本語(にほんご)要約(ようやく):
法律(ほうりつ)は 言語(げんご)として 書(か)かれた プログラム に 近(ちか)い。 — Law is written as a language, and it behaves like a program.


1. Law as a Symbolic Execution System

At its most basic level, a legal document does not describe reality—it defines a machine for making decisions.

A statute or constitution:

This maps cleanly onto what programmers would recognize as:

The legal system as a whole then executes these texts through courts, just as a program is executed by a machine.

The crucial point: law is not prose. It is instructional text intended to be run.


2. Why English Law Looks Like Early Procedural Code

2.1 Sequential, Not Abstract

18th-century English law—especially common law—developed incrementally through cases. Each ruling added another step to the chain.

This resembles early procedural programming:

There is no clean separation of concerns. Instead:

This is exactly how early software systems behaved before modular design.


3. Common Law as “Patch-Based Development”

English common law evolved through precedent:

This mirrors patch-based development:

The doctrine of stare decisis functions like a version-locking system:

In programming terms, courts are forced to maintain ABI compatibility with centuries-old code.


4. The Interpreter Problem: Judges as Runtimes

Early law did not execute itself. It required human interpreters.

Judges:

This makes them closer to runtime environments than compilers:

Different courts = different runtimes, each with quirks and edge behaviors.

This explains why the same statute can behave differently across jurisdictions—identical source code, different execution environments.


5. 18th-Century Law and Global Scope

Early law is overwhelmingly globally scoped.

Key characteristics:

There is little encapsulation:

This is the legal equivalent of early C programs with:

The result is fragility: change one rule, and unforeseen consequences propagate.


6. The American Constitution as a Refactor Attempt

The entity["book","United States Constitution","1787 federal charter"] represents a deliberate attempt to clean up this system.

Notably:

However, it is still procedural, not object-oriented:

The Constitution is closer to a carefully commented core library than a modern framework.


7. Why OOP Took So Long to Emerge in Law

Object-oriented programming arose to solve:

Law faced the same pressures—but lacked:

Attempts at abstraction (rights, offices, agencies) emerged slowly and unevenly.

Even today:

Administrative law is arguably the closest thing to OOP:

But it remains hybrid and inconsistent.


8. Why This Analogy Matters

Understanding law as programming clarifies several otherwise-mystifying facts:

  1. Why legal text is so precise yet ambiguous
    It’s source code written in natural language.

  2. Why interpretation disputes never end
    The language lacks a strict compiler.

  3. Why small changes cause massive downstream effects
    Global scope + side effects.

  4. Why reform is so hard
    You are refactoring a live system with billions of users and no rollback.


9. A Useful Mental Model

If you want a compact metaphor:

Seen this way, 18th–early-19th-century law is not primitive—it is pre-abstract, operating at the limits of what linear, human-interpreted systems can sustain.

日本語(にほんご)補足(ほそく):
古(ふる)い 法律(ほうりつ)は 手続(てつづ)き型(がた)プログラム に 似(に)ている。 — Old law resembles procedural programming.


10. Closing Note

This framing does not diminish law; it explains it.
Legal language looks strange because it is doing an unnatural job: acting as executable logic while remaining readable to humans.

Once you see that, the similarities stop being metaphorical and start being structural.