Transcript for:
Insights from Leslie Lamport's Lecture

my name is lesie Lamport and I am a computer scientist uh which is something that didn't really exist when I started being a computer scientist and it took me a while to figure out that I was one my relationship with computers began as a programmer it never quite occurred to me that I was doing anything scientific until after I had published enough papers that if finally occurred to me my education was as a mathematician it was just natural for me to think about computers as a mathematician when you write an algorithm you need to have a proof that it's correct an algorithm without a proof is a conjecture it's not a theorem and if you're proving things well that means mathematics computer scientists tend to think in terms of programming languages one of the epiphanies in my career was the realization that I was not writing programs as a computer scientist I was designing algorithms I came to realize that if I'm not writing a program I shouldn't use a programming language people confuse programming with coding coding is to programming what typing is to writing writing is something that involves mental effort you're thinking about what you're going to say the words have some importance but in some sense that even they are secondary to the ideas in the same way programs are built on ideas they have to do something and what they're supposed to do I mean is like what writing is supposed to convey if people are trying to learn programming by being taught to code well they're being taught writing by being taught how to type and that doesn't make much sense the best way way I have for teaching about programming as distinct from coding is to think about what the program is supposed to do mathematically there's a very big practical problem with this the mathematical education in this country is pretty terrible most people wind up being afraid of mathematics this is even senior programmers I've developed a language called t+ for writing down the ideas that go into the program before before you do any coding it's a pretty hard thing for engineers to get into but when they do it develops their ability to think mathematically a distributed system is one in which your computer can be rendered useless by the failure of a computer that you didn't even know existed non-distributed Computing is when different processes communicate by using the same memory and distributed computing means that they're communicating with one another by sending messages now my interest in distributed systems came about by Serendipity I received a pre-print of a paper by Robert Thomas and Paul Johnson who had an algorithm for implementing distributed databases these are databases where you could have multiple copies of the data sitting at different computers so that programs on each computer could have rapid access to the data but they had to be synchronized so that processes on all the computers got consistent views of what the data was I happened to have become quite familiar with special relativity one of the things that special relativity teachers you is that two different observers have different Notions of what at the same time means but there's one notion that is invariant there's a certain notion of one event happening before another event and that means that it's possible for information to be transmitted from one event to the other when the information cannot travel faster than the speed of light I realized that that that notion of causality was violated by the algorithm of Thomas and Johnson it's completely analogous to the relation and special relativity so what I did is I wrote a paper that explained this notion of causality one could solve any distributed system Problem by building what I called a state machine think of it as an abstract computer that does one thing at a time you make sure that all the computers in this distributed system cooperate to implement a single state machine and that idea has become you know fundamental in the way people think about building distributed systems I had never even thought about a distributed system before I wrote that paper as I progressed in my career I came to appreciate of the idea of working in Industry that's where most of the interesting problems that I found came from you know from Engineers having a problem to solve it reminds me actually of something that August Renoir once said if someone asked him why he painted outside rather than in his studio and what he said is if I were painting in the studio and I wanted to paint a leaf I would be able to you know think of only a half dozen or so different kinds of leaves that I could paint but when I was painting Outdoors there were just these millions of different kinds of leaves that were there that I could paint from I found my research the same way that if I sat down you know and just you know contemplated my Naval and think about problems you know there was this small number of problems that I could think of but there were just scars of them sitting out in Industry waiting to be to be solved my favorite of my algorithms is the bakery algorithm it's to solve the mutual exclusion problem that is keep two processes from using the printer at the same time processes choose a number based on the numbers that have been chosen by other processes and use an algorithm so that the lowest is allowed to use the printer but what is amazing about it is it does not make an assumption that almost every other algorithm makes the Assumption being that if say I'm changing my number from 47 to 100 and you read that number you'll either get 47 or 100 but that algorithm works even if instead of getting 47 or 100 you maybe got 4700 or maybe you got 99,999 the algorithm still works I didn't intend it to I mean I didn't intend that I just discovered that when I wrote a proof I never needed to make the assumption that is just so beautiful uh and you know I'm really proud that that that I uh stumbled on it [Music]