Visual summary of operating lessons from Barbara Liskov.

Lessons from Barbara Liskov

Barbara Liskov’s work helped establish data abstraction, behavioral subtyping, and practical approaches to reliable distributed systems. This profile covers CLU and Argus, the substitution principle that bears her name, and research developed with students and collaborators. — ACM Oral History — Barbara Liskov.

Part 1: The Architecture of Abstraction

  1. On the Discovery of ADTs: Liskov describes recognizing that a module with hidden data and exported operations could represent an abstract data type, such as a set or sequence. — Peterman Pod — Data Abstraction and Distributed Systems.
  2. On the Definition of a Type: A data abstraction presents objects through a set of operations. Those operations are the interface through which clients use the objects. — The Power of Abstraction — QCon Slides.
  3. On Irrelevant Details: Abstraction exposes details relevant to using a component while suppressing details of its implementation. Clients should rely on what the abstraction does, not how it is implemented. — Programming with Abstract Data Types.
  4. On the Venus Operating System: While building Venus, Liskov organized state into partitions accessible only through their owning modules. She later developed the data-abstraction idea after joining MIT, working with Steve Zilles in 1973. — ACM Oral History — Barbara Liskov.
  5. On Object Logic: An integer’s users need its arithmetic operations, not its bit-level storage format. An abstract data type similarly lets clients use its operations without supplying its representation. — Programming with Abstract Data Types.
  6. On Thinking Before Coding: Plan what an experiment should accomplish before running it. Liskov recalls that slow batch turnaround forced careful thought; rapid iteration can waste time when students have not decided what they are trying to learn. — Infinite MIT — Barbara Liskov.
  7. On Design Boundaries: Abstraction involves both finding a useful system interface and designing an effective implementation behind it. — The Power of Abstraction — MIT CSAIL.
  8. On Procedural Limitations: Procedures alone did not match the stateful modules needed for systems such as files and databases. Data abstraction provided a way to think about those modules. — Peterman Pod — Data Abstraction and Distributed Systems.

Part 2: The Substitution Principle

  1. On the Informal Definition: Subtyping must preserve the behavior expected by programs written for the supertype. Matching an inheritance declaration is not enough. — A Behavioral Notion of Subtyping.
  2. On the Formal Definition: Properties established for supertype objects must remain valid for subtype objects. Liskov and Wing formalize this requirement through specifications. — A Behavioral Notion of Subtyping.
  3. On Naming the Principle: She says she first learned that the substitution principle carried her name when someone emailed to ask whether they had interpreted it correctly. — Peterman Pod — Data Abstraction and Distributed Systems.
  4. On Subtyping vs. Subclassing: Reusing a superclass’s implementation is different from establishing a valid subtype relationship. Liskov’s criterion concerns how an object behaves where the supertype is expected. — Peterman Pod — Data Abstraction and Distributed Systems.
  5. On the History Constraint: Subtypes must preserve the supertype’s history properties. Mutation is permissible when it is invisible through the supertype’s interface—not categorically forbidden beneath an immutable supertype. — A Behavioral Notion of Subtyping.
  6. On Behavioral Consistency: Behavioral subtyping preserves method behavior, invariants, and history properties, not just compatible signatures. — A Behavioral Notion of Subtyping.
  7. On Preconditions: A subtype method must accept every state allowed by the corresponding supertype method’s precondition. — A Behavioral Notion of Subtyping.
  8. On Postconditions: A subtype method may strengthen its postcondition, but must still deliver the guarantees promised by the supertype. — A Behavioral Notion of Subtyping.
  9. On Client Expectations: Clients reasoning from a supertype’s specification must retain those guarantees when an object is replaced by a valid subtype. — A Behavioral Notion of Subtyping.

Part 3: Designing for Reliability in CLU

  1. On Modular Organization: Liskov compared software interfaces to the wires connecting electrical components. Explicit connections help prevent an uncontrolled tangle of dependencies. — ACM Oral History — Barbara Liskov.
  2. On the "Cluster": CLU’s clusters gave data abstractions a language-level implementation. The compiler enforced the abstraction barrier so outside code interacted through exported operations. — ACM Oral History — Barbara Liskov.
  3. On Iterators: CLU’s iterators supported traversing collections through a for loop without exposing their representation. Liskov credits Russ Atkinson with devising the iterator mechanism after a visit to Carnegie Mellon. — ACM Oral History — Barbara Liskov.
  4. On Exception Handling: CLU’s exception mechanism supports explicit handling and signaling. It does not require a handler for every exception: an uncaught exception is automatically converted to the language-defined failure exception. — Exception Handling in CLU.
  5. On "Where Clauses": CLU’s where clauses listed operations and signatures required of a type parameter. The compiler checked that those operations existed; their semantic properties still required specifications and reasoning. — ACM Oral History — Barbara Liskov.
  6. On Inheritance Omission: CLU used independent clusters rather than subclass inheritance. Liskov contrasts that design with languages organized around changing a superclass’s implementation. — Peterman Pod — Data Abstraction and Distributed Systems.
  7. On Dijkstra's Influence: Liskov took Dijkstra’s critique of goto statements as a broader argument for control structures that make reasoning about correctness easier. — ACM Oral History — Barbara Liskov.
  8. On Static Type Checking: She favored strong static checking because a compiler could catch mistakes early and save time during development, in contrast with her experience programming in Lisp. — ACM Oral History — Barbara Liskov.
  9. On Language as a Tool: Language features make an abstraction available for programmers to think with and test in real programs. Building the CLU compiler also tested whether its mechanisms were useful enough. — ACM Oral History — Barbara Liskov.

Part 4: The Distributed Challenge

  1. On Modularity in Distribution: Liskov applied modular language design to distributed programs: Argus organized computation around guardians that communicated across machines. — Peterman Pod — Data Abstraction and Distributed Systems.
  2. On Guardians: In Argus, a guardian was a module located at one computer, communicating with other guardians through remote procedure calls. This account does not establish that guardians preceded the actor model. — Peterman Pod — Data Abstraction and Distributed Systems.
  3. On Atomic Actions: Argus borrowed transactions from database systems so a computation involving multiple guardians could complete as a whole or have no effect. — Peterman Pod — Data Abstraction and Distributed Systems.
  4. On Nested Transactions: Argus ran remote calls as subactions that could be aborted, allowing another approach without committing their effects. Liskov also cautions that this model was complicated and expensive. — ACM Oral History — Barbara Liskov.
  5. On Stable State: Argus distinguished stable objects that could be recovered after a crash from volatile state that was lost. Committed changes to stable objects were recorded in stable storage; volatile state had to be reconstructed during recovery. — Distributed Programming in Argus.
  6. On Viewstamped Replication: Viewstamped replication, developed with Brian Oki, addressed reliability and availability by coordinating replicated state despite benign failures. Replication needed a protocol—not merely extra copies. — ACM Oral History — Barbara Liskov.
  7. On PBFT: Practical Byzantine Fault Tolerance, developed with Miguel Castro, addresses arbitrary replica behavior, including malicious responses that appear legitimate. It is a different failure model from crash-only replication. — ACM Oral History — Barbara Liskov.
  8. On Malicious Failures: As the Internet expanded beyond a community of trusted researchers, Liskov’s group began treating malicious replicas as a practical threat. This motivated work on Byzantine fault tolerance, not a claim that every system requires it. — ACM Oral History — Barbara Liskov.
  9. On RPC Efficiency: A missing response to a remote call does not reveal whether the other machine failed or the reply is merely delayed. Distributed programs need a way to handle that uncertainty without waiting forever. — ACM Oral History — Barbara Liskov.

Part 5: Software Engineering as a Science

  1. On Performance Obssessions: Performance concerns should be tied to actual use. Liskov emphasizes that efficient mechanisms encourage adoption and that overhead in a platform can be amplified by applications built on top of it. — ACM Oral History — Barbara Liskov.
  2. On the Software Crisis: Liskov recalls large software projects being discarded because they did not work. Breaking systems into modules with clear interfaces was central to addressing that problem. — Peterman Pod — Data Abstraction and Distributed Systems.
  3. On Reasoning Independently: A well-specified interface and hidden implementation allow programmers to reason about a module’s correctness without inspecting the rest of the system. — Peterman Pod — Data Abstraction and Distributed Systems.
  4. On Programming as Cooking: She compares computational thinking to cooking: break a task into steps and organize the process so that carrying out those steps accomplishes the job. — Infinite MIT — Barbara Liskov.
  5. On Complexity as the Enemy: Modularity helps manage complexity through local reasoning, replaceable implementations, and independent development. Liskov also emphasizes algorithms, protocols, methodology, and language support—not encapsulation alone. — The Power of Abstraction — QCon Slides.
  6. On Encapsulation as Security: Encapsulation supports modular reasoning by preventing outside code from interfering with a module’s internal state. It is not, by itself, a complete security guarantee. — Peterman Pod — Data Abstraction and Distributed Systems.
  7. On Computational Thinking: Liskov describes design as imagining the data types and operations a program needs, then treating their implementation as subproblems to solve in turn. — Quanta Interview — The Architect of Modern Algorithms.
  8. On the Spirit of the Time: Research now takes place on foundations laid by earlier work. Liskov contrasts that accumulated context with her early career, when fundamental questions were still poorly understood and researchers often had to strike out on their own. — MIT News — Q&A with Barbara Liskov.

Part 6: Critique of Modern Languages

  1. On Python's Encapsulation: Liskov criticizes Python’s lack of enforced encapsulation: having modules does not prevent outside code from accessing their internals. This is her design critique, not a claim that Python has no modular organization. — Peterman Pod — Data Abstraction and Distributed Systems.
  2. On Team Integrity: She favors compiler-enforced boundaries in large teams because conventions alone leave room for a programmer to violate a module’s assumptions. — Peterman Pod — Data Abstraction and Distributed Systems.
  3. On Python's Intended Use: She recognizes Python’s usefulness for helping beginners write programs quickly, while contrasting that aim with language-enforced safeguards for large systems. She also notes that she no longer considers herself a programming-language expert. — Peterman Pod — Data Abstraction and Distributed Systems.

Part 7: Navigating Career and Adversity

  1. On the Princeton Rejection: She recalls Princeton rejecting her mathematics graduate application because it did not admit women. She was admitted to Berkeley but chose a programming job instead, which she describes as a happy accident. — Peterman Pod — Data Abstraction and Distributed Systems.
  2. On Accidental Programming: After receiving a Berkeley graduate-school offer, Liskov chose a job at MITRE. She taught herself programming from a FORTRAN manual and discovered work that she enjoyed and did well. — ACM Oral History — Barbara Liskov.
  3. On the First CS PhD: MIT identifies Liskov as the first U.S. woman to earn a PhD from a computer science department. Her 1968 doctorate was from Stanford. — MIT News — Barbara Liskov Wins Turing Award.
  4. On Strategic Career Tracks: After her PhD, Liskov chose MITRE rather than the non-faculty technical position she thought MIT might offer. That gave her room to move from AI into systems research before she joined MIT’s faculty in 1972. — ACM Oral History — Barbara Liskov.
  5. On Ignoring the "Noise": Looking back, Liskov tentatively describes keeping a low profile and feeling little need to please others as part of her strategy. She also says that confidence in asking public questions took time to develop. — Quanta Interview — The Architect of Modern Algorithms.
  6. On Resilience: Liskov recalls being the only woman in her Stanford class and qualifying-examination cohort. That experience illustrates the isolation of the period, not a claim that representation posed no obstacle. — Infinite MIT — Barbara Liskov.
  7. On Competence: Strong work did not make discrimination disappear: Liskov recalls male peers being recruited while she was overlooked. Her later research recognition opened opportunities, but she does not present merit alone as a cure for bias. — Quanta Interview — The Architect of Modern Algorithms.
  8. On Value of Downtime: Liskov advises working hard on problems without working all the time. She emphasizes downtime and a balanced life; this excerpt does not establish that gardening produces technical breakthroughs. — Stephen Ibaraki Interview — Career Lessons.
  9. On Career Success: She advises finding work that matches both your abilities and your interests. For her, that fit made computer science a satisfying career. — MIT News — Q&A with Barbara Liskov.

Part 8: Mentorship and the Path Forward

  1. On Important Problems: She advises graduate students to seek more than incremental improvements: choose a significant problem that is tractable and fits their skills. — Peterman Pod — Data Abstraction and Distributed Systems.
  2. On Modern Education: She observes that data abstraction became so fundamental that some of her students did not realize there had been a time before it existed. — Peterman Pod — Data Abstraction and Distributed Systems.
  3. On the Future of Parallelism: In her 2013 talk, Liskov identifies massively parallel computers as a challenge for both programming methodology and programming-language support. — The Power of Abstraction — QCon Slides.
  4. On Cross-Chain Deals: Her 2019 coauthored work studies safe exchanges among mutually distrustful parties across ledgers. Cross-chain deals require different guarantees from classical atomic transactions; full decentralization depends on synchronous communication assumptions. — Cross-chain Deals and Adversarial Commerce.
  5. On BFT Scalability: Adding replicas is not free. Castro and Liskov note that extra replicas exchange more and larger messages, degrading performance without improving resilience when the tolerated-fault bound stays fixed. — Practical Byzantine Fault Tolerance.
  6. On Legacy: CLU’s data-abstraction mechanisms influenced later languages, including Ada, C++, Java, and C#. This is conceptual influence, not a claim that all modern languages descend directly from CLU. — MIT News — Barbara Liskov Wins Turing Award.
  7. On the Craft vs. Science: Her approach emphasizes specifications and reasoning about correctness rather than treating programming as merely producing code. — Peterman Pod — Data Abstraction and Distributed Systems.
  8. On the Long Game: She suggests that foundational work can become so widely assumed that people stop noticing its origins. Its influence may be embedded in how programmers think, not only in a recognizable named protocol. — Peterman Pod — Data Abstraction and Distributed Systems.