The mess we’re in
CC Attribution - NonCommercial - ShareAlike 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this
Armstrong, Joe
Software is a mess. In the last 40 years I and my colleagues have been writing buggy, unspecified, and difficult to maintain software. By doing so we have created an entire industry. We have collectively created billions of lines of unmaintainable unspecified code that will require millions of programmers to work for thousands of years to correct the mess we've made. Where did things go wrong? Can we make things work again? Should we admit we were wrong and throw all our legacy software away and start again? How can we make correct software, that is easy to understand and maintain? I don't pretend I can answer these questions - but I have some idea as to what went wrong, so maybe we can learn from our mistakes. In this lecture I'll talk about some of the biggest mistakes we made and what we can learn from these.
 No hands up. Yeah, when about two and a half years before I was born, the first computer ran at Manchester University. It had, I think it was 18 instructions, and it made use of the Williams tube, which could store 1,024 bits on a Caffèdre tube for up to an hour. And that was the first program that ever ran on a stored memory computer. It was in 1948. Of course, I didn't really know about that when I was born. I discovered computing when I was a bit older, about 16 or 17 and at school. And I wanted to learn programming. So we could choose between Fortran, Assembler, or COBOL. But Assembler and COBOL weren't options because nobody knew how to program in them. So I had the choice of only Fortran and had a turnaround time of three weeks when you'd written a program. Now the situation's a bit better. Well, perhaps it's a bit better. So you guys, when you're starting out, instead of having a choice between three different languages, have a choice between 2,500 different languages. So there's much more to choose from. On the other hand, it's not easy to make that choice because there's so many bloody languages you don't know. Which language to choose? So I think actually we got into a slight mess and there went my slides. Hello. What happened to the slides? Is this me or you? Oh, no. There we go. They're back again. Isn't it marvelous? Right. Was that the second slide? That was the second slide. Yes. I started programming when I was about 17 and always been kind of intro. Whoops. That's the third slide. Why are they moving forward automatically? I didn't. Hey, stop it. Go away. Look. Right. Now don't do this to me. What? There's a little, which is that one? That one there. Right. So now it'll step forward. And if I could double click outside, that will that. Very good. Now it's not going to move forward. Is that right? Keep our fingers crossed. Right. So I'm going to, in this lecture, talk about three things, actually. I think we're in a bit of a mess, actually. So I'm going to go into why we're in a mess and tell you what the symptoms of the mess are and the causes of the mess. That's about the first third of the lecture. And then there's about a third of the lecture. I used to be a physicist, actually. So I'm going to talk about the physical limits of computation and what that means for computer programs and so on. And then since we're in this mess and I've contributed to making this mess, I've got some vague ideas about how we might conceivably get out of the mess. So I'll talk about that as well. So the start point for this, I think, I'm going to go back to about 1985, because that's when I was a young sort of, how old, of 85. I mean, I was a young 35-year-old with a gleam in my eye and thought, I'll invent a new programming language which the whole world will use. And to help me, I had these wonderful things here. So this is a computer from 1985. For comparison, it's a supercomputer from a couple of years ago. This little fella had 256 kilobytes of RAM. You could stick cards in it so you could get an amazing three megabyte. You filled it full of cards. You get three megabytes of memory. Isn't that a lot? You get eight gigabytes on a stick now. It had this blindingly fast eight megahertz clock. And it had a 20. Or if you had a lot of money, you could buy a 40 megabyte disk. So it wasn't really very good for downloading movies, because movies, digital movies hadn't been invented. They were like 800 megabytes anyway, so they wouldn't fit. What's missing from that list? That's the spec of 1985. What's conspicuous by its absence? What? A mouse. No communications. This thing can't talk to the internet at 100 megabits per second. It had no communications. That's a big thing that's changed. Now if you buy a computer, it's got a 100 megabit ethernet connector or something. It's got a Wi-Fi. You've got LTE and 4G and 3G and stuff. And you can connect to the internet at hundreds of megabits per second. Couldn't do that then. Distributed computing is only something that's emerged from about 1990 onwards. Only 10 years, 15 years into this period of distributed computing. That's radically changed what's going on. So that was the start point. And now we've got these supercomputers. So this guy, let me see. Well, it had 8 gigabytes of memory or typical laptop today, this little thing. 8 gigabytes of memory. That's 32,000 times the memory of the machine in 1985. Maybe a new laptop's a quad core running at 2.5 gigahertz. So it's 1,000 times faster. And it's got 250 gigabytes of solid-state disk or something like that. So it's maybe 1,000 times faster. So the machine that booted in 120 seconds in 1985 should boot in 120 milliseconds today. Does it? Does your machine boot in 120 seconds? No, it doesn't. So what the hell went wrong? What have we done as an industry? What have we got wrong? So I'm going to look at some of the things we did that were wrong. Right, so in the last 40 years, we've written a ton of code, millions of lines of code. But we have created an industry that will take up trillions of man hours to fix it. So you guys are going to say, I should retire and die. And you guys can live on and fix all this complete mess we've made. So welcome to programming. Now I'm going to look at some of the things they said about programming languages when I started and compare them to what we say today. And we'll see exactly the same thing. I mean, 1985, we're all going to program in PL1 and ADA. That's the future. Just forget about anything else. How many people program in PL1 here? Right. ADA? Oh, sorry. Well done. So you're believing this 1985 stuff and you're not going to change, right? So I take this with a pinch of salt. We're all going to be programming in C minus plus minus tran in the next million years. It's a load of rubbish. Well, when the hardware doesn't change, the programming languages don't change. So if the hardware is basically the same, the programming language will follow some S curve where you find a maximum and a most efficient way of programming that hardware. And then when the hardware changes, you'll suddenly start changing the programming models. So in fact, we've seen two changes in architectures in the last 15 years or so. The first thing is ubiquitous computing. I mean, the internet and being permanently connected to the internet at high bandwidth. That started in about 1990. By 2000, it's a fact. The significant factor there is this permanent connection wherever you go. It's in your pocket, it's through LTE or something like that. And that means you need to know about distributed programming if you want to build interesting applications. All the interesting applications are distributed. The second thing that's happened is the multi-core thing that happened in 2004. That was inevitable. It was predicted around about 1998 or something like that. Chips got bigger and bigger and bigger. And the clock speed got faster and faster and faster. But then a physical limitation hit in. You couldn't get from one side of the chip to the other at the speed of light. Because the speed of light is finite. It's not infinite. And so the synchronous chip design vanished. And you put multiple cores on with their own clocks. And that's because of the speed of light. You could also drop the voltage. So you can run at lower power because of that. So in the future, we're going to see. I mean, I've got, I'm experimenting with 64 core low power processor at the moment. Should see 1,024 core low power processors coming onto the market in 2015. And they're going to influence how we do things. So we've got a change in the hardware. And that will reflect in the change in the programming language. No programming languages have been explicitly designed with distribution, multi-core, and low power in mind. I haven't seen any languages that have been designed with that in mind. We're working on it. So we'll see what happens, sir. Right. And when those change, the languages will change. Right. So what are the problems? This lecture, what are the problems? What are the laws of physics have to say about computation? Can we get out of this mess we've got ourselves into? Right. So what are the problems? Here's a few problems. Legacy code, complexity, all this kind of stuff. I'm going to talk about each of those in turn. So legacy code. This is great. Legacy code is when all the programmers who wrote the stuff are dead. Right, that's legacy code. And it's a pain in the ass. There's no specific. Have you ever seen a program that had a specification? Well, I've seen a lot of programs, and I've seen a lot of specifications. And the two normally don't have anything to do with each other. They're kind of a vague description of what the program might do on a good day. They're written in archaic languages, which nobody understands. Right, that's great. You want to be a maintenance programmer? Here's half a million lines of COBOL. Wow. Cool. That's just what I wanted to do. You've got to change one line of it, but which line? That's the problem. Nobody understands how this stuff works. And it works. And then we've got business value. We've got managers who say, well, this legacy code, this million lines of stuff written in COBOL.Tran4 has got commercial value. It's got business value, so we can't touch it. And to rewrite it, because the first time it was written, took a million man hours or something to rewrite, it's going to take 10 million man hours. Of course, nobody knows what it does. It might not. Right. So it might not. So management thinks that modifying legacy code is cheaper than a total rewrite. They are nuts. They're completely lunatics. Sometimes it is. If that legacy code is in good order, but often it's not. Right. So what you do is legacy code. Don't touch it. Put it in a virtual. This is what you do. You put the legacy code in virtual machine. Don't mess with it. So you've got all these little black boxes running legacy code, which nobody knows what it does. And it's just sitting there festering like a nasty wart or something that will come and hit you one day. Horrible stuff. But it's created a lot of job opportunities. So it's pretty good. Complexity. Complexity. Right. So I have to sort of remind myself of some numbers. You can see a lot of numbers in this talk. So the mass of the Earth, I used to be a physicist, the mass of the Earth is six times 10 to the 27 grams. And the Earth's got about 10 to the 50 atoms in it. Just remember that number. 10 to the 50 is a nice number. So we do a back of envelope calculation. Here's my envelope. And back of envelope. So if we take 10 to the 50, 2 to the 167, and divide that by 32 and take the ceiling of that, that's six. What does that say? That says six 32-bit integers has what's that? 192 bits. But the number of atoms on the planet is 2 to the 167. So what does that say? That says a C program with six integers has more possible states than the number of atoms on the planet. And don't ask about JavaScript. What about JavaScript? Well, three variables, actually, because they're double precision. So what does that mean? Well, it means you need more than six unit tests. If you've got six variables, or more than three unit tests, if you've got JavaScript variables. Just as an aside, my machine, little machine here, has got a 250 gigabyte solid state disk in it. That means the number of possible states it can be in is 2 to the power of 250 billion times 8. OK? The total number of atoms, not in the planet, but in the universe, the total number of atoms in the universe, is about 2 to the 260. That means the complexity. The number of states that my machine can be in divided by the number of atoms in the universe is 2 to the 7 billion. So I'd need 2 to the 7 billion universes filled with computers. And I might just find one that's in the same state as my computer. Right. So this is why. You know, I do things on my computer, and it doesn't work. So I Google. I say, blah, blah, blah, blah, blah, blah, blah, blah, didn't work. And I find a web person. He says, oh, I have exactly the same problem as you. Do this. And there's lots of mails after. I say, oh, gee, thanks. That's absolutely great, because I had exactly the same problem. And I type this stuff in. And guess what? It doesn't work. Shit. So I Google again. And I find I had exactly the same problem. So I Google again. And I do it. And it doesn't work. Why is that? Well, because his machine, when he did these commands, or she did these commands, is not the same as my machine. Its state is different. In fact, the chance that it's the same is one in 2 to the 250, blah, blah, times 8. Right. And I would need to be very lucky in being one of these universes of the 7 giga, 2 to the 7 giga universes, where the guy has just happened to post in his machine was in the same state as me. Well, it's not going to happen. And it happened surprisingly early. Last week, no week before last at work, we got, my and my colleague, we both got two brand new Apple Retina laptop thingamijigs. And they were factory new. And they were installed. And we were going to run the same software. So we thought, we'll do the install together so that our machines are in sync. And after four hours, I typed some commands on my machine and an install worked. And he typed the same commands on his machine. And the install failed. Right. And we'd be up to that. We'd been the same. And then what do we do? Well, he started googling, oh, how the hell I did it. I didn't work trying doing that. So they diverged after four hours. Of course, they weren't the same to start with. But you kind of think they're the same, don't you? It's not true. It's not true. So what's the answer to all of this? Well, scary math to the rescue. The trouble is, scary math hasn't got there yet. We don't have scary math to help us yet. OK? Because scary math is trying to prove things about the states of these programs. So the only way it can do it is prune the search space down to something that's manageable and then look at that. So you can't really prove things about programs of more than two or three variables in. So that's pretty tricky. Well, sometimes, if they're specially constructed, you can. So we can't really look to scary math to help us yet. It's coming along. It takes a long time. It takes like 100 years for somebody to get a good idea. And then it takes. I mean, look at the Lambda calculus. Church had invented the Lambda calculus in 1930. The type of Lambda calculus in 1936. And I think it got into Java this year, didn't it? Or last year or something. I mean, it takes rather a long time. And then nobody's had any ideas since church. So there you go. Failures. What about failures? Well, stuff fails. Deal with it. Stuff does actually fail. Computers fail. So there's only one way to handle failures. Do it on another. Joe's first theorem. In order to handle failures, you need two computers. Because if the whole computer crashes, you're screwed. Sorry, at least two. If you want to tolerate the failure of 100 computers, you need 101. Probability of them all failing at the same time is 2 to the power of 101. So it's low. But still might all fail. That means that you need to understand distributed computing because you've got two computers. You need to understand parallel computing because they're running at the same time. And you need to understand concurrent programming because the programs in them are running at the same time. So if you think you can do error handling or scalability without understanding these three things, it's not going to work. Now, I'm not going to talk about that. I've written three books about that and made a programming language to embody some of those ideas. And if you want to read more about that, you can read some of those. Right. Means because systems break, because they're becoming more complicated, we have to make them so that they will self-configure and they will repair themselves and they will evolve with time. I think they'll be like us. They'll gradually die. And it's a very interesting problem, handling dying chips, how they, I'm looking at that, multicores where the cores start failing. When we produce 1,000 core multicore chips, half a dozen of the chips won't work. And then as we run them, some of the cores will start failing. And we need to live with that. Don't want to throw them away because bits of them don't work. Languages. Language doesn't matter, they say. Well, they should have told the Romans. Do you do arithmetic like this? No. It's even worse. You see, Romans didn't have a zero. And they didn't have negative numbers. For a lot of, do you know how old negative numbers are? They're not very old. They were about, I can't remember the date, 1,700 and something. We need notations and things that are familiar and easy to work with. And if you're kind of in this mindset of programming in with numerals like this and somebody else is using Arabic numerals, you won't understand each other. You say, well, it's a lot easier using Arabic. No, no, no, no, no, no. I'm perfectly happy with this. I mean, I'm not talking about Jarbrun Haskell and things like that. I'm talking about Romans and things. But there are analogies to be made there. So 1985, everybody. So there's a little star there. Not absolutely everybody. Everybody knew the born shell, make and see. If there were sort of scientific, technical programmer sort of type. That meant they could talk to each other. Programmers could talk to each other. Well, now we can't talk to each other. We don't have these common languages. When you go to these big conferences, there's these.NET people. Any.NET people here? Right. Any JVM people here? Right. Oh, golly. I've been to other conferences. I say, any JVM people. Oh, the hands go up. And you say, any.NET people here? Nobody. And I'm a sort of neither a.NET or a JVM person. So I don't really belong here. I hope you won't eat me. It's like talking to the light. I've been thrown to the lions. 99% of the audience were.NET people. Oh, my god. What's.NET? You think I'm joking? I haven't actually got a window. No, none of my friends have got a Windows machine. I don't know what it is. Well, I used one. Well, that old thing, that had a Windows audience. Yeah. And so now what do we program for JVM.NET? We program in Ruby, do before, Tran, and the bubble. We can't talk to each other. Right. So we can't sort of send programs to each other. We can't understand them. So when I learned to program at Jews, I said this earlier, I can choose three languages. Now, first list I looked on, I looked on the Wikipedia. And it said there were 776 languages. Looked somewhere else, 2,500. There's a lot anyway. And then we have build tools. Well, once upon a time, I said everybody talk to make. Makes wonderful. I love make. And now there's Ant and Grunt and make, and Rake, and Malvin, and Jake, and Bacon, and BitBake, and Fabric, and Paver, and Shovel, and BitGrovel, and God knows what. And what the hell these things are. So I was researching this talk, and I looked up on Stack Overflow. And somebody asked the question, is there a rake equivalent in Python? Yeah, well, this paver, invoke Shovel, WAF, and well, that's really good. That's what I like. So a couple of months ago, I was writing this. I actually do some programming for my living at Ericsson. I was writing this program in Elling, and it was going to go into a product. I want to put it on the target. And so the guy says, well, we've got this script that does it. Just log in on this development system, and type make, because it was a make file, actually. Well, it evoked a bake file, no, a BitBake file, a bake recipe. And it was taking a while. I left it, and I went, oh, oh, oh, oh, oh, oh, oh. 18 hours later, it had downloaded 46,000 files, which included the entire source code of the Linux kernel and of GCC, compiled the whole bloody lot up, and then built a single image, when then it cryptographically signed it and done all this stuff. And then I could take my three-module program and put it on the target. Well, of course, Elling was designed to be object code compatible. So you just move the files over anyway. No, that's not possible. We have to use BitGrum Tour. I know you'll say you should have used Grunt, and it would have been easy, but I don't know how to build Grunt files. I'm sorry. This is not good, actually. Right. So without Google and Stack Overflow, programming would be impossible. I've shown these slides to somebody two days ago, and he said, well, when the internet stops, I can't program. Why didn't they go? It's really very good. And I don't think, oh, shit, it doesn't work. Oh, Google it is a very good programming paradigm. In fact, I think programming is going to stop. You see, if you plot, if I reckon the amount of time I spend fixing stuff that's broken that shouldn't be broken, corresponding to do real work where I'm just doing stuff, the fixing stuff that's broken that shouldn't be broken takes 30% to 40% of my time, and that is increasing with time. So I think in 10 years' time, nobody will be able to program anything you use that will be broken in 10 years' time, and you won't be able to program you. You'll spend all your life in Google searching for, well, why did my fucking program work? Because I've done this, and it's supposed to work, and it's not going to happen. Right, good. So efficiency, and I love efficiency. You know, programming language designers, they don't care about efficiency. All the programming, like Dennis Ritchie and everybody ever invented programming, don't think about efficiency. Think about correctness. Why is that? Because programming language designers get blamed. If a programmer writes a program and it crashes and kills somebody, you see, it's their fault, it's not my fault. You shouldn't have put it in your bloody language, right? So I'm more concerned about correctness than efficiency. So we have this sort of dichotomy between efficiency and clarity. So to make something clearer, you add a layer of abstraction. And to make something more efficient, you remove a layer of abstraction. So you're always kind of dicing around between these two alternatives. And of course, in the last 30 years, we have systematically chosen efficiency over clarity. Well, that's great. That's fantastic, because now we have machines that are so frigging fast, you can throw anything at them, and they do instantaneously, if the code is correct. Right. So about 20 years ago, I was telling my bosses at Ericsson, I was saying, look, this is stupid. What we have to do is write our software as clearly as possible. And there's a few lines of code with as closer correspondence as we can make it to the specification and to the mathematics. And then we'll be in a very good position in the future, because as processes get faster, we'll just be able to take this stuff. And one day, it will be fast enough. Right. So it's really simple. If you're in a program, you want to optimize it, make it 1,000 times faster, just wait 10 years. And it's really simple. Alan goes a million times faster by waiting 20 years. You just wait 10 years, it goes 1,000 times faster. Who's in such a bloody hurry? Why do we want it to be quick tomorrow? We're making this legacy code now, that if we don't fry the planet, and if we don't have a nuclear war, and if we don't have a pandemi, and if the nanorobots don't take over, and if we're not hit by an asteroid, and if there's not a supervolcano, it's going to last for a bloody long time. And you look back at this archaeological layer of crap that was done in the beginning of computing. And so why did they write it like that? Why didn't they just write it efficiently? Sorry, no, oh, sorry, clearly. Hey? And so what we see in the beginning of a technology is companies compete by being incompatible with each other, by being deliberately incompatible with each other. So the early browser wars were a Microsoft browser was deliberately incompatible with a Netscape browser. After 10 years of that, people say, hey, that's bloody stupid. Let's try and make them. Let's not compete over browsers. Let's try and make them compatible with each other. So now we're into this. OK, the browsers are largely, they all use WebKit, and something like that. So they are compatible. So the wars are somewhere else. So we've got some decent functional programming. We've got Haskell, the LNG, things like that. And then, OK, so let's not use them, Microsoft. All there's some really good ideas in functional programming. I know what we'll do. We won't use them. We'll invent our own language, F sharp. That's nice. That's great. And then Apple comes along. Oh, there's some really good ideas in functional programming. I know what we'll do. Let's not use them. Let's invent our own one. Why is that? Why is Microsoft making F sharp? Why is Apple making Swift? To lock you in forever so that we can't talk to each other. Now that will last for 10 to 15 years. And then everybody will say, oh, this is a complete mess because we've got all this legacy code which can't talk to each other. We've got the.NET world. We've got the JVM world. And you guys can't talk to each other. But it becomes part of that legacy code which has to be maintained for thousands of years into the future. It's not a good idea. Contribute to the stuff. Now is not the time to be inventing new functional languages because that was done a while back. That was done in the 80s. So if Apple wanted to do something, make a Cocoa Bridge to Haskell or to Erlang so that we can really use Cocoa and the nice gooey stuff. Don't make your own thing because you don't have all the libraries. You don't have all the stuff going. Right, names. How we do for time? Golly. I have to speed up. Names. Names. We name things. Names are imprecise. Terribly difficult deciding on names. Unique names. I'm called Joe. Any other Joes? No. So Joe's unique in this namespace. But if it's a bigger namespace, there's lots of Joes. I'll talk more about that later. It's the root of all evil. Right, now it's a sort of changed subject now. This is light relief because I'm an ex-physicist. What do the laws of physics have to say about computation? Any other physicists? Good, thank you. Right. So my interest in this was spiking. I was reading the Elling-Manual pages. And it said, the return reference will reoccur. It's make a unique reference. It said the return reference will reoccur after approximately 2 to the 82 calls. And therefore, it is unique enough for practical purposes. I just wondered what this sentence meant. Well, 2 to the 82, that's 10 to the 25. Sometimes I use 2 to the, sometimes I use 10 to the. What do these numbers mean? Right. So in this physics, I'm going to talk about causality. Simultaneuity, entropy, speed, and computation, storage capacity. So causality to a physicist, a cause must proceed in an event. We communicate through messages, some rays of light, sound. You don't know about, you hear what I say a couple of milliseconds after I've said it. You see my arms waving about before you hear what I say. Your brain sort of sorts that thing out. You think it's simultaneously. Information travels at or less than the speed of light. You don't know how something is now. You knew how it was the last time you talked to it. So simultaneuity, this is basic sort of physics. We've got two stars, A and B. In different parts of the universe, and they explode at the same time. They explode at the same time. We've got three observers. And they look at that. Well, this guy over here, this bloke here, he's nearer to A than B. So light to him gets there first. So he says A exploded before B. And the guy to the far right, he says, well, B exploded before A. And the guy is in between them. He says, well, they happened at the same time. So physicists gave up this idea of simultaneuity for a long time ago. Prior to, you know, I mean, as soon as you realize that light traveled at a finite speed, that this whole notion of simultaneuity is vanished from physics. You're not allowed to talk about simultaneuity. So if you put it into sort of computer terms, try and replicate data. Suppose you've got a server A where you store something and a server B where you keep a replica. If you update X on A, you send X equals 10 to B and it replicates it. It sends an act back to A. Trouble is that B doesn't know that A knows that the value is replicated, because it doesn't know that the act signal has got there or not. They can't make any assumptions about that. So if B wished to know that A was replicated, i.e. that it had the same value, because it doesn't know that the act signal has got back there, you'd have to send an act signal back from A to B. But A doesn't know that the act signal has got back to B. This is called the Byzantine general problem. And it's a very simple impossibility proof that when you've got data in two different places, there is no physical law that can determine that. They're the same. You're violating the laws of physics, if you say they're the same. What does that mean? It means that two-phase commit doesn't work. It actually means that three-phase commit doesn't work. Well, it actually means that infinite-phase commit doesn't work. So you can't have data in two places and know that it's the same. It's a law of physics, which we break a lot. It's not a good idea breaking the laws of physics. They're there for a good reason. Entropy always increases. Entropy is the amount of disorder in a system. If you take a load of dice, you chuck them up in the air, they're not all going to land with one up, or always six. They're going to become more and more disordered. This is the second law of thermodynamics. Entropy always increases. In software terms, it means systems become more disordered all the time as you build them. This is the law of physics. Speed of computation. This is quite fun. Who are the geysers here? That's a little quiz. Who's this guy? Sorry? Yes, that's right. Yes, that's Albert Einstein. This is Hans Joachim Bremermann. Who's this guy? No? Yes, Planck, Max Planck. So Max Planck is kind of a phabric quantum mechanics. One of his relationships is E equals H mu. E's the energy of a black box radiator. A black box radiator couldn't radiate in different frequencies. And the energy in a particular frequency is Planck's constant times mu. OK, so that's one of Planck's relationships. Einstein said, well, E equals M. Everybody knows E equals Mc squared. That's the amount of energy in a given mass. So Mr. or Dr. Professor Bremermann said, well, if E equals H mu and E equals Mc squared, then H mu is Mc squared. Just knock out the E. And mu is M times C squared over H. So C squared over H is called the Bremermann limit. And it's 1.36 times 10 to the 50 hertz per kilogram. OK, so that says that a 1 kilogram computer, a 1 kilogram of anything, it doesn't matter what it is, a 1 kilogram of anything can oscillate at a max of 10 to the 50 cycles per second. That's an upper limit on how fast an oscillator can run. That's a clock frequency of a kilogram of stuff. They can't go faster than that due to quantum mechanics. Right. So not only is there the Bremermann limit, there's Bremermann's limit, the Margolius-LeVintien theorem, the Birkenstein bound, the Landau limit. We all familiar with these. So I'll just go through them very quickly because they tell us important things about computing. So the Bremermann limit, that says that the max clock rate of a 1 kilogram computer is 1.6 times 10 to the 50 hertz C. The Margolius-LeVintien theorem, that relates computation to energy. We can do 10 to the 33 operations per second per joule. The Birkenstein bound, that tells us how tightly we can pack information. What is it? 10 to the 43 bits per meter times of, sorry, wait a minute, per mass and meter. You take the mass of the thing and the radius of the sphere. That's the maximum stuff. And then the Landau limit, the minimum energy to change one bit of information. And that's 2.85 zeta joules at 25 degrees. I didn't know what a zeta, I had to look up what a zeta joule was. It's 10 to the minus 21 of a joule. There's another unit. I just invented it. It's FBDC. It's a Facebook data center. And that's 28 megawatts. So Facebook data center is 28 times 10 to the 6 joules per second. And the Landau limit is 10 to the minus 21 of a joule. So you see this 27 orders of magnitude difference. Of course, the Facebook data center is not just doing a one-bit operation. It's doing lots of bits operation. But you get some idea of that. So let's build the ultimate laptop and see what that is. Well, as you add more and more components, it gets hotter and hotter and the component density gets greater and greater. So the ultimate laptop is a black hole. Of course, we squashed all this stuff into it. And it runs at this Bremerhauer limit. What was his name? Bremermer. I forgot the name. So it's running at 10 to the 51 operations per second. So you think, well, this is bloody useful. I can do a lot in that. But there's a problem. It's pretty small. It's 10 to the minus 27 of a meter big. So you might drop it and not be able to find it. It's got a storage capacity of 10 to the 16 bits. And above all, it lives for 10 to the minus 21 of a second. So yeah. But it's done 10 to the 31 computations during that time. And you might ask, how does it get out? Black hole stuff goes into black holes. You might have heard this. Stuff falls into black holes. But it can't get out. Well, that's not true. Stephen Hawkins found there's something called Hawkins Radiation that comes out of a black hole when you drop stuff into it. So if you take an elephant and you drop it into a black hole, you get an elephant's worth of energy that comes out of the black hole. But how does it come out? Oh, there's a picture. Nice picture from Scientific American. What happens is outside the black hole, things are falling into the black hole. They split into pairs. Particles and antiparticles, say one of them drops into the black hole. They're split pairs. So their spins and things are equal and opposite. And provided nobody measures them or does anything, you're fine. When you change the spin or something of the thing inside the black hole and somebody measures it outside, it instantaneously has this value. It's called quantum entanglement. Einstein called spooky action at a distance. He didn't believe in it, actually. So there's a kind of technical problem. A, how to encode our program. We drop it into a black hole and the answer instantaneously appears due to quantum entanglement somewhere else in the universe. These are technical problems which I leave to future programmers and physicists. Not quite sure how to work it. Oh, well, hang on. That was the ultimate laptop. What's the ultimate computer? Well, that's the entire universe behaving as a black hole, right? It's a black hole computer that's, you know, it's the ultimate computer. So we could ask the question, how long, how many operations has the universe done since it was booted? So you boot the universe and you wait 10 to the 10 years about now. And, well, it's done 10 to the 1, 2, 3 operations since then. Okay? This is as a quantum computer. Its size is 2 to the 26, 2 times 10 to the 26 meters and it will live for 10 to the 10 to the 100. Well, that's a Googleplex. Nobody really knows. It's like cool down and die, I suppose, I don't know. So that's giving you some sort of, if the number of operations, the entire universe, working as a quantum computer since it was created is, what did I say, 2 to the 409. If you wanted to craft a crypto key that's, you know, by systematic search of all keys and you've got a 512-bit key to just go through them all one at a time. If you could go through them on one clock cycle, it would take 2 to the 103 universes to do that. It's actually cryptographers use measures from quantum mechanics to set the upper bounds on the complexity of the algorithms. So you don't actually need to, you don't need infinite length keys. You just need to set them in relation to the size of the universe and then you're fine. And yeah, okay. So there's some paper-safe reader. There's a very readable article in Scientific American about black hole computers from 2012. Fun facts and figures. Oh, this is wrong, I noticed. One kilogram can do 10 to the 51, store 10 to the 31. And I wrote it, it's a 10 giga gigahertz. That's obviously not a giga gigahertz machine, it's a giga giga giga giga giga giga giga giga giga giga giga giga. Oh, I forget it. I mean, it's fast. It's faster than this thing, anyway. A conventional computer can do 10 to the 9 operations per second if you compare it to the black hole computer. And the universe can store 10 to the 92 bits of information. Multiply 92 times 3 is about 270. So the number of bits in the universe is about 2 to the 2 to the 290. So for a 290-bit checksum, you're about on par with the number of bits you can store in the universe. So SHA1 is 120 bits. It's not enough if you want to store a checksum of everything in the universe. It's probably good for the earth, so it may be all right. I have to think about that. Exercise. So the number of bits should a checksum have to uniquely identify every atom on the planet. Answers on the back of an envelope. Right, it's a third bit. Golly, I have to speed up. So we created all this mess. We've got the laws of physics. What are we going to do about it? Right, so I have a little proposal here. We've got to break the laws of physics. We can reverse entropy if you put energy into the system. We've got to build the condenser. The condenser should have made a better size like a meat machine. You put all files into it and you turn the handle and less files come out. So we condense. You see, what we've been doing in the past is we've been expanding the amount of information. Right. So let's break this. Just breaking the second law of thermodynamics. We can do that if we put energy into the system. That's fine. Why did the number of files increase? Well, you start off with files and you make more, you take a file and you edit it and you do this and you do that. That's entropy increasing. Files mutate. When you've got a file, well, disks are really huge. Every time I buy a new computer, I just copy all the stuff I had on all my old computers onto it. Just a complete mess. I can't find anything on it. I mean, I've got 43,000 Erlang files on my machine. I can't find anything in them. Then you have a file. You've got some data. You say, well, I wonder what file name I should have. Oh, okay. I don't know. I wonder what directory I should put it in. Oh, I don't know. I wonder which machine I should store. I don't know. And that problem gets worse and worse and worse as you have more and more files. It gets far worse when the system becomes distributed. Right. So I want to declare the war on names. You know, the war on terror. There's a war on poverty. We programmers, we should declare the war on names. It's kind of been, you know, Git's quite good. It's declared the war on names nicely. So we shouldn't have any names. So a few examples. To talk about things, they need names. We can't talk about something if we can't name it. It's a basic philosophical fact. Okay. So here's a paragraph of text. Cup of tea. He sat down, cut a buttered slice of toast. He tore away the burnt flesh and flung it to the cat and so on. What's that from? I know you'll use Google. Any guesses? James Joyce is from Ulysses. Because that paragraph has no name, we can't talk about it. So let's name it. Well, it's not really a name. Okay. So there we go. Just compute it's SHA1 checksum. Right. The name of that paragraph is 79.915.0AD. So given that name, I can tell, that's not really a name, it's a hash. Given that hash, I can tell anybody. I'm talking about the paragraph. Well, not about the paragraph. I'm talking about 79.915. Blup, blup, blup. We've uniquely named this. There's no ambiguity whatsoever. Right. So imagine, let's do away with these URIs. They are evil. They are silly idea. Well, they're not a silly idea, but they're okay for a props emotion to the truth. So look at this thing. It's got two parts. It's got a host name. Use DNS to look the host name up and then it's got a resource name. Well, DNS can be spoofed. A naughty person can put a false thing into DNS or send you to the wrong DNS. If the resource was changed, this reference is wrong. It points to the, you know, that reference you found in a file or something, it points to that. But somebody changes that, what do we call it, ABC. They change the content of C. You still got a reference to the old C. You get the new C. If you put a time to live or a caching in, you wouldn't know what time to put it in. Suppose you put this in a cache and it says time to live for 10 minutes and the guy changes it after five minutes. You can't invalidate the cache or something like that. There are all sorts of problems with this. And the content can be changed by a man in the middle. Bad guys can listen to this stuff and change the content. So we don't want this at all. So let's do it like this. Instead of having a URI, we'll make a new type of thing. We'll just say hash and there's the name. Just go and get, notice there is no host name. There's just the hash of the content. The nice thing about this is, you say to this, go find this thing, go find this blob that has this hash. So no man in the middle can attack that thing because you get the blob back. You compute the hash. That is what you're asked for. So no man in the middle can change this. No man in the middle can attack this. No DNS thing can spoof this. If you get an answer, it's what you asked for. It is completely safe. It doesn't need any crypto keys to be exchanged. It doesn't need to be protected from man in the middle attacks. It doesn't need to do anything like that. So then the question is, how do we find this thing? Because we haven't said which host it's on. Well, that's a well-solved problem. So DNS usually works. You've got two start addresses in your, okay. So you have two start addresses in your machine. And the answer is what you've got when you turn your machine off. So when you boot your machine, you've got two start addresses in a cache. A DNS1 and DNS2. And you go and look at these two addresses. In a peer-to-peer system, you've got a long list of machines that are known to participate in a distributed hash table. And what do you do? Let's suppose I know about these machines here. Here's the IP addresses of machines that are participating in a peer-to-peer distributed hash table. And what you do is you compute the SHA1 checksum of each of these IP addresses, and you sort them all. And you say, okay, I've got this resource. I want to find something with this hash. Where is 536852? You look in this and say, well, it's somewhere these two machines here that I've highlighted. They're the nearest machines in this space to this hash address. So I go and ask them. And they've got lists like that. And they'll find the nearest ones. And they'll go and ask them and so on. Okay, so this is the basis of CORD and Catermelia and algorithms like that. These are well-understood algorithms. The Catermelia system's got something like 9 million machines. It's actually invented by the file sharers who are using it to share movies and things like that. But it works great. So we could put all information into this. Right. Instead of just having movies and things like that, just put all information into it. Right. So here's how to make... So I'm going to make the condenser. The first thing we want to do is find all identical files and then find all similar files and reduce the amount of information on the Internet. Well, finding all identical files on the Internet is trivial. We compute the SHA1, check some of it, and we inject it into the hash table. That's all we have to do. You can do that in all the machines in the world. Can run in parallel. We could do this in a few hours and get rid of all the replicas. Okay? That's what Dropbox does, I think. If you put stuff in there, it's got the same checks and without. I don't need to keep multiple copies. I just keep two or three copies. Right. So that's the finding all identical files bit. Now we want to find all similar files. Right. Find the most similar file to a given file. This is a tricky problem. I've been thinking about this for ages. Okay. So the best algorithm I know, I'll just tell you the answer. It's called least compression difference. If two things are similar, then if you concatenate them and compress them, the size of the thing will be, okay, so you've got the file here. You compress it. It's got a certain size. If you took the file twice and compressed it, concatenate it and compressed it, the file size of the compressed file would be only a little bit greater than the file size because it's just describing the difference. There is no difference. So if you take a file, concatenate it to itself 100 times and compress it, it's about the same size as the file compressed by itself. It's very dissimilar. Two files that are totally dissimilar. Random numbers that are totally dissimilar. If you compress A and you compress B and you compress A concatenate it to B, the size of the totally dissimilar one will be more or less the size of the sum of both of these. So this will find the most similar thing. It's very insensitive to changes in the compression algorithm. So I have a thing on my machine. I type, when I've got information, I type it into a little box like Twitter. I press the Sherlock button. Sherlock Holmes, this little icon there. I press Sherlock. It does least compression difference on most of my files. It takes a long time. Then it says, hmm, do you know? The most similar thing to that was something you did 15 years ago and it's in this file. It finds it for me. I want that to be on the entire internet. I want us to put all the information we've got into the internet so that we reduce the amount of information. We reverse entropy and you just make it more manageable. Okay. Right. This takes order of time n, where n is the number of files on the planet. So it's not super quick. So I'm just wondering if we can speed it up. We have to reduce the search space. I don't really know how to do that. I'd like to talk to some researchers who know how to do that. But there's a little hint there on, we certainly know things that couldn't be similar because they're very different sizes. The plagiarism detection algorithms, do you know how they work? They work on a rolling check sum. There are databases of open source software and of student essays that people do for the feces. What you do is you take the source code or you take the student fee. You chop it into 50-byte blocks, say 50 bytes, and you compute a check sum, an MD5 or an SHA1. You stick that in a key value database. Sorry, no, it's not an MD5. It's called a rolling check sum. I didn't mention what they're called. A rolling check sum is one that you take 50 bytes, you compute the check sum, and if you shift it by one byte, you can incrementally change the hash. It's a typical one. You XOR all these bits. Simple one is XOR all the 50 bytes. When you shift it by one byte, you XOR the final byte and XOR the beginning byte, and now you've got the check sum of the next block. That's called a rolling hash. What you do is you take your data, split it into 50-byte blocks, compute the hash, the rolling hash, stick them in a catamilia or a distributed hash table, and then you take your 50-byte block, look it up in the hash table. If it's in there, that line would possibly be the same. Let me go and look at it and see if it actually was the same. You can do that in linear time per docket. It needs order of n lookups where n is the number of bytes in the file. It's reasonable. You could probably do that fairly quickly, I think. Right. Summary. We made a mess. Horrible mess. Created millions and trillions of man hours of work. In order to get out of this mess, we need to reverse entropy and start making things simpler instead of making things more complicated. Quantum mechanics sets the limits to the precision or the number of bits we need in checksums and things like that. We can dimension our systems accordingly. We would love some mathematics to prove things. I think we're going to have to wait a long time. Yeah. Well, join the war on names and help me build the condenser. That's the next five years job. Thank you very much. So, any questions? Yeah, where do I buy a quantum computer? You can't. And wouldn't a black hole computer be dangerous? Possibly. No questions, though. Different problem. Google it. Get to work.
 No hands up.  Yeah, when about two and a half years before I was born,  the first computer ran at Manchester University.  It had, I think it was 18 instructions,  and it made use of the Williams tube, which  could store 1,024 bits on a Caffèdre tube for up to an hour.  And that was the first program that ever  ran on a stored memory computer.  It was in 1948.  Of course, I didn't really know about that when I was born.  I discovered computing when I was a bit older, about 16 or 17  and at school.  And I wanted to learn programming.  So we could choose between Fortran, Assembler, or COBOL.  But Assembler and COBOL weren't options  because nobody knew how to program in them.  So I had the choice of only Fortran  and had a turnaround time of three weeks  when you'd written a program.  Now the situation's a bit better.  Well, perhaps it's a bit better.  So you guys, when you're starting out,  instead of having a choice between three different languages,  have a choice between 2,500 different languages.  So there's much more to choose from.  On the other hand, it's not easy to make that choice  because there's so many bloody languages you don't know.  Which language to choose?  So I think actually we got into a slight mess  and there went my slides.  Hello.  What happened to the slides?  Is this me or you?  Oh, no.  There we go.  They're back again.  Isn't it marvelous?  Right.  Was that the second slide?  That was the second slide.  Yes.  I started programming when I was about 17  and always been kind of intro.  Whoops.  That's the third slide.  Why are they moving forward automatically?  I didn't.  Hey, stop it.  Go away.  Look.  Right.  Now don't do this to me.  What?  There's a little, which is that one?  That one there.  Right.  So now it'll step forward.  And if I could double click outside, that will that.  Very good.  Now it's not going to move forward.  Is that right?  Keep our fingers crossed.  Right.  So I'm going to, in this lecture, talk about three things,  actually.  I think we're in a bit of a mess, actually.  So I'm going to go into why we're in a mess  and tell you what the symptoms of the mess are  and the causes of the mess.  That's about the first third of the lecture.  And then there's about a third of the lecture.  I used to be a physicist, actually.  So I'm going to talk about the physical limits of computation  and what that means for computer programs and so on.  And then since we're in this mess  and I've contributed to making this mess,  I've got some vague ideas about how we might conceivably  get out of the mess.  So I'll talk about that as well.  So the start point for this, I think,  I'm going to go back to about 1985,  because that's when I was a young sort of, how old, of 85.  I mean, I was a young 35-year-old with a gleam in my eye  and thought, I'll invent a new programming language  which the whole world will use.  And to help me, I had these wonderful things here.  So this is a computer from 1985.  For comparison, it's a supercomputer  from a couple of years ago.  This little fella had 256 kilobytes of RAM.  You could stick cards in it so you could get an amazing three  megabyte.  You filled it full of cards.  You get three megabytes of memory.  Isn't that a lot?  You get eight gigabytes on a stick now.  It had this blindingly fast eight megahertz clock.  And it had a 20.  Or if you had a lot of money, you could buy a 40 megabyte disk.  So it wasn't really very good for downloading movies,  because movies, digital movies hadn't been invented.  They were like 800 megabytes anyway, so they wouldn't fit.  What's missing from that list?  That's the spec of 1985.  What's conspicuous by its absence?  What?  A mouse.  No communications.  This thing can't talk to the internet at 100 megabits  per second.  It had no communications.  That's a big thing that's changed.  Now if you buy a computer, it's got a 100 megabit ethernet  connector or something.  It's got a Wi-Fi.  You've got LTE and 4G and 3G and stuff.  And you can connect to the internet at hundreds of  megabits per second.  Couldn't do that then.  Distributed computing is only something that's emerged from  about 1990 onwards.  Only 10 years, 15 years into this period of distributed  computing.  That's radically changed what's going on.  So that was the start point.  And now we've got these supercomputers.  So this guy, let me see.  Well, it had 8 gigabytes of memory or typical laptop  today, this little thing.  8 gigabytes of memory.  That's 32,000 times the memory of the machine in 1985.  Maybe a new laptop's a quad core running at 2.5 gigahertz.  So it's 1,000 times faster.  And it's got 250 gigabytes of solid-state disk or something  like that.  So it's maybe 1,000 times faster.  So the machine that booted in 120 seconds in 1985 should  boot in 120 milliseconds today.  Does it?  Does your machine boot in 120 seconds?  No, it doesn't.  So what the hell went wrong?  What have we done as an industry?  What have we got wrong?  So I'm going to look at some of the things we did that were  wrong.  Right, so in the last 40 years, we've written a ton of code,  millions of lines of code.  But we have created an industry that will take up  trillions of man hours to fix it.  So you guys are going to say, I should retire and die.  And you guys can live on and fix all this complete mess  we've made.  So welcome to programming.  Now I'm going to look at some of the things they said about  programming languages when I started and compare them to  what we say today.  And we'll see exactly the same thing.  I mean, 1985, we're all going to program in PL1 and ADA.  That's the future.  Just forget about anything else.  How many people program in PL1 here?  Right.  ADA?  Oh, sorry.  Well done.  So you're believing this 1985 stuff and you're not going to  change, right?  So I take this with a pinch of salt.  We're all going to be programming in C minus plus  minus tran in the next million years.  It's a load of rubbish.  Well, when the hardware doesn't change, the programming  languages don't change.  So if the hardware is basically the same, the  programming language will follow some S curve where you  find a maximum and a most efficient way of programming  that hardware.  And then when the hardware changes, you'll suddenly  start changing the programming models.  So in fact, we've seen two changes in architectures in  the last 15 years or so.  The first thing is ubiquitous computing.  I mean, the internet and being permanently connected to the  internet at high bandwidth.  That started in about 1990.  By 2000, it's a fact.  The significant factor there is this permanent connection  wherever you go.  It's in your pocket, it's through LTE or something like  that.  And that means you need to know about distributed  programming if you want to build interesting applications.  All the interesting applications are distributed.  The second thing that's happened is the multi-core  thing that happened in 2004.  That was inevitable.  It was predicted around about 1998 or something like that.  Chips got bigger and bigger and bigger.  And the clock speed got faster and faster and faster.  But then a physical limitation hit in.  You couldn't get from one side of the chip to the other at  the speed of light.  Because the speed of light is finite.  It's not infinite.  And so the synchronous chip design vanished.  And you put multiple cores on with their own clocks.  And that's because of the speed of light.  You could also drop the voltage.  So you can run at lower power because of that.  So in the future, we're going to see.  I mean, I've got, I'm experimenting with 64 core  low power processor at the moment.  Should see 1,024 core low power processors coming onto the  market in 2015.  And they're going to influence how we do things.  So we've got a change in the hardware.  And that will reflect in the change in the programming  language.  No programming languages have been explicitly designed with  distribution, multi-core, and low power in mind.  I haven't seen any languages that have been designed with  that in mind.  We're working on it.  So we'll see what happens, sir.  Right.  And when those change, the languages will change.  Right.  So what are the problems?  This lecture, what are the problems?  What are the laws of physics have to say about computation?  Can we get out of this mess we've got ourselves into?  Right.  So what are the problems?  Here's a few problems.  Legacy code, complexity, all this kind of stuff.  I'm going to talk about each of those in turn.  So legacy code.  This is great.  Legacy code is when all the programmers who wrote the  stuff are dead.  Right, that's legacy code.  And it's a pain in the ass.  There's no specific.  Have you ever seen a program that had a specification?  Well, I've seen a lot of programs, and I've seen a  lot of specifications.  And the two normally don't have anything to do with each  other.  They're kind of a vague description of what the program  might do on a good day.  They're written in archaic languages, which nobody  understands.  Right, that's great.  You want to be a maintenance programmer?  Here's half a million lines of COBOL.  Wow.  Cool.  That's just what I wanted to do.  You've got to change one line of it, but which line?  That's the problem.  Nobody understands how this stuff works.  And it works.  And then we've got business value.  We've got managers who say, well, this legacy code, this  million lines of stuff written in COBOL.Tran4 has  got commercial value.  It's got business value, so we can't touch it.  And to rewrite it, because the first time it was written,  took a million man hours or something to rewrite, it's  going to take 10 million man hours.  Of course, nobody knows what it does.  It might not.  Right.  So it might not.  So management thinks that modifying legacy code is  cheaper than a total rewrite.  They are nuts.  They're completely lunatics.  Sometimes it is.  If that legacy code is in good order, but often it's not.  Right.  So what you do is legacy code.  Don't touch it.  Put it in a virtual.  This is what you do.  You put the legacy code in virtual machine.  Don't mess with it.  So you've got all these little black boxes running legacy  code, which nobody knows what it does.  And it's just sitting there festering like a nasty  wart or something that will come and hit you one day.  Horrible stuff.  But it's created a lot of job opportunities.  So it's pretty good.  Complexity.  Complexity.  Right.  So I have to sort of remind myself of some numbers.  You can see a lot of numbers in this talk.  So the mass of the Earth, I used to be a physicist, the  mass of the Earth is six times 10 to the 27 grams.  And the Earth's got about 10 to the 50 atoms in it.  Just remember that number.  10 to the 50 is a nice number.  So we do a back of envelope calculation.  Here's my envelope.  And back of envelope.  So if we take 10 to the 50, 2 to the 167, and divide that by  32 and take the ceiling of that, that's six.  What does that say?  That says six 32-bit integers has what's that?  192 bits.  But the number of atoms on the planet is 2 to the 167.  So what does that say?  That says a C program with six integers has more possible  states than the number of atoms on the planet.  And don't ask about JavaScript.  What about JavaScript?  Well, three variables, actually, because they're  double precision.  So what does that mean?  Well, it means you need more than six unit tests.  If you've got six variables, or more than three unit tests,  if you've got JavaScript variables.  Just as an aside, my machine, little machine here, has got  a 250 gigabyte solid state disk in it.  That means the number of possible states it can be in is  2 to the power of 250 billion times 8.  OK?  The total number of atoms, not in the planet, but in the  universe, the total number of atoms in the universe, is about  2 to the 260.  That means the complexity.  The number of states that my machine can be in divided by  the number of atoms in the universe is 2 to the 7 billion.  So I'd need 2 to the 7 billion universes filled with  computers.  And I might just find one that's in the same state as my  computer.  Right.  So this is why.  You know, I do things on my computer, and it doesn't work.  So I Google.  I say, blah, blah, blah, blah, blah, blah, blah, blah,  didn't work.  And I find a web person.  He says, oh, I have exactly the same problem as you.  Do this.  And there's lots of mails after.  I say, oh, gee, thanks.  That's absolutely great, because I had exactly the same  problem.  And I type this stuff in.  And guess what?  It doesn't work.  Shit.  So I Google again.  And I find I had exactly the same problem.  So I Google again.  And I do it.  And it doesn't work.  Why is that?  Well, because his machine, when he did these commands, or  she did these commands, is not the same as my machine.  Its state is different.  In fact, the chance that it's the same is one in 2 to the  250, blah, blah, times 8.  Right.  And I would need to be very lucky in being one of these  universes of the 7 giga, 2 to the 7 giga universes, where the  guy has just happened to post in his machine was in the same  state as me.  Well, it's not going to happen.  And it happened surprisingly early.  Last week, no week before last at work, we got, my and my  colleague, we both got two brand new Apple Retina laptop  thingamijigs.  And they were factory new.  And they were installed.  And we were going to run the same software.  So we thought, we'll do the install together so that our  machines are in sync.  And after four hours, I typed some commands on my machine  and an install worked.  And he typed the same commands on his machine.  And the install failed.  Right.  And we'd be up to that.  We'd been the same.  And then what do we do?  Well, he started googling, oh, how the hell I did it.  I didn't work trying doing that.  So they diverged after four hours.  Of course, they weren't the same to start with.  But you kind of think they're the same, don't you?  It's not true.  It's not true.  So what's the answer to all of this?  Well, scary math to the rescue.  The trouble is, scary math hasn't got there yet.  We don't have scary math to help us yet.  OK?  Because scary math is trying to prove things about the states  of these programs.  So the only way it can do it is prune the search space down  to something that's manageable and then look at that.  So you can't really prove things about programs of more than  two or three variables in.  So that's pretty tricky.  Well, sometimes, if they're specially constructed, you  can.  So we can't really look to scary math to help us yet.  It's coming along.  It takes a long time.  It takes like 100 years for somebody to get a good idea.  And then it takes.  I mean, look at the Lambda calculus.  Church had invented the Lambda calculus in 1930.  The type of Lambda calculus in 1936.  And I think it got into Java this year, didn't it?  Or last year or something.  I mean, it takes rather a long time.  And then nobody's had any ideas since church.  So there you go.  Failures.  What about failures?  Well, stuff fails.  Deal with it.  Stuff does actually fail.  Computers fail.  So there's only one way to handle failures.  Do it on another.  Joe's first theorem.  In order to handle failures, you need two computers.  Because if the whole computer crashes, you're screwed.  Sorry, at least two.  If you want to tolerate the failure of 100 computers,  you need 101.  Probability of them all failing at the same time  is 2 to the power of 101.  So it's low.  But still might all fail.  That means that you need to understand distributed computing  because you've got two computers.  You need to understand parallel computing  because they're running at the same time.  And you need to understand concurrent programming  because the programs in them are running at the same time.  So if you think you can do error handling or scalability  without understanding these three things,  it's not going to work.  Now, I'm not going to talk about that.  I've written three books about that  and made a programming language to embody some of those ideas.  And if you want to read more about that,  you can read some of those.  Right.  Means because systems break, because they're  becoming more complicated, we have to make them so that they  will self-configure and they will repair themselves  and they will evolve with time.  I think they'll be like us.  They'll gradually die.  And it's a very interesting problem, handling dying chips,  how they, I'm looking at that, multicores  where the cores start failing.  When we produce 1,000 core multicore chips,  half a dozen of the chips won't work.  And then as we run them, some of the cores will start failing.  And we need to live with that.  Don't want to throw them away because bits of them don't work.  Languages.  Language doesn't matter, they say.  Well, they should have told the Romans.  Do you do arithmetic like this?  No.  It's even worse.  You see, Romans didn't have a zero.  And they didn't have negative numbers.  For a lot of, do you know how old negative numbers are?  They're not very old.  They were about, I can't remember the date, 1,700 and something.  We need notations and things that are familiar and easy  to work with.  And if you're kind of in this mindset of programming  in with numerals like this and somebody else is using Arabic  numerals, you won't understand each other.  You say, well, it's a lot easier using Arabic.  No, no, no, no, no, no.  I'm perfectly happy with this.  I mean, I'm not talking about Jarbrun Haskell and things  like that.  I'm talking about Romans and things.  But there are analogies to be made there.  So 1985, everybody.  So there's a little star there.  Not absolutely everybody.  Everybody knew the born shell, make and see.  If there were sort of scientific, technical programmer  sort of type.  That meant they could talk to each other.  Programmers could talk to each other.  Well, now we can't talk to each other.  We don't have these common languages.  When you go to these big conferences,  there's these.NET people.  Any.NET people here?  Right.  Any JVM people here?  Right.  Oh, golly.  I've been to other conferences.  I say, any JVM people.  Oh, the hands go up.  And you say, any.NET people here?  Nobody.  And I'm a sort of neither a.NET or a JVM person.  So I don't really belong here.  I hope you won't eat me.  It's like talking to the light.  I've been thrown to the lions.  99% of the audience were.NET people.  Oh, my god.  What's.NET?  You think I'm joking?  I haven't actually got a window.  No, none of my friends have got a Windows machine.  I don't know what it is.  Well, I used one.  Well, that old thing, that had a Windows audience.  Yeah.  And so now what do we program for JVM.NET?  We program in Ruby, do before, Tran, and the bubble.  We can't talk to each other.  Right.  So we can't sort of send programs to each other.  We can't understand them.  So when I learned to program at Jews, I said this earlier,  I can choose three languages.  Now, first list I looked on, I looked on the Wikipedia.  And it said there were 776 languages.  Looked somewhere else, 2,500.  There's a lot anyway.  And then we have build tools.  Well, once upon a time, I said everybody talk to make.  Makes wonderful.  I love make.  And now there's Ant and Grunt and make, and Rake, and Malvin,  and Jake, and Bacon, and BitBake, and Fabric, and Paver,  and Shovel, and BitGrovel, and God knows what.  And what the hell these things are.  So I was researching this talk, and I looked up on Stack Overflow.  And somebody asked the question, is there  a rake equivalent in Python?  Yeah, well, this paver, invoke Shovel, WAF, and well,  that's really good.  That's what I like.  So a couple of months ago, I was writing this.  I actually do some programming for my living at Ericsson.  I was writing this program in Elling,  and it was going to go into a product.  I want to put it on the target.  And so the guy says, well, we've got this script that does it.  Just log in on this development system, and type make,  because it was a make file, actually.  Well, it evoked a bake file, no, a BitBake file, a bake recipe.  And it was taking a while.  I left it, and I went, oh, oh, oh, oh, oh, oh, oh.  18 hours later, it had downloaded 46,000 files,  which included the entire source code of the Linux kernel  and of GCC, compiled the whole bloody lot up,  and then built a single image, when then it cryptographically  signed it and done all this stuff.  And then I could take my three-module program  and put it on the target.  Well, of course, Elling was designed  to be object code compatible.  So you just move the files over anyway.  No, that's not possible.  We have to use BitGrum Tour.  I know you'll say you should have used Grunt,  and it would have been easy, but I don't know how  to build Grunt files.  I'm sorry.  This is not good, actually.  Right.  So without Google and Stack Overflow,  programming would be impossible.  I've shown these slides to somebody two days ago,  and he said, well, when the internet stops,  I can't program.  Why didn't they go?  It's really very good.  And I don't think, oh, shit, it doesn't work.  Oh, Google it is a very good programming paradigm.  In fact, I think programming is going to stop.  You see, if you plot, if I reckon the amount of time  I spend fixing stuff that's broken that shouldn't be broken,  corresponding to do real work where I'm just doing stuff,  the fixing stuff that's broken that shouldn't be broken  takes 30% to 40% of my time, and that is increasing with time.  So I think in 10 years' time, nobody  will be able to program anything you use that  will be broken in 10 years' time,  and you won't be able to program you.  You'll spend all your life in Google searching for,  well, why did my fucking program work?  Because I've done this, and it's supposed to work,  and it's not going to happen.  Right, good.  So efficiency, and I love efficiency.  You know, programming language designers,  they don't care about efficiency.  All the programming, like Dennis Ritchie and everybody  ever invented programming, don't think about efficiency.  Think about correctness.  Why is that?  Because programming language designers get blamed.  If a programmer writes a program and it crashes and kills  somebody, you see, it's their fault, it's not my fault.  You shouldn't have put it in your bloody language, right?  So I'm more concerned about correctness than efficiency.  So we have this sort of dichotomy between efficiency  and clarity.  So to make something clearer, you add a layer of abstraction.  And to make something more efficient,  you remove a layer of abstraction.  So you're always kind of dicing around  between these two alternatives.  And of course, in the last 30 years,  we have systematically chosen efficiency over clarity.  Well, that's great.  That's fantastic, because now we have  machines that are so frigging fast,  you can throw anything at them, and they do instantaneously,  if the code is correct.  Right.  So about 20 years ago, I was telling my bosses at Ericsson,  I was saying, look, this is stupid.  What we have to do is write our software as clearly  as possible.  And there's a few lines of code with as closer correspondence  as we can make it to the specification  and to the mathematics.  And then we'll be in a very good position in the future,  because as processes get faster, we'll just  be able to take this stuff.  And one day, it will be fast enough.  Right.  So it's really simple.  If you're in a program, you want to optimize it,  make it 1,000 times faster, just wait 10 years.  And it's really simple.  Alan goes a million times faster by waiting 20 years.  You just wait 10 years, it goes 1,000 times faster.  Who's in such a bloody hurry?  Why do we want it to be quick tomorrow?  We're making this legacy code now,  that if we don't fry the planet, and if we don't have  a nuclear war, and if we don't have a pandemi,  and if the nanorobots don't take over,  and if we're not hit by an asteroid,  and if there's not a supervolcano,  it's going to last for a bloody long time.  And you look back at this archaeological layer of crap  that was done in the beginning of computing.  And so why did they write it like that?  Why didn't they just write it efficiently?  Sorry, no, oh, sorry, clearly.  Hey?  And so what we see in the beginning of a technology  is companies compete by being incompatible with each other,  by being deliberately incompatible with each other.  So the early browser wars were a Microsoft browser  was deliberately incompatible with a Netscape browser.  After 10 years of that, people say, hey, that's bloody stupid.  Let's try and make them.  Let's not compete over browsers.  Let's try and make them compatible with each other.  So now we're into this.  OK, the browsers are largely, they all use WebKit,  and something like that.  So they are compatible.  So the wars are somewhere else.  So we've got some decent functional programming.  We've got Haskell, the LNG, things like that.  And then, OK, so let's not use them, Microsoft.  All there's some really good ideas in functional programming.  I know what we'll do.  We won't use them.  We'll invent our own language, F sharp.  That's nice.  That's great.  And then Apple comes along.  Oh, there's some really good ideas in functional programming.  I know what we'll do.  Let's not use them.  Let's invent our own one.  Why is that?  Why is Microsoft making F sharp?  Why is Apple making Swift?  To lock you in forever so that we can't talk to each other.  Now that will last for 10 to 15 years.  And then everybody will say, oh, this is a complete mess  because we've got all this legacy code which  can't talk to each other.  We've got the.NET world.  We've got the JVM world.  And you guys can't talk to each other.  But it becomes part of that legacy code  which has to be maintained for thousands of years  into the future.  It's not a good idea.  Contribute to the stuff.  Now is not the time to be inventing new functional languages  because that was done a while back.  That was done in the 80s.  So if Apple wanted to do something,  make a Cocoa Bridge to Haskell or to Erlang  so that we can really use Cocoa and the nice gooey stuff.  Don't make your own thing because you  don't have all the libraries.  You don't have all the stuff going.  Right, names.  How we do for time?  Golly.  I have to speed up.  Names.  Names.  We name things.  Names are imprecise.  Terribly difficult deciding on names.  Unique names.  I'm called Joe.  Any other Joes?  No.  So Joe's unique in this namespace.  But if it's a bigger namespace, there's lots of Joes.  I'll talk more about that later.  It's the root of all evil.  Right, now it's a sort of changed subject now.  This is light relief because I'm an ex-physicist.  What do the laws of physics have to say about computation?  Any other physicists?  Good, thank you.  Right.  So my interest in this was spiking.  I was reading the Elling-Manual pages.  And it said, the return reference will reoccur.  It's make a unique reference.  It said the return reference will reoccur after  approximately 2 to the 82 calls.  And therefore, it is unique enough for practical purposes.  I just wondered what this sentence meant.  Well, 2 to the 82, that's 10 to the 25.  Sometimes I use 2 to the, sometimes I use 10 to the.  What do these numbers mean?  Right.  So in this physics, I'm going to talk about causality.  Simultaneuity, entropy, speed, and computation,  storage capacity.  So causality to a physicist, a cause must proceed in an event.  We communicate through messages, some rays of light, sound.  You don't know about, you hear what I say a couple of milliseconds  after I've said it.  You see my arms waving about before you hear what I say.  Your brain sort of sorts that thing out.  You think it's simultaneously.  Information travels at or less than the speed of light.  You don't know how something is now.  You knew how it was the last time you talked to it.  So simultaneuity, this is basic sort of physics.  We've got two stars, A and B. In different parts  of the universe, and they explode at the same time.  They explode at the same time.  We've got three observers.  And they look at that.  Well, this guy over here, this bloke here,  he's nearer to A than B. So light to him gets there first.  So he says A exploded before B. And the guy to the far right,  he says, well, B exploded before A. And the guy is in between them.  He says, well, they happened at the same time.  So physicists gave up this idea of simultaneuity  for a long time ago.  Prior to, you know, I mean, as soon as you  realize that light traveled at a finite speed,  that this whole notion of simultaneuity  is vanished from physics.  You're not allowed to talk about simultaneuity.  So if you put it into sort of computer terms,  try and replicate data.  Suppose you've got a server A where you store something  and a server B where you keep a replica.  If you update X on A, you send X equals 10 to B  and it replicates it.  It sends an act back to A. Trouble is that B doesn't know  that A knows that the value is replicated,  because it doesn't know that the act signal has got there or not.  They can't make any assumptions about that.  So if B wished to know that A was replicated,  i.e. that it had the same value, because it doesn't know  that the act signal has got back there,  you'd have to send an act signal back from A to B.  But A doesn't know that the act signal has got back to B.  This is called the Byzantine general problem.  And it's a very simple impossibility proof  that when you've got data in two different places,  there is no physical law that can determine that.  They're the same.  You're violating the laws of physics, if you say they're the same.  What does that mean?  It means that two-phase commit doesn't work.  It actually means that three-phase commit doesn't work.  Well, it actually means that infinite-phase commit doesn't work.  So you can't have data in two places  and know that it's the same.  It's a law of physics, which we break a lot.  It's not a good idea breaking the laws of physics.  They're there for a good reason.  Entropy always increases.  Entropy is the amount of disorder in a system.  If you take a load of dice, you chuck them up in the air,  they're not all going to land with one up, or always six.  They're going to become more and more disordered.  This is the second law of thermodynamics.  Entropy always increases.  In software terms, it means systems become more disordered  all the time as you build them.  This is the law of physics.  Speed of computation.  This is quite fun.  Who are the geysers here?  That's a little quiz.  Who's this guy?  Sorry?  Yes, that's right.  Yes, that's Albert Einstein.  This is Hans Joachim Bremermann.  Who's this guy?  No?  Yes, Planck, Max Planck.  So Max Planck is kind of a phabric quantum mechanics.  One of his relationships is E equals H mu.  E's the energy of a black box radiator.  A black box radiator couldn't radiate in different frequencies.  And the energy in a particular frequency is Planck's constant times mu.  OK, so that's one of Planck's relationships.  Einstein said, well, E equals M. Everybody knows E equals Mc squared.  That's the amount of energy in a given mass.  So Mr. or Dr. Professor Bremermann said, well, if E equals H mu and E equals Mc squared,  then H mu is Mc squared.  Just knock out the E. And mu is M times C squared over H.  So C squared over H is called the Bremermann limit.  And it's 1.36 times 10 to the 50 hertz per kilogram.  OK, so that says that a 1 kilogram computer, a 1 kilogram of anything, it doesn't matter  what it is, a 1 kilogram of anything can oscillate at a max of 10 to the 50 cycles per second.  That's an upper limit on how fast an oscillator can run.  That's a clock frequency of a kilogram of stuff.  They can't go faster than that due to quantum mechanics.  Right.  So not only is there the Bremermann limit, there's Bremermann's limit, the Margolius-LeVintien  theorem, the Birkenstein bound, the Landau limit.  We all familiar with these.  So I'll just go through them very quickly because they tell us important things about  computing.  So the Bremermann limit, that says that the max clock rate of a 1 kilogram computer is  1.6 times 10 to the 50 hertz C. The Margolius-LeVintien theorem, that relates computation to energy.  We can do 10 to the 33 operations per second per joule.  The Birkenstein bound, that tells us how tightly we can pack information.  What is it?  10 to the 43 bits per meter times of, sorry, wait a minute, per mass and meter.  You take the mass of the thing and the radius of the sphere.  That's the maximum stuff.  And then the Landau limit, the minimum energy to change one bit of information.  And that's 2.85 zeta joules at 25 degrees.  I didn't know what a zeta, I had to look up what a zeta joule was.  It's 10 to the minus 21 of a joule.  There's another unit.  I just invented it.  It's FBDC.  It's a Facebook data center.  And that's 28 megawatts.  So Facebook data center is 28 times 10 to the 6 joules per second.  And the Landau limit is 10 to the minus 21 of a joule.  So you see this 27 orders of magnitude difference.  Of course, the Facebook data center is not just doing a one-bit operation.  It's doing lots of bits operation.  But you get some idea of that.  So let's build the ultimate laptop and see what that is.  Well, as you add more and more components, it gets hotter and hotter and the component  density gets greater and greater.  So the ultimate laptop is a black hole.  Of course, we squashed all this stuff into it.  And it runs at this Bremerhauer limit.  What was his name?  Bremermer.  I forgot the name.  So it's running at 10 to the 51 operations per second.  So you think, well, this is bloody useful.  I can do a lot in that.  But there's a problem.  It's pretty small.  It's 10 to the minus 27 of a meter big.  So you might drop it and not be able to find it.  It's got a storage capacity of 10 to the 16 bits.  And above all, it lives for 10 to the minus 21 of a second.  So yeah.  But it's done 10 to the 31 computations during that time.  And you might ask, how does it get out?  Black hole stuff goes into black holes.  You might have heard this.  Stuff falls into black holes.  But it can't get out.  Well, that's not true.  Stephen Hawkins found there's something called Hawkins Radiation that comes out of a black  hole when you drop stuff into it.  So if you take an elephant and you drop it into a black hole, you get an elephant's  worth of energy that comes out of the black hole.  But how does it come out?  Oh, there's a picture.  Nice picture from Scientific American.  What happens is outside the black hole, things are falling into the black hole.  They split into pairs.  Particles and antiparticles, say one of them drops into the black hole.  They're split pairs.  So their spins and things are equal and opposite.  And provided nobody measures them or does anything, you're fine.  When you change the spin or something of the thing inside the black hole and somebody measures  it outside, it instantaneously has this value.  It's called quantum entanglement.  Einstein called spooky action at a distance.  He didn't believe in it, actually.  So there's a kind of technical problem.  A, how to encode our program.  We drop it into a black hole and the answer instantaneously appears due to quantum entanglement  somewhere else in the universe.  These are technical problems which I leave to future programmers and physicists.  Not quite sure how to work it.  Oh, well, hang on.  That was the ultimate laptop.  What's the ultimate computer?  Well, that's the entire universe behaving as a black hole, right?  It's a black hole computer that's, you know, it's the ultimate computer.  So we could ask the question, how long, how many operations has the universe done since  it was booted?  So you boot the universe and you wait 10 to the 10 years about now.  And, well, it's done 10 to the 1, 2, 3 operations since then.  Okay?  This is as a quantum computer.  Its size is 2 to the 26, 2 times 10 to the 26 meters and it will live for 10 to the 10  to the 100.  Well, that's a Googleplex.  Nobody really knows.  It's like cool down and die, I suppose, I don't know.  So that's giving you some sort of, if the number of operations, the entire universe,  working as a quantum computer since it was created is, what did I say, 2 to the 409.  If you wanted to craft a crypto key that's, you know, by systematic search of all keys  and you've got a 512-bit key to just go through them all one at a time.  If you could go through them on one clock cycle, it would take 2 to the 103 universes  to do that.  It's actually cryptographers use measures from quantum mechanics to set the upper bounds  on the complexity of the algorithms.  So you don't actually need to, you don't need infinite length keys.  You just need to set them in relation to the size of the universe and then you're fine.  And yeah, okay.  So there's some paper-safe reader.  There's a very readable article in Scientific American about black hole computers from 2012.  Fun facts and figures.  Oh, this is wrong, I noticed.  One kilogram can do 10 to the 51, store 10 to the 31.  And I wrote it, it's a 10 giga gigahertz.  That's obviously not a giga gigahertz machine, it's a giga giga giga giga giga giga giga  giga giga giga giga giga.  Oh, I forget it.  I mean, it's fast.  It's faster than this thing, anyway.  A conventional computer can do 10 to the 9 operations per second if you compare it to  the black hole computer.  And the universe can store 10 to the 92 bits of information.  Multiply 92 times 3 is about 270.  So the number of bits in the universe is about 2 to the 2 to the 290.  So for a 290-bit checksum, you're about on par with the number of bits you can store in  the universe.  So SHA1 is 120 bits.  It's not enough if you want to store a checksum of everything in the universe.  It's probably good for the earth, so it may be all right.  I have to think about that.  Exercise.  So the number of bits should a checksum have to uniquely identify every atom on the planet.  Answers on the back of an envelope.  Right, it's a third bit.  Golly, I have to speed up.  So we created all this mess.  We've got the laws of physics.  What are we going to do about it?  Right, so I have a little proposal here.  We've got to break the laws of physics.  We can reverse entropy if you put energy into the system.  We've got to build the condenser.  The condenser should have made a better size like a meat machine.  You put all files into it and you turn the handle and less files come out.  So we condense.  You see, what we've been doing in the past is we've been expanding the amount of information.  Right.  So let's break this.  Just breaking the second law of thermodynamics.  We can do that if we put energy into the system.  That's fine.  Why did the number of files increase?  Well, you start off with files and you make more, you take a file and you edit it and  you do this and you do that.  That's entropy increasing.  Files mutate.  When you've got a file, well, disks are really huge.  Every time I buy a new computer, I just copy all the stuff I had on all my old computers  onto it.  Just a complete mess.  I can't find anything on it.  I mean, I've got 43,000 Erlang files on my machine.  I can't find anything in them.  Then you have a file.  You've got some data.  You say, well, I wonder what file name I should have.  Oh, okay.  I don't know.  I wonder what directory I should put it in.  Oh, I don't know.  I wonder which machine I should store.  I don't know.  And that problem gets worse and worse and worse as you have more and more files.  It gets far worse when the system becomes distributed.  Right.  So I want to declare the war on names.  You know, the war on terror.  There's a war on poverty.  We programmers, we should declare the war on names.  It's kind of been, you know, Git's quite good.  It's declared the war on names nicely.  So we shouldn't have any names.  So a few examples.  To talk about things, they need names.  We can't talk about something if we can't name it.  It's a basic philosophical fact.  Okay.  So here's a paragraph of text.  Cup of tea.  He sat down, cut a buttered slice of toast.  He tore away the burnt flesh and flung it to the cat and so on.  What's that from?  I know you'll use Google.  Any guesses?  James Joyce is from Ulysses.  Because that paragraph has no name, we can't talk about it.  So let's name it.  Well, it's not really a name.  Okay.  So there we go.  Just compute it's SHA1 checksum.  Right.  The name of that paragraph is 79.915.0AD.  So given that name, I can tell, that's not really a name, it's a hash.  Given that hash, I can tell anybody.  I'm talking about the paragraph.  Well, not about the paragraph.  I'm talking about 79.915.  Blup, blup, blup.  We've uniquely named this.  There's no ambiguity whatsoever.  Right.  So imagine, let's do away with these URIs.  They are evil.  They are silly idea.  Well, they're not a silly idea, but they're okay for a props emotion to the truth.  So look at this thing.  It's got two parts.  It's got a host name.  Use DNS to look the host name up and then it's got a resource name.  Well, DNS can be spoofed.  A naughty person can put a false thing into DNS or send you to the wrong DNS.  If the resource was changed, this reference is wrong.  It points to the, you know, that reference you found in a file or something, it points  to that.  But somebody changes that, what do we call it, ABC.  They change the content of C. You still got a reference to the old C.  You get the new C.  If you put a time to live or a caching in, you wouldn't know what time to put it in.  Suppose you put this in a cache and it says time to live for 10 minutes and the guy changes  it after five minutes.  You can't invalidate the cache or something like that.  There are all sorts of problems with this.  And the content can be changed by a man in the middle.  Bad guys can listen to this stuff and change the content.  So we don't want this at all.  So let's do it like this.  Instead of having a URI, we'll make a new type of thing.  We'll just say hash and there's the name.  Just go and get, notice there is no host name.  There's just the hash of the content.  The nice thing about this is, you say to this, go find this thing, go find this blob that  has this hash.  So no man in the middle can attack that thing because you get the blob back.  You compute the hash.  That is what you're asked for.  So no man in the middle can change this.  No man in the middle can attack this.  No DNS thing can spoof this.  If you get an answer, it's what you asked for.  It is completely safe.  It doesn't need any crypto keys to be exchanged.  It doesn't need to be protected from man in the middle attacks.  It doesn't need to do anything like that.  So then the question is, how do we find this thing?  Because we haven't said which host it's on.  Well, that's a well-solved problem.  So DNS usually works.  You've got two start addresses in your, okay.  So you have two start addresses in your machine.  And the answer is what you've got when you turn your machine off.  So when you boot your machine, you've got two start addresses in a cache.  A DNS1 and DNS2.  And you go and look at these two addresses.  In a peer-to-peer system, you've got a long list of machines that are known to participate  in a distributed hash table.  And what do you do?  Let's suppose I know about these machines here.  Here's the IP addresses of machines that are participating in a peer-to-peer distributed  hash table.  And what you do is you compute the SHA1 checksum of each of these IP addresses, and you sort  them all.  And you say, okay, I've got this resource.  I want to find something with this hash.  Where is 536852?  You look in this and say, well, it's somewhere these two machines here that I've highlighted.  They're the nearest machines in this space to this hash address.  So I go and ask them.  And they've got lists like that.  And they'll find the nearest ones.  And they'll go and ask them and so on.  Okay, so this is the basis of CORD and Catermelia and algorithms like that.  These are well-understood algorithms.  The Catermelia system's got something like 9 million machines.  It's actually invented by the file sharers who are using it to share movies and things  like that.  But it works great.  So we could put all information into this.  Right.  Instead of just having movies and things like that, just put all information into it.  Right.  So here's how to make...  So I'm going to make the condenser.  The first thing we want to do is find all identical files and then find all similar files and  reduce the amount of information on the Internet.  Well, finding all identical files on the Internet is trivial.  We compute the SHA1, check some of it, and we inject it into the hash table.  That's all we have to do.  You can do that in all the machines in the world.  Can run in parallel.  We could do this in a few hours and get rid of all the replicas.  Okay?  That's what Dropbox does, I think.  If you put stuff in there, it's got the same checks and without.  I don't need to keep multiple copies.  I just keep two or three copies.  Right.  So that's the finding all identical files bit.  Now we want to find all similar files.  Right.  Find the most similar file to a given file.  This is a tricky problem.  I've been thinking about this for ages.  Okay.  So the best algorithm I know, I'll just tell you the answer.  It's called least compression difference.  If two things are similar, then if you concatenate them and compress them, the size of the thing  will be, okay, so you've got the file here.  You compress it.  It's got a certain size.  If you took the file twice and compressed it, concatenate it and compressed it, the  file size of the compressed file would be only a little bit greater than the file size  because it's just describing the difference.  There is no difference.  So if you take a file, concatenate it to itself 100 times and compress it, it's about the  same size as the file compressed by itself.  It's very dissimilar.  Two files that are totally dissimilar.  Random numbers that are totally dissimilar.  If you compress A and you compress B and you compress A concatenate it to B, the size of  the totally dissimilar one will be more or less the size of the sum of both of these.  So this will find the most similar thing.  It's very insensitive to changes in the compression algorithm.  So I have a thing on my machine.  I type, when I've got information, I type it into a little box like Twitter.  I press the Sherlock button.  Sherlock Holmes, this little icon there.  I press Sherlock.  It does least compression difference on most of my files.  It takes a long time.  Then it says, hmm, do you know?  The most similar thing to that was something you did 15 years ago and it's in this file.  It finds it for me.  I want that to be on the entire internet.  I want us to put all the information we've got into the internet so that we reduce the  amount of information.  We reverse entropy and you just make it more manageable.  Okay.  Right.  This takes order of time n, where n is the number of files on the planet.  So it's not super quick.  So I'm just wondering if we can speed it up.  We have to reduce the search space.  I don't really know how to do that.  I'd like to talk to some researchers who know how to do that.  But there's a little hint there on, we certainly know things that couldn't be similar because  they're very different sizes.  The plagiarism detection algorithms, do you know how they work?  They work on a rolling check sum.  There are databases of open source software and of student essays that people do for the  feces.  What you do is you take the source code or you take the student fee.  You chop it into 50-byte blocks, say 50 bytes, and you compute a check sum, an MD5 or an  SHA1.  You stick that in a key value database.  Sorry, no, it's not an MD5.  It's called a rolling check sum.  I didn't mention what they're called.  A rolling check sum is one that you take 50 bytes, you compute the check sum, and if you  shift it by one byte, you can incrementally change the hash.  It's a typical one.  You XOR all these bits.  Simple one is XOR all the 50 bytes.  When you shift it by one byte, you XOR the final byte and XOR the beginning byte, and  now you've got the check sum of the next block.  That's called a rolling hash.  What you do is you take your data, split it into 50-byte blocks, compute the hash, the  rolling hash, stick them in a catamilia or a distributed hash table, and then you take  your 50-byte block, look it up in the hash table.  If it's in there, that line would possibly be the same.  Let me go and look at it and see if it actually was the same.  You can do that in linear time per docket.  It needs order of n lookups where n is the number of bytes in the file.  It's reasonable.  You could probably do that fairly quickly, I think.  Right.  Summary.  We made a mess.  Horrible mess.  Created millions and trillions of man hours of work.  In order to get out of this mess, we need to reverse entropy and start making things  simpler instead of making things more complicated.  Quantum mechanics sets the limits to the precision or the number of bits we need in  checksums and things like that.  We can dimension our systems accordingly.  We would love some mathematics to prove things.  I think we're going to have to wait a long time.  Yeah.  Well, join the war on names and help me build the condenser.  That's the next five years job.  Thank you very much.  So, any questions?  Yeah, where do I buy a quantum computer?  You can't.  And wouldn't a black hole computer be dangerous?  Possibly.  No questions, though.  Different problem.  Google it.  Get to work.
Joe_Armstrong_-_The_mess_we_re_in_0_2303.png Joe_Armstrong_-_The_mess_we_re_in_2304_2627.png Joe_Armstrong_-_The_mess_we_re_in_2628_2747.png Joe_Armstrong_-_The_mess_we_re_in_2748_2807.png Joe_Armstrong_-_The_mess_we_re_in_2808_2939.png Joe_Armstrong_-_The_mess_we_re_in_2940_3083.png Joe_Armstrong_-_The_mess_we_re_in_3084_3143.png Joe_Armstrong_-_The_mess_we_re_in_3144_3203.png Joe_Armstrong_-_The_mess_we_re_in_3204_3251.png Joe_Armstrong_-_The_mess_we_re_in_3252_3347.png Joe_Armstrong_-_The_mess_we_re_in_3348_3455.png Joe_Armstrong_-_The_mess_we_re_in_3456_8003.png Joe_Armstrong_-_The_mess_we_re_in_8004_9143.png Joe_Armstrong_-_The_mess_we_re_in_9144_14471.png Joe_Armstrong_-_The_mess_we_re_in_14472_14675.png Joe_Armstrong_-_The_mess_we_re_in_14676_16955.png Joe_Armstrong_-_The_mess_we_re_in_16956_17003.png Joe_Armstrong_-_The_mess_we_re_in_17004_17495.png Joe_Armstrong_-_The_mess_we_re_in_17496_18203.png Joe_Armstrong_-_The_mess_we_re_in_18204_18935.png Joe_Armstrong_-_The_mess_we_re_in_18936_19451.png Joe_Armstrong_-_The_mess_we_re_in_19452_19727.png Joe_Armstrong_-_The_mess_we_re_in_19728_23855.png Joe_Armstrong_-_The_mess_we_re_in_23856_25115.png Joe_Armstrong_-_The_mess_we_re_in_25116_25391.png Joe_Armstrong_-_The_mess_we_re_in_25392_26579.png Joe_Armstrong_-_The_mess_we_re_in_26580_26759.png Joe_Armstrong_-_The_mess_we_re_in_26760_27611.png Joe_Armstrong_-_The_mess_we_re_in_27612_28991.png Joe_Armstrong_-_The_mess_we_re_in_28992_29675.png Joe_Armstrong_-_The_mess_we_re_in_29676_31283.png Joe_Armstrong_-_The_mess_we_re_in_31284_32195.png Joe_Armstrong_-_The_mess_we_re_in_32196_32603.png Joe_Armstrong_-_The_mess_we_re_in_32604_35855.png Joe_Armstrong_-_The_mess_we_re_in_35856_37079.png Joe_Armstrong_-_The_mess_we_re_in_37080_42263.png Joe_Armstrong_-_The_mess_we_re_in_42264_43031.png Joe_Armstrong_-_The_mess_we_re_in_43032_43415.png Joe_Armstrong_-_The_mess_we_re_in_43416_44423.png Joe_Armstrong_-_The_mess_we_re_in_44424_45323.png Joe_Armstrong_-_The_mess_we_re_in_45324_46583.png Joe_Armstrong_-_The_mess_we_re_in_46584_48647.png Joe_Armstrong_-_The_mess_we_re_in_48648_49415.png Joe_Armstrong_-_The_mess_we_re_in_49416_52139.png Joe_Armstrong_-_The_mess_we_re_in_52140_52463.png Joe_Armstrong_-_The_mess_we_re_in_52464_53651.png Joe_Armstrong_-_The_mess_we_re_in_53652_54467.png Joe_Armstrong_-_The_mess_we_re_in_54468_56399.png Joe_Armstrong_-_The_mess_we_re_in_56400_57827.png Joe_Armstrong_-_The_mess_we_re_in_57828_60623.png Joe_Armstrong_-_The_mess_we_re_in_60624_62531.png Joe_Armstrong_-_The_mess_we_re_in_62532_62891.png Joe_Armstrong_-_The_mess_we_re_in_62892_63707.png Joe_Armstrong_-_The_mess_we_re_in_63708_64007.png Joe_Armstrong_-_The_mess_we_re_in_64008_65519.png Joe_Armstrong_-_The_mess_we_re_in_65520_66443.png Joe_Armstrong_-_The_mess_we_re_in_66444_67115.png Joe_Armstrong_-_The_mess_we_re_in_67116_69083.png Joe_Armstrong_-_The_mess_we_re_in_69084_70451.png Joe_Armstrong_-_The_mess_we_re_in_70452_72863.png Joe_Armstrong_-_The_mess_we_re_in_72864_73091.png Joe_Armstrong_-_The_mess_we_re_in_73092_74195.png Joe_Armstrong_-_The_mess_we_re_in_74196_79643.png Joe_Armstrong_-_The_mess_we_re_in_79644_81731.png Joe_Armstrong_-_The_mess_we_re_in_81732_81791.png Joe_Armstrong_-_The_mess_we_re_in_81792_81887.png Joe_Armstrong_-_The_mess_we_re_in_81888_81959.png Joe_Armstrong_-_The_mess_we_re_in_81960_82007.png Joe_Armstrong_-_The_mess_we_re_in_82008_82079.png Joe_Armstrong_-_The_mess_we_re_in_82080_82127.png Joe_Armstrong_-_The_mess_we_re_in_82128_82415.png Joe_Armstrong_-_The_mess_we_re_in_82416_82468.png