Transcript for:
Lecture by Leslie Lamport on Computer Science and Algorithms

my name is leslie lamport and i am a computer scientist 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 it 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 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 tla plus for writing down the ideas that go into the program 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 preprint 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 happen to have become quite familiar with special relativity one of the things that special relativity teaches 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 notion of causality was violated by the algorithm of thomas and johnson it's completely analogous to the relation in 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 has 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 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 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 auguste 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 navel and think about problems you know there's a small number of problems that i could think of but there were just scares 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 4 700 or maybe you got 9999 the algorithm still works i didn't intend it to i mean i didn't intend that i just discovered that when i wrote the proof i never needed to make the assumption that is just so beautiful uh and you know i'm really proud that that i stumbled on it [Music] you