The Man Who Revolutionized Computer Science With Math (Category Distributed Systems)
The Man Who Revolutionized Computer Science With Math (Rubric #DistributedSystems)
In this video Lesley Lamport 8 He talks for a minute about special relativity, causality, distributed systems, and how it all fits together. This video is a short interview with Quanta Magazine where he explains the meaning of his classic phrase.
You realize that you are using a distributed system when a computer failure that you didn’t even know existed causes the entire system to shut down and, for you, you can’t do your job. But better to tell first, and what is known Leslie Lamport, who won the Alan Turing Award (Nobel, but in computer science). He's listed. Lamport clocks + happens-before: how to organize events without a common clock Paxos and replicated state machine: the foundation of failover clusters/storage LaTeX: the de facto standard for scientific layout TLA+: Specifications + model checking to catch design bugs to code
The most delicious thing about this interview is the story about the connection of special relativity from physics and distributed systems theory from computer science. As a Physics student, I really liked this part about multidisciplinarity and the benefits of physics. (Although I studied in the Department of Applied Mathematics, we gave physics to everyone so that no one left offended by the fact that it was not received enough.). Well, at STO. (special relativity) There is no universal “now”: observers can argue about what came before. But they don't argue about causality - Event A can affect B only if the signal (faster than light) Could have gone from A to B. And Lesley Lamport endured it. 1b1 c distributed systems:
- No global time. (latency, drift, party)
- But there is a causal partial order: "may the information from A affect B" As a result, order compatible with causality is more important in the distribution than “exact time-stamps.” Hence came the logical clock, the total order over the partial, and the consistent emulation of one serial state machine by several nodes. Anyway, I didn't know how Lesley came to this before, and then I found out and realized that this is really a brilliant game of reason.
But if you return to sinful land, you can glean such insights for engineers and technical managers. - Programming ≠ coding. The code is the last mile. There must be a pattern of behavior and explicit assumptions. (network, failures, order of messages, hours). An algorithm without proof is a hypothesis.. Even if you don’t write formal proofs, TLA+/model checker often catch bugs that are barely catchable. - Look for causation.. When arguing about the order of operations in the database / cache / queue – ask not “what hour was earlier”, but “what information could get where”.
One thought on Lasley's favorite algorithm, "Bakery" (mutual exclusion)" Here, the bakery metaphor works like this: each process takes a number, and the critical section includes a minimum. (equitably, id). In the original work, he even notes that such "numbers" can be implemented distributedly: store with the owner of the process and read over the network. The beauty is that the algorithm is correct even with very weak assumptions about memory: reading intersects with the record can return arbitrary "garbage", and proof-of-proofing still works. Lamport realized this when he was writing a proof – it’s a great argument why write specifications/evidences at all: they find properties you haven’t put in.
#DistributedSystems #Software #Engineering #Architecture #Leadership #SystemDesign