Visual summary of operating lessons from Leslie Lamport.

Lessons from Leslie Lamport

Leslie Lamport is the creator of LaTeX and the Paxos algorithm, the logic that keeps distributed systems synchronized. This profile examines his argument that mathematical rigor, not more code, is the only way to design complex software correctly.

Part 1: The Relationship Between Writing and Thinking

  1. On the nature of thought: "Thinking doesn't guarantee that we won't make mistakes. But not thinking guarantees that we will." — Source: [Microsoft Research]
  2. On the connection between writing and logic: "Writing is nature’s way of letting you know how sloppy your thinking is." — Source: [The Computer Science Podcast]
  3. On the limits of memory: "If you think you know something but don't write it down, you only think you know it." — Source: [Quanta Magazine]
  4. On mathematical clarity: "Math is nature’s way of showing you how sloppy your writing is." — Source: [Leslie Lamport's Homepage]
  5. On the purpose of a specification: "A specification is a description of what a system does. You can’t build a system unless you know what it’s supposed to do." — Source: [Communications of the ACM]
  6. On language as a distraction: "Thinking is not the ability to manipulate language; it's the ability to manipulate concepts." — Source: [Heidelberg Laureate Forum]
  7. On the difficulty of precision: "The most difficult part of writing a program is deciding what it should do." — Source: [Stanford Lecture Series]
  8. On prose vs. math: "English is a great language for writing novels, but it's a terrible language for describing algorithms." — Source: [Lex Fridman Podcast]
  9. On the value of abstractions: "The purpose of a model is to abstract away the details that don't matter so you can focus on the ones that do." — Source: [TLA+ Video Course]

Part 2: The Logic of Distributed Systems

  1. On the definition of distributed failure: "A distributed system is one in which the failure of a computer you didn't even know existed can render your own computer unusable." — Source: [Email to a colleague, June 1987]
  2. On reaching consensus: "Agreement is easy if nobody fails. The problem is reaching agreement when things go wrong." — Source: [The Paxos Paper]
  3. On the Byzantine Generals problem: "We can achieve reliability in the presence of arbitrary failures only if more than two-thirds of the components are working correctly." — Source: [ACM Transactions on Programming Languages and Systems]
  4. On the origin of Paxos: "I thought the algorithm was so simple that it would be obvious to everyone, so I tried to make it more interesting by dressing it up in a story about a Greek parliament." — Source: [My Papers: The Part-Time Parliament]
  5. On the necessity of state machines: "Every computer program can be viewed as a state machine. The state is the value of all the variables." — Source: [ACM Turing Award Interview]
  6. On replicated logs: "A distributed system is just a way to make multiple machines act like a single state machine." — Source: [Microsoft Research Blog]
  7. On the Bakery Algorithm: "It's the first algorithm that solved the mutual exclusion problem without assuming that read and write operations are atomic." — Source: [Communications of the ACM]
  8. On fault tolerance: "A system that can't handle the failure of a single component isn't a distributed system; it's a chain where the weakest link breaks everything." — Source: [Software Engineering Radio]
  9. On complexity and errors: "The more complex the system, the more likely it is that your 'obvious' reasoning is wrong." — Source: [Building High-Level Specifications]
  10. On the role of non-determinism: "In a distributed system, you don't know the order in which events happen unless you enforce it." — Source: [PODC Keynote]

Part 3: Formal Specification and TLA+

  1. On the utility of TLA+: "TLA+ is based on the idea that the best way to describe a system is with simple mathematics." — Source: [TLA+ Project Page]
  2. On finding bugs: "Engineers at Amazon used TLA+ to find bugs in their core systems that had existed for years and that no amount of testing had uncovered." — Source: [How Amazon Web Services Uses TLA+]
  3. On the definition of 'Liveness': "Liveness means that something good eventually happens. Safety means that something bad never happens." — Source: [Formal Methods in System Design]
  4. On mathematical tools: "You don't need fancy category theory to specify a system; you just need sets and functions." — Source: [Specifying Systems (Book)]
  5. On the resistance to math: "Programmers are afraid of math because they think it's hard, but they spend all day dealing with much more complex things in their code." — Source: [Thinking Above the Code Talk]
  6. On invariants: "An invariant is a property that stays true no matter what happens. If you can't state your invariant, you don't understand your algorithm." — Source: [Teaching Concurrency Paper]
  7. On the Temporal Logic of Actions: "TLA provides a uniform way to describe both the system and its properties in the same mathematical language." — Source: [ACM Transactions on Programming Languages]
  8. On model checking: "The model checker doesn't find all the bugs, but it finds the ones that humans are too tired or too distracted to see." — Source: [TLA+ Video Lectures]
  9. On blue prints: "Coding without a spec is like building a skyscraper by just starting to lay bricks and hoping for the best." — Source: [Microsoft Faculty Summit]
  10. On the cost of formality: "Writing a specification takes time, but it takes less time than debugging a system that was built on a flawed design." — Source: [Interview with Dr. Dobb's]

Part 4: Programming vs. Coding

  1. On the distinction between roles: "Coding is to programming what typing is to writing." — Source: [The Peterman Pod]
  2. On the obsession with languages: "The language you use to write your code is much less important than the ideas you use to design your system." — Source: [Heidelberg Laureate Forum Interview]
  3. On the 'hacker' culture: "The 'just start coding' approach is why we have so much buggy software in the world today." — Source: [Quanta Magazine Profile]
  4. On clear design: "A program is a mathematical object. If you don't treat it like one, you're just guessing." — Source: [Stanford CS208]
  5. On simplicity: "Complexity is not a sign of intelligence; it's a sign of a failure to find a simpler abstraction." — Source: [Turing Award Lecture: The Computer Science of Concurrency]
  6. On architectural decisions: "The most important decisions are made before you ever touch a keyboard." — Source: [Microsoft Research: Thinking for Programmers]
  7. On trial and error: "Trial and error is a fine way to learn to ride a bike, but it's a terrible way to build a nuclear power plant controller." — Source: [ACM Interview]
  8. On the definition of 'Algorithm': "An algorithm is a way of solving a problem that doesn't depend on the specific programming language you use." — Source: [Introduction to TLA+]
  9. On the role of comments: "If the code is clear, the comments should explain 'why,' not 'what.' But if you have a spec, you don't need as many comments." — Source: [Lex Fridman Podcast #265]

Part 5: Time, Order, and Causality

  1. On logical clocks: "Time is not a physical absolute in a distributed system; it is a partial ordering of events." — Source: [Time, Clocks, and the Ordering of Events paper]
  2. On the 'Happened-Before' relation: "We can define 'a happened before b' if there is a path of messages or local events connecting them." — Source: [Communications of the ACM, 1978]
  3. On synchronization: "Synchronization is the process of ensuring that events happen in the correct order, even when there is no global clock." — Source: [Microsoft Research Publication]
  4. On physical time: "Physical clocks are always slightly out of sync. You cannot rely on them for correctness in a distributed algorithm." — Source: [Turing Award Lecture]
  5. On causality: "If event A can affect event B, then A must be considered to have happened before B." — Source: [Lamport's Website: My Papers]
  6. On total ordering: "We can turn a partial ordering into a total ordering by using process IDs to break ties, which is essential for distributed databases." — Source: [Time, Clocks, and the Ordering of Events]
  7. On the limits of observation: "You can't tell which of two independent events happened first. In a distributed system, there is no 'now'." — Source: [ACM Queue Interview]
  8. On state consistency: "Consistency in a distributed system means that every process sees the same sequence of events, regardless of their physical location." — Source: [Paxos Made Simple]
  9. On message delays: "The fundamental challenge of distributed computing is that messages take time to travel and can be lost or reordered." — Source: [Byzantine Generals Paper]

Part 6: LaTeX and Documentation

  1. On the creation of LaTeX: "I wanted a way to write my own books and papers without having to worry about the low-level formatting of TeX." — Source: [The TeX User Group Interview]
  2. On the philosophy of LaTeX: "The author should focus on the content and the structure, not on the font size or the margins." — Source: [LaTeX: A Document Preparation System (Book)]
  3. On macros: "LaTeX is just a set of macros for TeX. It succeeded because it provided a standard way for people to share styles." — Source: [ACM Oral History]
  4. On Guttman's influence: "I didn't expect LaTeX to be used by anyone but me and a few friends at SRI." — Source: [Interview with Leslie Lamport, 2013]
  5. On mathematical typesetting: "Before TeX and LaTeX, mathematical formulas in books were often ugly and difficult to read." — Source: [The LaTeX Project]
  6. On open source: "I made LaTeX freely available because I wanted people to use it, not because I wanted to get rich." — Source: [Oral History: Computer History Museum]
  7. On standardizing science: "LaTeX became the standard because it allowed scientists to communicate their ideas with perfect precision on the page." — Source: [Microsoft Research Alumni Profile]
  8. On simplicity for the user: "A user shouldn't have to be a programmer to write a professional-looking paper." — Source: [LaTeX 2e Introduction]
  9. On the name: "I called it LaTeX because it was 'Lamport's TeX'. Simple as that." — Source: [TeX Users Group (TUG) Profile]
  10. On the durability of tools: "The fact that people are still using LaTeX decades later shows that we got the core abstractions right." — Source: [Interview at Heidelberg Laureate Forum]

Part 7: Mathematical Rigor and Algorithms

  1. On the definition of 'Obvious': "To a mathematician, 'obvious' means 'I don't want to bother writing down the proof.'" — Source: [TLA+ Video Course]
  2. On the beauty of a proof: "A proof is not just a way to show that something is true; it's a way to understand why it's true." — Source: [How to Write a 21st Century Proof]
  3. On rigorous thinking: "Mathematics is the only tool we have for dealing with the complexity of concurrent systems." — Source: [Teaching Concurrency]
  4. On the Bakery Algorithm's elegance: "The beauty of the Bakery algorithm is that it uses nothing but simple reads and writes." — Source: [ACM Digital Library]
  5. On 'Hand-wavy' reasoning: "If you can't write a formal proof, you're just hand-waving, and hand-waving leads to bugs." — Source: [Thinking Above the Code]
  6. On the role of logic: "Logic is the grammar of thought. If you don't know the logic, you can't express the thought." — Source: [Specifying Systems]
  7. On set theory: "Everything in computer science can be explained using set theory. You don't need anything more complex." — Source: [Introduction to TLA+]
  8. On persistence: "I'm not smarter than other people; I'm just more persistent in trying to understand things at a fundamental level." — Source: [Turing Award Profile]
  9. On the limits of intuition: "Intuition is what tells you that a concurrent algorithm is correct right before you find the counter-example." — Source: [Concurrent Programming talk]

Part 8: Education and the Future of Computing

  1. On teaching students: "We should teach students how to think before we teach them how to code." — Source: [Quanta Magazine Interview]
  2. On the role of AI: "AI can write code, but it can't think for you. You still need to specify what you want the AI to do." — Source: [The Peterman Pod retrospective]
  3. On the shift to biology: "The future of computing might look more like biology than like logic, with systems that grow and adapt rather than being built." — Source: [The Future of Computing: Logic or Biology]
  4. On the responsibility of engineers: "If your bridge falls down, you're responsible. If your software crashes, people just expect it. We need to change that." — Source: [Microsoft Research Blog]
  5. On learning from history: "We keep making the same mistakes in software because we don't study the foundational principles that were discovered 40 years ago." — Source: [ACM Queue]
  6. On the value of math in school: "Students don't hate math; they hate the way math is taught as a series of boring rules instead of a tool for discovery." — Source: [Lex Fridman Podcast #265]
  7. On the next generation: "I want to leave behind tools that make it easier for the next generation to build systems that actually work." — Source: [Turing Award Lecture]
  8. On the definition of 'Science': "Computer science is a science when it seeks to understand the world through computation." — Source: [Heidelberg Laureate Forum]
  9. On the ultimate goal: "The goal of everything I've done is to make the world a little more logical." — Source: [ACM Oral History Transcript]