Claims

Edsger Dijkstra invented the formal theory of concurrent programming in a 1965 paper by introducing the concept of critical sections—pieces of code that at most one process can execute at a time—as a way to structure programs as collections of semi-independent tasks that must synchronize.

The origin of the time-sharing problem was that computers were expensive and fast, so they could be used simultaneously by multiple people whose programs would compete for shared resources like printers, requiring synchronization to prevent garbled output.

Lamport submitted a simple two-process algorithm to CACM in 1972, received a letter pointing out a bug, and realized that concurrent programs are hard to get right and require proofs of correctness—this rejection motivated him to develop the bakery algorithm.

The bakery algorithm was inspired by the deli ticket system, where customers take a numbered ticket and the lowest remaining number is served next, adapted to work without central control by having each process choose its own ticket number.

The bakery algorithm has the remarkable property that it does not require atomic (all-or-nothing) writes to shared memory: if one process reads a register while another is writing to it, the reader can get any arbitrary value and the algorithm still works correctly.

When Lamport shared the bakery algorithm proof with colleague Anatol Hol, the result was so remarkable that Hol didn't believe it, took it home to find the error, but never found anything wrong with it.

Dijkstra's original solution to the critical section problem had the defect that processes could be starved—an individual process might never get access to the critical section if other processes kept entering.

Lamport simplified Dijkstra's concurrent garbage collection algorithm by recognizing that the free list handling—which Dijkstra had made a special process—could be integrated into the regular data structure, requiring no special handling.

Lamport drew the notion of 'happens before' from special relativity: just as one event can influence another via light-speed-limited signals in physics, in distributed systems one event can influence another via messages actually sent in the system; this is the fundamental notion of causality in distributed computing.

In the Time, Clocks paper, Lamport described systems in terms of state machines—entities with a state that processes commands in order, where each command changes state and produces a value—and recognized this was the most important idea in the paper, but it was completely ignored by readers.

Understanding a concurrent program requires identifying invariants—boolean-valued properties of the state that, if true at each step, guarantee the output is correct—and reasoning about invariants rather than behavioral sequences reduces complexity from exponential to quadratic in the number of processes.

Much research in distributed systems theory attempts to use partial orderings and behavioral proofs, which is not the practical way to build systems; the method that reliably works is invariance proofs, though there are exceptions like the bakery algorithm where partial orderings are useful.

The Byzantine generals problem arose from Lamport's work on fault-tolerant state machines at SRI, where the challenge was how systems could reach agreement when some processes might fail arbitrarily (do 'anything')—including sending malicious or contradictory messages.

Lamport's initial Byzantine generals algorithm used digital signatures, which allowed it to tolerate one faulty process with three total processes, whereas algorithms without signatures required four processes—a critical difference for practical systems.

At the time (1975) Lamport developed his Byzantine algorithm, very few people knew about digital signatures; he learned about them from Whitfield Diffie, a friend, who described the unsolved problem of how to sign messages; Lamport sat down and sketched out the first digital signature algorithm on a napkin.

The SRI team developed a simpler abstraction for the Byzantine problem: rather than getting agreement on a sequence of commands, they created an algorithm for agreement on a single command and executed it repeatedly—this was a nicer abstraction than Lamport's sequence-based approach.

The insight that 'happens before' could be formalized mathematically blew people away because it provided a precise definition of causality in distributed systems, whereas before the notion of what it means for one event to occur before another in a distributed system was vague and obvious to most people.

The Byzantine generals problem is practically important because computers will fly aircraft, and during the 1970s oil crisis engineers realized that fuel-efficient aircraft must be aerodynamically unstable (smaller control surfaces), which pilots cannot control—only computers can make the necessary adjustments.

At DEC (Digital Equipment Corporation), which Lamport joined in 1985, they had built one of the first distributed operating systems with all computers on an Ethernet network sharing common storage, maintaining consistency via algorithms rather than explicit code.

An algorithm is more abstract than a program—it can be implemented in any programming language, whereas a program is concrete code in a specific language; thinking in terms of algorithms rather than code is crucial for concurrent systems.

When Lamport first presented the Paxos paper at a lecture dressed as an archaeologist (playing up the fictional 'ancient Greek parliament' framing), the audience may have enjoyed the presentation, but they did not understand the algorithm or its significance.

Raft is described as 'basically Paxos but with some of the tales left unfinished by the Paxos paper filled in,' presenting the same concepts but in a different order that appeals more to engineers.

Paxos has two phases: a leader-election phase (phase 1) that can be done once, then a sequence of decision phases (phase 2) that repeat as long as the same leader exists; when the leader fails, a new leader must be elected (phase 1 again) before phase 2 continues.

Raft advocates claimed the algorithm is simpler than Paxos and demonstrated this by teaching Paxos to one group of students and Raft to another; the Raft group reported better understanding, but a bug was later discovered in Raft that the students found more understandable than the correct version.

LaTeX was created by Lamport because he needed macros on top of TeX to do typesetting for a book he was writing, and decided to make the macros reusable for others; he was inspired by Scribe, which emphasized logical document structure over formatting details.

Computer people and programmers are 'really hung up on languages,' inventing languages and believing they improve thinking, but for understanding and reasoning about systems, mathematics beats any programming language.

Lamport wanted to develop a grand unified theory of concurrency (like the Turing machine for sequential computing) but never found it, which made him feel like a failure; many other researchers pursued the same goal via Petri nets and other approaches, all unsuccessfully.

State machines are more powerful than Turing machines because they can describe impossible or nondeterministic systems, whereas Turing machines only describe feasible computations—a feature, not a bug.

The problem Lamport encountered in building distributed databases was that the original solution would execute actions as if they occurred in a sequence, but that sequence could be different from the actual order in which they happened—a violation of the causal consistency that Lamport's 'happens before' relation was designed to capture.

Petri nets were a major candidate for the 'Turing machine of concurrency' and were very popular in the 1970s, but Lamport notes there is still a large community working on Petri nets today.

Lamport now believes that state machines (described not with commands and values but simply as a state and a next-state relation) are the 'Turing machine of concurrency'—the foundational abstraction for concurrent computing.

A state machine is defined by its state and a next-state relation: each command takes the system from one state to another, with correctness determined by invariants—boolean-valued properties of the state that ensure correct output regardless of what happened in the past.

Loops have existed in programming since Bohm and Jacopini's 1966 theorem, which established that three constructs—sequence, conditionals, and loops—are necessary and sufficient for Turing completeness; agents now employ loops to achieve this computational universality.

In conventional computing, knowledge is immortal because you can run the same program on different hardware—if one machine dies, you transfer the program to another. But this requires running transistors at very high power to maintain reliable digital representation, preventing use of analog properties that would be hardware-specific.

Alan Turing stated in 1950 that any system capable of learning must have an element of randomness; modern AI systems that rely solely on weights and optimization cannot learn without incorporating stochasticity.

NP-completeness hit AI researchers with a theoretical ceiling: many problems in search, reasoning, and computer vision are NP-complete or worse, meaning there is no known efficient algorithm to solve them—one must exhaustively search all candidate solutions, which is computationally infeasible for problems with many variables.

Computational irreducibility is the phenomenon wherein simple computational systems cannot be predicted to produce specific long-term outputs without actually running the computation for approximately that many steps—you cannot 'jump ahead' in prediction the way exact science has traditionally allowed.

Around 1981, Wolfram conducted a computational experiment of running all possible cellular automaton rules to see what behaviors they produced, which led to the discovery of Rule 30.

Rule 30, a cellular automaton with a simple three-bit rule, produces patterns that appear completely random over many iterations despite starting from a single black cell, demonstrating that simple programs can generate complex and apparently random behavior.

Mathematical equations were not effective for modeling complexity, leading Wolfram to consider simple programs and cellular automata as more general foundations for models, based on the insight that specifying rules for something determines what it will do.

Cellular automata are simple programs where each cell's next state depends on its current state and neighboring cells according to fixed rules, and Wolfram discovered in 1981 by running all possible rules that many produce simple patterns, but Rule 30 produces elaborate, seemingly random behavior from just one initial black cell.

Problems in AI such as traveling salesman, blocks world, and most reasoning tasks belong to the NP-complete complexity class, meaning no known efficient algorithm exists—you must examine all exponentially many candidate solutions, creating a combinatorial explosion barrier that symbolic search approaches cannot overcome.

There is a branch of computer science studying self-organization principles including reaction-diffusion patterns, cellular automata (which compute using only neighbor state observation), and neural cellular automata that may explain both organism development and brain self-organization.

Claim extraction enables evaluation of answer relevance by allowing assessment of individual claims within an answer, where some claims may be relevant to a question while others are not, enabling aggregation into a composite relevance measure.

When processing the sentence 'Argentina's currency value has plunged,' Claimify correctly specifies that inflation is the cause of the currency depreciation, whereas the baseline only stated that the currency value has plunged without identifying the causal mechanism.

One of the most popular use cases for language models is generating long-form content, and claim extraction can help with evaluation of such content.

Extraction is the process of breaking down a text into claims.

Claim extraction matters because it unlocks the ability to evaluate long-form content generated by language models.

Claimify is a system that takes text of any length and decomposes it into high-quality claims.

Claimify's ability to determine whether ambiguity in a sentence can be resolved using context is a particularly unique and powerful aspect of the disambiguation stage.