Functional Programming the Long Road to Enlightenment: a Historical and Personal Narrative
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
This talk outlines developments in programming from the beginning of programming (in 1948) to today. In particular I'll talk about the development of Erlang and about the trends in programming that lead to Erlang and what these trends mean for the future. Work on Erlang started in 1985, so we'll turn the clock back to 1985 and see what the world looked like then. C++, Java, Haskell, Javascript, Ruby, Python and Perl had yet to be invented. Most people believed, incorrectly as it turned out, that Ada and PL/1 would dominate the future. But I was more interested in Prolog and Smalltalk. Prolog was the answer, but I didn't know what the question was. I'll talk about how we grew a programming language, and what the main factors were in spreading the language. I'll relate my personal experience with Erlang to broader developments in programming and try to see how the two fit together. I'll also take a peep into the future and speculate about where computing is going.
 Hello. Can you hear me? Anybody hear me? Anybody not hear me? Put your hands up if you can't hear me. Yeah, I'm giving two talks here. So, I hope I'm giving the right talk. This is one about functional programming. I've sort of tried to interleave what I've done in functional programming with the history of what was happening at the time. So, I'm going to go back to about 1985 when I started doing this and kind of give it a historical perspective. I think when I started programming, there were only a few programming languages. I had to choose between Fortran and Assembler and Kobol. And now I think there's 2,500 programming languages to choose between. It's actually much easier to choose between three than 2,500. And of those, there's probably only about 30 or 40 that are worth using anyway. And that's tomorrow's lecture, how we got into this colossal mess and how we've totally fucked up all the software structures with far too many programming languages. And I'm one of the people who've been making programming languages, so I've kind of contributed to this. So, tomorrow I'll admit my sins and possibly think of, talk about some little ways of getting out of that. But that's tomorrow's lecture, not today's lecture. So, this lecture is all about, well, the title is Functional Programming the Long Load to Enlightenment. And I'm going to tell you about two things. I'm going to tell you a little bit about the history of functional programming. And I'm going to interleave that with my own personal involvement with that so you can kind of see where, how things fit in. And so, I'll run it along a sort of historical timeline. And that timeline starts back in, for my part, in about 1985. This slide actually, it's quite an old slide. I've used it quite a lot because it represents the world as it was in 1998 or 1999 when I gave an invited talk to the ICFP, International Conference on Functional Programming where I gave the history of airline. And it stops there for a reason, which I couldn't reveal at that conference. So, I shall reveal why it stops there and then what happened after that. So, I'm going to go back to 19, about 1985 when I, I used to be a physicist and I got a job at Ericsson in the computer science lab. And that was a newly started lab. And so, we were just kind of messing around with programming languages. So, here I am in 1995. I was a young lad of, you know, how old was I then, 30 or something, you know, with a glint in my eye and didn't know anything about programming. I used to be a physicist and I was without working as a computer scientist, which was quite fun. So, if you look, oh, sorry, just back off a little bit. If we look at the decades of programming, not many languages have really survived into the future. Some of them have took with them ideas and they've lasted forever. Others, others kind of died or they're still around because of legacy code, but they haven't influenced future languages. So, we have these decades of programming and in the, starting off in the 1950s, that was the first stage of programming languages like Lisbawg or Kobol, Mercury Auto Code, things like that came along. And what lived into the future was, I guess, the Fortran and the Kobol and the Lisb. Lisb was the progenitor of all the dynamic languages and Fortran was the progenitor of the statically typed imperative languages and so on. And then in the 60s, APL and PL1. PL1, of course, was at the time everybody said, well, PL1 is the language of the future. Everybody will be programming in PL1 and it wasn't the case. It wasn't the case. It didn't work out that way at all. 70s, basic, small talk, scheme, the born shell, C came along. Small talk, of course, the progenitor of the object-oriented languages. I mean, this was object-oriented done correctly. It was replaced by Java and C++ object-oriented done incorrectly. Small talk only got one thing wrong, was a concurrency model, but apart from that, it was a pretty decent language. And then, oh, wait a minute, I haven't got, well, it's a language which is survived today and still used. I should have put prolog in the list, which is 1972, but I don't think people use it today. It's highly influential and it's one of those nice languages that should have survived. But unfortunately, not many people use it. It has survived in niche domains like constraint logic programming, to schedule airlines and things like that. Basically, prolog is so good there aren't any problems that are worthy of its use. Robert Kowalski said that prolog was a solution in search of a problem, but there weren't any problems that were difficult enough for it. So people use Java and things like that instead. And then in the 90s, Haskell and a load of scripting languages came along. The real sort of Haskell type language came relatively late, they came in the 1990s. The logic programming languages came in the 70s, so actually 20 years ahead of the functional programming language. And I'm not talking about functional programming as an academic discipline, of course, with the church and the Lambda calculus from the 1930s, but nobody knew about that because he couldn't actually run any programs in the type of Lambda calculus in 1936 or something like that. And then in 2000, we've got C sharp and Scarlet and Go and 2010. I don't know which languages will survive from 2010, possibly Julia, which seems to be a very nice language. We'll have to look, have to give a lecture in 2030 to, probably won't be alive then. You'll have somebody here who will have to give a lecture in 2030. Right. So these are the kind of significant languages. I found this on the net somewhere and I sort of, somebody's just made a list. And I'm just looking at the dates when they came in. 1957, Fortran, first dynamic language, Lisp, 1960, first logic programming language prologue, or the arrow points wrongly, 1970, actually I said 72, it was 70 there. Small talk 80, actually, the small talk 72, which surprisingly was done in 1972. You could guess that from its name. And standard ML came in on 1984, Haskell 1990, we were talking about functional programming. Really there wasn't much functional programming before ML, I think, standard ML in 1984. Of course, although it came out in 1984, I didn't know about it in 1984. So when I started work, which was in 1985, what did I know about? Well, I knew about logic programming, I knew about prologue, and I knew about small talk. And of course, everybody knew about ADA and PL1 and the Algor family of languages. So I didn't actually realize I was a functional prologue, I was a closet functional programmer for five years, because I started off with prologue and small talk, kind of merged the two together to make a parallel programming, a parallel logic programming language. And that with time became more and more functional. So I sort of slowly sort of moved over to functional programming. Right. I just thought this was nice as well, because if you're functional programmers, there's a very nice talk by David Turner, which gives a history of the road to Haskell. And starts, of course, the Lambda calculus, or the typed Lambda calculus in 1936. These are from his lecture. Lisp came in 1960. Lisp is not actually an implementation of the Lambda calculus, because it turns out that McCarthy didn't actually know about the Lambda calculus at the time. It wasn't influenced by Church in the slightest. It was an independent invention. Then Algor 60, I swim, if you see what I mean, Peter Landon, one of his, he wrote this great paper, I think it's an 8, 800, was it 600 or 800? 800 programming languages, I believe. He had this I swim notation, which was the first, and then PAL and SASL. And in the late 1969 to 80, NPL, HOPE, and so on, came from Edinburgh. And by a strange coincidence, I had a job in Edinburgh, because I was a physicist and I'd just got a job working at Edinburgh. So I was fortunate enough to learn prologue from Robert Kowalski. The prologue was very early. And as a student there, we were all going like, well, Kowalski's either mad or he's a genius. We couldn't figure out which of the two it was, because we didn't really understand what he was talking about. And certainly years later, I've realized that he certainly wasn't mad. I mean, he was very smart. And then Rod Burstle did this new programming language, and then ML and then HOPE and then Miranda came out of that and then Haskell came out. And it's quite interesting, because I talked to David Turner about this, and he remembers coming to Ericsson, giving us a talk on SASL when I was doing Erlang, and we were exchanging ideas there. And we both remembered this. And we got on talking about types and dynamic types and static types, and I said, well, what do you think about types? And he said, oh, well, it doesn't really matter. So SASL was dynamically typed, Haskell was statically typed. It's not a religion. I mean, it's just a sort of practical thing. They're equally good, he said. And I thought, that's quite nice, because he was the father of the polymorphic statically typed languages, and yet he didn't really, he wasn't very religious about it. He's a very practical man. And then, OK, so that's functional programming. Logic programming. It actually came earlier, to Alan Colmarier and Philip Rosso, based on the work of Kowalski. Kowalski made a theorem proof of the horn clauses, which could be programmed in an efficient way, and out came logic, I mean, sequential logic, prologue. Because there was no time or anything like that, prologue turns out to be quite easy to parallelize. And so the first parallel programming languages came out in the early 80s, concurrent prologue, and parlogue, and KL1, flat GHC. These are languages that very much influenced AILANG, not in the syntax or anything like that, but in the implementation. Because when we were doing AILANG, we were looking to how parlogue had implemented and how KL1 was implemented to gain inspiration. This is all before I started work. This is prehistory. In 1982, something very significant happened. Japan started, the Minister of International Trade started an $850 million project to create a massively parallel computer based on prologue. This was a Japanese effort, and it came out in 1982. And this guy, Ed Wood Shapiro, as an American, went off to Japan, sent there, and he wrote a study, and he reported back, and he said, as part of Japan's effort to become a leader in the computer industry, the Institute for the New Generation Computer Technology has launched a revolutionary tenure plan for the development of large computer systems which will be applicable to knowledge information systems. This was the fifth generation. And that report didn't have much significance. I think it was largely until Fygenbaum wrote this book, The Fifth Generation, which came out, I think in, I can't remember the date, I think it was 83, something like that. Yeah, I think it was 83. This book caused a storm in America. And they said, the Japanese are going to build this thing, this massively powerful parallel computer that can do everything. And we have to do something about this. And so as a result of that, in the US, very quickly, they formed the strategic computing initiative with DARPA funding, which is going to fund it with $1 billion from 1983 to 1993. And one of the people in there wrote, the machine would run 10 billion instructions a second to see here, think like a human. You know, it was going to do real-time natural language translation and all these things. It was fantastic. Wow, this is great. Once we built this megalip prologue machine, I just put there, in 1987, they cut all the funding for this project because they weren't getting anywhere. And the project kind of fizzled out by 1987. But in 83, there was loads of money around. And in Britain, the Alvee project started, and they chucked in 350 million pounds to build a machine, it was a declarative machine to build Hope. Hope was a sort of, it'd come out of ML and new programming language from Edinburgh. It was called Hope Park Square, which is in Edinburgh. And the Department of Machine Intelligence and Artificial Intelligence were centered around Hope Park Square. And they were going to make this declarative architecture that would execute declarative, functional, and logic programs extremely quickly. And if you look at Hope, that's factorial function in Hope, looks like that. And you'll notice very similar to what factorial looks like in Haskell or Erlang or any of these programming languages. They all kind of date back from there. So that's a prehistory. And so then I arrive at Erickson in 1985. The projects haven't been cancelled because it's not yet up to 1987 where they realized none of this stuff was going to work and cut all the funding. And the funding is absolutely amazing. So it's really good. And everybody's rushing around going, what the hell, you know, prologue, prologue, let's build declarative machines and do all this stuff. So I sort of arrived there. And I learned prologue and I thought, wow, prologue, everybody's going to do everything in prologue in the future, if I thought. Turned out to be completely wrong, but that's what I thought at the time. So here we are in 1985. And at the time, everybody said, well, AIDA and PL1 are going to be the languages of the future. Everybody's going to be programming PL1 forever. How many of you are programming PL1? How many in AIDA? Oh, one person. Very good. Thank you very much. Yes, right. So I take with a pinch of salt. Somebody says, well, everybody's going to be programming in Java plus plus in the future or whatever they say. Because these things last a few years and then something better comes. Well, if something better doesn't come along with Sunk, because we need better stuff. In 1985, IBM was at its height. It had 450,000 employees worldwide. And it actually started syncing after that. Microsoft Windows was released in November. Machines had a few megabytes of memory. So this is 1985. It's a typical PC, typical, no, it wasn't a typical PC you could buy if you had lots of money. It's not the one you bought at home. It was one that bought for you at work. And it had a colossal 256 kilobytes of RAM. You could extend it up to three megabytes by adding a few expansion cards in. You needed a lot of, these are big cards you plug them in. And it had this blazingly fast 8 megahertz clock. And you could have a 20 or 10 megabyte hard disk. That's 1985, actually. So you have to ask yourself, you know, that thing in 1985 would boot in 120 seconds, process a day, 10,000 times faster, should boot in 12 milliseconds. But my machine doesn't boot in 12 milliseconds. So what the hell went wrong? I'll be talking about that in my lecture tomorrow, what the hell went wrong. Different subject. So using machines like this, I wanted to program this. This is a telephony, because I work for Ericsson, this is a telephony flow diagram. It shows three parallel processes. Time is proceeding down the screen and message passing is sent between them. It's a three communicating finite-step machines. And I want to find a convenient way to program that. So I wrote, right about 1985, I discovered Prolog and I started writing these things in Prolog. And I was trying to dig out the first version. I completely lost the first version. So the first version I could find is this documentation for version 1.06. And in the comments it says version 1.03 lost in the midst of time. So I haven't actually got anything that goes back beyond that. So that's the first ever thing that I could find. And yeah, so that's kind of around about 1986. I was actually developing a programming language. I didn't know I was doing developing a programming language at the time. If anybody had said that in 30 years time or 20 years time lots of people would be using it, I just said they were mad, because I didn't even know I was making a programming language. So having developed a programming language, the first significant thing that happened was we had the good fortune to come in contact with a group of people who wanted to use the technology we were developing. This is Shrestha Nerdling. And she had an application. She wanted to build something. Now I would recommend, you know, it's very good if you're making a new technology, get a user. You know, I mean, computer scientists will just invent stuff. If they're given nothing to do, computer scientists will just invent stuff, which is totally useless, right? Because they don't actually have any problems. Given no problems at all, they will invent their own problems and solve them. So you want a real human being of flesh and blood, somebody who isn't interested in programming, isn't interested in computer science and wants to build something, right? And then you cherish them. So this is Shrestha Nerdling. And what she wanted to do was program this thing. This is a telephone exchange. It's an MD 110. And she worked out a better way of programming these. These were programmed in a language called Plex. Plex was a, for its time, it comes from 1978. It was a very good programming language. It's probably the precursor of a lot of object-oriented programming languages. But it was proprietary. It was secret. Nobody knew anything about it. And for that reason, it never spread. But it had certain concepts in it, like blocks and signals, which have correspondences in languages like prologue. Sorry, not prologue. Small talk and language like that. Above all, it had memory protection between processes. So LLang's got a lot of things that came from Plex, actually. The memory protection in particular came from Plex. She wanted to program this thing. And she was a great fan of what she called fishbone diagrams. These are logic trees that are sheer decision trees. They haven't got no cycles in terms like that. She would write diagrams like this. That's a bit of a fishbone diagram. It's just a finite state machine with no cycles in it. But what you want to do is execute lots and lots of them in parallel. So you've got thousands of them running in parallel. So how do you run lots and lots of these in parallel? So that was the question I wanted to answer. Given a finite state machine, how do you do that? Well, one way of doing it is to run it and suspend it by putting it into a database and then when it wakes up, pull it out of the database. That's not a really good way of doing it. There are other ways of doing that. The way we hit upon or thought up was just to put this in a process. It's in memory. We need a very lightweight mechanism for doing this. So I wrote this in Prologue. And this was, oh, there we are, back again. That was, if you look at that diagram there, it turns out to be a bit of code that looked like that. That's Prologue, actually, because Prologue has in-fix operators. And so I could do that in Prologue. But Prologue is a sequential language. And so the way of implementing concurrency was you execute a sequential process. And then when it runs out of things to do, more or less run to completion. Actually run for a certain number of inferences or until it wants to receive a message and it has no such message. And then suspend it. Suspend it means putting it in a database. And then just a simple round-roll in scheduler. So I wrote that stuff. And then by 1988, this was delivered to Shestyn Oadling and her group. And they built a telephony exchange with it, a prototype of that. But it wasn't very quick. Here you can see I called a multiprocessor version. This is the first version that had parallel processes in. And as you can see, it took four days to, there was four days with total rewrite of the language. So I mean, that's just a smallish Prologue program. Maybe a couple of thousand lines of Prologue. You could rewrite it all in a few days. And it was pretty slow. It was doing 245 reductions a second. A reduction is just a function call. But it was fast enough to be able to prototype this telephone exchange that we wanted to build. For 1998, Ericsson took a decision to make a product based on that. We decided that we would have to speed up the implementation language. Far too slow. It had to be about 8,000 times faster to make it into a product. Then we needed documentation and all this other stuff. So we started two activities in parallel. One was the programming of the product, which we expected to take about two years. And the other was the speeding up of the virtual machine, which we also expected to take about two years. We thought they would converge and be fast enough. And we could do all this stuff. So in 1998, we started that project. We needed to develop courses. This is before PowerPoint. So it was just sort of hand drawn overheads on slides. I'm not a very good artist. But I had quite fun doing the slides. I think PowerPoint just sort of killed all creativity. This is a head and tail of a list. We needed documentation. You've got to have documentation. I wrote the complete documentation of the first airline system, which fit into one page, actually. So that's the first documentation. I mean, it's now 120,000 files of XML or something. It's a bit bigger than that. But that was good enough. And the users were very good. They didn't complain if you changed the language. If the next version of the language wasn't the same as the version they had the week before, they just happily swallowed that without complaining. So it's very good. And we had small machines. Remember I said that machine was pretty small. So stuff we didn't use, we removed. Nowadays, you've got whacking great big machines. All this crap that you should throw away. You don't have to throw it away because your machines are so big, you can swallow all the crap as well as the good stuff. But in those days, we had to throw away all the rubbish because space was limited. Right. That was the documentation. Performance. Performance was absolutely lousy. This is a sort of time plot up to the late 1984. It just shows the number of reductions per second and the technology we use to do that. And the green and red shows, green is experiments and red is production. If you put this stuff into production, and you'll see there that there's a gap. It's about a sort of you're in a half period when you mess around with an interpreter or an implementation technique and then you deploy it. And you've got these phasing in and coming out with different technologies. So the one killer reductions per second that was the interpreters. We did a failed experiment with strand of the logic programming language developed by Ian Foster based on KL1 and the Japanese fifth generation languages. And that's the first and last time I ever predicted how fast something would go before I had implemented it because we confidently told people how fast this thing would go before we'd implemented and measured and were completely wrong. So I've never done that since then. So all the project managers keep going, when will your program run? I don't know. How fast will it be? I don't know. And you just stone wall forever. If a project manager asks you when your software will be ready, just say, I don't know. I've never done it before. And never give in. Right. Because you always get into trouble. If you say it's going to take six weeks and it takes two years, you get into trouble. And even if you take six weeks and it takes two minutes, you're also getting into trouble. And you never know. So just say, don't know. Right. So that was the failed experiment. There was no production. And then there was a jam, the Joe's abstract machine based on the Warren abstract machine. And that was in production for quite a long time until it was replaced by a better machine. And here we get up to 1988. So this is, I don't know if you want to know how Aelang works. Anybody want to know how Aelang works? Briefly. Oh, jolly good. So this is how Aelang works. Each process has got a stack and a heap and some registers. And all of that fits into about 350 bytes. Okay. And it's preallocated. So we have preallocate, actually, I think we preallocate a kilobyte per process in that the stack and heap that grows together in a set of registers. I'll just look at it. This is how the jam worked, actually. Aelang's got terms, symbolic terms. Think of them as structs in C. So here's a struct containing a rectangle, an atom a rectangle. That's a symbol. And a couple of integers, 10 and 20. So in memory, that's represented as a tag pointer. Or was it? Yeah, it's still represented as a tag pointer. It's a tag that says, hey, I'm pointing to a tuple. That can be on the stack or heap. And there's an address. And at that point on the heap, in fact, for a tuple, it'll always be on the heap. It points to a tag pointer and says, hey, this a3, arity3, that says, I'm a struct with three things in it. And then there are three pointers. It says, hey, I'm an atom. And there's a pointer into an atom table. And then there's something that says, hey, I'm an immediate integer. And the value of 10 is in there. This is for a 32-bit or 64-bit machine. That's the memory organization. So if you wanted to build that tuple, you could say, push integer 20, push, stack and heap, you say, push integer 20, push integer 10, push atom rectangle, and make tuple 3. This is pretty much like the old Warren machine used to work. You're just moving things from the stack and heap with instructions. Okay. So when you've done all that, you're going to have something like that on, wait a moment, the built object, the tuple, you're going to have a tuple that points to something on the heap. That says, I'm a struct of three words long, and it says, I'm an atom, and here's the point. Everything's fully tagged, and it's just sitting on the heap. It doesn't take much space. And the code to do that, let's suppose we've got a function foo that returns a tuple 10 ABC. The complete code just says, well, enter foo, that's just a label that says, this is the start of the foo function. What are you going to do? Push atom ABC, push in 10, make tuple 2 and return. Now each of these things just becomes byte code. If I take those two instructions, push int 10 and make tuple 2, well, the push int 10 might be the byte code 16 because it's a byte code of machine, 10 is the immediate value. It's a push short integer instruction. 20 might mean make tuple, and the argument's 2. And then there's just a little C interpreter that just interprets that. So it's pretty simple. That's literally the compiler to do that just spits out byte code, the emulator just executes that. It's very much like the JVM, very much like the.NET virtual machine. The instructions in many instances pretty similar, actually. I mean, the push integer just sort of sticks an integer on the stack, but I can't really do anything else. So I wrote a compiler for that in Erlang itself, because we had one in Prolog, and then I wrote an emulator for that in Prolog again, and here it was, the jam. You can see from the handwriting it says I wanted to call it Joseph, Joseph's super Erlang programming. No, that didn't really fit. And then Joseph's engine, and it actually went at 3012. That was an Erlang reduction per second when it was interpreted. We could compile this into this byte code and execute it with, again, all in Prolog. That ran at 35. And we could compile it once a day when I went home and it would be ready the next morning so you could run it. But that was good enough. We ran through all the test bench suites and everything, and ran at 35. But the whole machine design was ready, and so Mike Williams then came along. Mike's my mate who knew C. I was writing this in C, and I had never written C before. I started writing it to speed it up. I had written Fortran before that. My first ever C program was C virtual machine to run Erlang. And Mike read it and said this is the worst program I have ever seen in my entire life. So he rewrote it. So now there were three. Robert had joined me about a year before. He's writing all the libraries. I write the compiler and Mike was writing the emulator. And we did that. And yeah, now it beatled along at, oh, about 100,000 reductions per second. It was really quite quick. Well, C is actually better than Prolog for implementing virtual machines. It's almost as if he's assembler. So it's pretty good. So here we are. We're at 1990. Yeah. And we've got this thing going. So what happens now? Show the movie. Oh, no, I won't show that. Hop over that. And we had great fun. This is the lab in 1992. We had to illustrate concurrency for people. Parallelism. So we thought, how do you do that? Well, we have a model train and a telephone exchange. And we'll control them from different parallel processes in the same virtual machine. So, and this was at a, this was the best, people who went on the Erlang course always remember this. Because the exercise, you put two trains on the tracks. There's one here. Can you see the mouse pointing to the left? And we put another train pointing to the right. And the programming exercise was to swap them. And there were little sensors that told you when. So there's really real time programming, actually. Great fun. And there's Robert. And we showed this at a trade fair together with the telephone. It was controlling the exchange at the same time. That was in 1992. So that was quite fun. And then what happened? Right. Well, nothing much happened then. 1992 to 1995, nothing much happened. We started Erlang user conferences and things. And that's one of the first ones. It was, at that time, it wasn't open source. It was limited to Ericsson. And we had one room with held 80 people. And that's the number of people who could come. And we had our yearly conference with great fun. Then one of the two things, two things have led to Erlang being a successful programming language. One of the first of these two things happened on the 8th of December 1995. A project called AXEN was cancelled. That was a big project. It was going to do everything in C++. It had been running for about six years. And a lot of programmers were involved in this. And it was cancelled. And it was, Ericsson had built the hardware and the software. And the software just didn't work. By coincidence, we were working in the same building as this project. So we knew all about it. And we'd also been itching to program their hardware. So we managed to get hold of the hardware after a lot of opposition. So we were programming the same application as they were programming. And we'd done it with six people. And they'd done it with about 800 people. And at the time, words were said and things. So we were very un-tactful in those days, I think, about the differences here. So we got a lot of enemies by mistake, which is coincidental. But anyway, they cancelled the AXEN project and decided to keep all the hardware and now do it in LN. Okay, because we could do that. So we started in LN group. And that started this OTP stuff. I moved from a lab into a production organization. We formed this OTP group. And I was technically responsible for this. And we started building this OTP system. And so in 1996, this project called AXD started. And stuff happened really, really quickly. We built up a group. We retrained 60 programmers, became LN programmers, and they programmed away. And off we went. And 1996 to 1998 not much happened. They were just kind of building their stuff. This is typical. You have these periods of stuff that happens really quickly. And then you have these long periods where nothing appears to happen. And then things happen really, really quickly. But in 1998, nothing much happened until we get to the end of the slide. That's the reason why the slide ends there. Because, well, I have to go back a bit, see why it ends here is, well, in 1998, the AXD is a tremendous success. It works stupendously well. And it's sold all over the place. And it was such a success that Ericsson banned it, banned Erlang. Right. And there were reasons for that. So I don't really want to go. Well, two of the reasons were it wasn't Java. And the second reason it wasn't C++. And Ericsson had taken some strategy decisions to only program in Java and C++. So it wasn't really that they didn't, it wasn't what it was that upset people. It was what it wasn't that upset people. So they decided to ban it. And that's why this slide stops there. Because I had to give a talk at ICFP about the same date after it had been banned. And so we were rather in this awkward position of saying, you know, going out there and saying, why are those great, you know, Ericsson's using it. We're doing all this wonderful stuff. I didn't really want to say it had been banned because that would sort of, you know, stifle any enthusiasm in the audience. You know, maybe I'll go and try it. And then they know that it's been banned. And so I just sort of forgot to tell them that, which was funny. So I met Vianna Sirstrup and he said, oh, C++ was banned 11 times, he said. So I thought, we've only been banned once, I think. It was, yeah, so we were banned. Now that was really bad news, actually. Well, at the time it was really bad news. I thought I couldn't sleep, I couldn't get ulcers, oh, dear, what are we going to do? So, well, what happened after that was quite fun because, for any moment, we were banned. So after it was banned, there was about a four-month period where the computer science lab people sort of went into a little huddle and went, what should we do, what should we do, what should we do? Well, we can't fight the technical director because he's a very big, big, powerful man. So I know we'll all quit. We said, start a company. We want to use Erlang, right. So then Erlang, after four months, became open source through a mechanism that still amazes me that we actually managed to persuade the Erricks of management, well, if we're not going to use it, release it as open source. And we managed to do that amazingly. I still don't understand how. And four days after it released as open source, we all left by a strange coincidence. And the matter, well, it turned out, you know, there's Dilbert Carty, venture capitalist, and just hand you money and stuff. Well, that was in the golden days of 1998. So four days later, we formed Blue Tail. And the Erricks and the Erlang development split into two groups. Basically, the people had been in the computer science lab. We all left and started a company. And the people inside Erricks had built the commercial product stuff. They went into flying under the radar mode. They didn't really want to annoy anybody. And so we keep changing the name so they wouldn't notice Erlang. It was quite good. Now, seriously, if your project is banned, change the name, okay? No, I'm serious. Years later, I was working in Erricks and then my boss came in and said, this project you're doing, do you want the good news or the bad news? What's the bad news? Well, the project you're working on has been cancelled. So what's the good news? We're starting a new project. Just change the name. It's taken six months to catch on. Right. It's a very good method. Right. So it's split into two. And so now I'm not actually in Erricks anymore. I'm now outside Erricks. And I haven't been watching carefully what's been going on. Haskell is now becoming pretty popular. Prologue has lost popularity totally. It's kind of sunk like a stone. It's niched into constraint logic programming. And interest in parallel machines has gone. There was a whole flurry of trying to make parallel architectures gone. Because every single project that tried to make a parallel machine failed. And every single research project that tried to parallelise legacy code failed. Failed managed to get a 15% speed up after massive efforts. I mean, people have been trying to parallelise as long as Fortran has been around and they've never got more than 15%. And everybody's arguing about dynamic and static typing and lazy evaluation and egress. We're all having great arguments. This is 1998. Right. In this period now from 1998 to 2014, this was the... BlueTale was formed in 2008. Things now are on the track to where we are today. After two years, BlueTale was acquired for $154 million, which was kind of nice because we had formed it and known stock in it. And it was quite fun. And a guy called Alexey Sheplin, I don't know if I'm pronouncing his name correctly, started building an XMPP server in Erlang using the Ukraine. BlueTale was acquired by Altium Web Systems. Altium Web Systems was acquired by Nortel Networks. Nortel Networks went bankrupt. Everybody got fired. And then out of the embers of these groups, then three companies formed. TailF formed out of the embers of the collapse of Nortel Networks. Clana was founded and these are founded in 2005. In 2006, we'll learn more about those later. 2006, Alexey Sheplin was awarded the Erlang user for the year. 2007, I wrote a book on Erlang because I hadn't written one for 14 years. Then things started, then the application started coming out. Facebook chat was suddenly announced. Two guys in Facebook had written a chat server in Erlang. It was deployed now and it was running the chat services inside Facebook. 2008, this book that I had written about Erlang, that stimulated the Haskell people. Andrew Sullivan wrote this, suddenly O'Reilly said, why are we publishing books of our fucking small programming? And I've been saying for years, publish the stuff, get the books out so people can learn to do it. And the whole movement started building up then. 2009, WhatsApp was founded. Actually quite interestingly, because of a number of reasons. One was they were looking at the Facebook server at the time, the Facebook chat server and that seemed to be good. It was the highest performing XMPP server that you could make on the planet. XMPP server had captured more than, I think about, okay, so a company called Process One had taken this and were competing with a Java server. The Erlang server was not only faster than the Java server, I think it was about four times faster, but it was free. And the Java server cost money, so they had a product that was four times faster and free. So that swept the world. We had 60, 70% of the XMPP market. XMPP is this instant messaging protocol, XML-based protocol that's used in, corporations tend to use it more and they're open Java servers, for example, for using XMPP. That server was the basis of the Facebook chat engine. And so at that time, oh, and there was now one or two books, I'd written my book and my good friend Francesco Cisarini and Simon Thompson. Francesco was a master's student that I supervised at Ericsson and he went on to form Erlang solutions. He subsequently wrote programming Erlang. I can never remember which is which. The O'Reilly book. And so the WhatsApp people said, whoa, okay, so we're going to build this application and they started building it in Erlang with 10 engineers in 2009. Same year as the Erlang books came out and then a load of more books came out. And then in 2014, of course, WhatsApp was acquired for $19 billion by Facebook, which is ironic really because by then they had dropped Facebook chat and re-implemented it in Java plus plus or something. And the reason for that was they said they couldn't get any, you know, the Erlang stuff didn't fit into their infrastructure. So what they had built themselves with their own engineers, they then bought later for $19 billion from somebody else to buy not only the technology but the user base, which I think is interesting to say the least. So there we go. So if you look back at this, you'll see in this time scale, when you're developing a technology, it seems to go in sort of periods of sort of, there's a gap about three to five years before you sort of rush into this new area that we're going to use this new technology. We get all excited and you start a project, you start a company or something like that. And then nothing seems to happen because you've got to do three to five years work before there's a result. And then they pop out three to five years upstream and then there's a massive flurry of attention. So Erlang's gone like that for the last, we keep on going like, oh, nothing's happening, nobody's using it. And then suddenly you all start tweeting, hey, WhatsApp's been sold for the largest acquisition ever and it's all programmed in Erlang. Oh, that's cool. And then so the Erlang user conference in San Francisco suddenly, it was quite funny, they had parallel sessions but the WhatsApp guys were talking about how they built WhatsApp application in Erlang and there were some parallel sessions. But not many people went to the parallel sessions. In fact, no people at all went to the parallel sessions and I think the schedule in the smallest room or something. It was a great room change at the last moment. Anyway, so how it spread has actually been rather like the spread of publishing, printing from the Gutenberg, did the first printing press. There was a 14-year delay. It took seven years to be an apprentice and once you'd been an apprentice after seven years, you had to work for your master or whatever it was called, for a seven-year period and then you could go and start your own company. About every 14 years, it was a doubling. What we've seen in the Erlang development is actually the sort of Erlang DNA started in the computer science lab. It stayed there for quite a long time. It split into, it split into BlueTale, this is outside Ericsson by the way, it split into BlueTale. BlueTale lasted three or four years. It split into TailF and Clana. This is a sort of genetic material. Clana is a banking, online banking place in Sweden that is the hottest IT banking startup in Sweden, now employs about, I don't know, lots and lots of people. It was expanding. It's all written in Erlang, the front end, back end written in Java and things like that. TailF they do net comps and sold into Cisco and places like that. Then Erlang solutions sort of split off and does consulting. They cross-owned BASCHO which is done React database and TriFort. BASCHO is done React database which found itself all over the place. There are other things outside that consortium. CouchDB, for example, is quite a few databases written in Erlang. CouchDB is written in Erlang and was chosen by CERN for the Large Hadron experiment and helped discover the Higgs boson. Erlang helped discover the Higgs boson which is quite nice because I'm an ex-physicist. Where have we got to? Oh, yes, technical. In the same period as these companies and things were going on, I think we've come back full circle now to looking at parallelism again because the thing that Erlang is kind of pretty suited for, which gave it a boost in 2004, 2005 was how to handle concurrency because the multi-core computers came along. In 2007, Intel made, I think it's called a Phoenix, I can't remember the name Phoenix or something, an 80-core network on chip architecture which did 1.1 teraflops at 62 watts. That's totally amazing performance. 2007, Ty Lira came out with the Ty L64 and I managed to get hold of the first production batches of those things and we took it into the lab and ported Erlang to it. We took one, we had a telephony application, we ported it to the Ty L64 without doing it. It ran 33 times faster. Just the first time. Didn't do anything to the code at all and we're very pleased about that. We showed it to the management and they said, why doesn't it go 64 times faster? We said, who's he? I don't know. I wanted it to go 64 times faster. I'm looking at adaptive as made this parallel board. I think these network on chip architectures are really, in 2015 we'll probably see 1,024 cores commercially available running at about 15 watts. These are supercomputers on a single chip and I think the key to the future is actually low energy. The people making the chips say these are high performance chips but nobody can think of applications that need that performance unless we simulate that and unless we do whole brain simulations and things like that that need massive computing power. There are very few problems that need that amount of computing power. On the other hand, we do need low energy computation and low energy computation can be achieved by massive parallelization and by dropping clock frequencies. There's a new generation of processors which become highly parallel with very low clock frequencies which have different funny cache behaviors and learning to take code or learning to program those is essential for generating low energy applications. I think that's very interesting. The modeling programming model actually fits into that quite nicely because caching is extremely important there. All Elling processors just have their own little cache and heap. Having written it with processors you've already ensured that those processors are cached. They can't look at anybody else's memory or anything like that. I think it's well placed for that. Just a few observations. The predictions that people were making in 1985 were almost completely wrong. The predictions as to which languages would be used in the future turned out to be completely wrong. Predictions about use of legacy code turned out to be completely wrong. I remember quite clearly when I worked for Ericsson talking to the head of strategy and he said, in the future everybody will be programming Plex because that was the language that we programmed in. I said, no, we won't. He said, yes, we will. It's company strategy. New products will be programmed in Plex as we have always promised our customers backwards compatibility with Plex. I said, no, no, it won't happen. 20 years time, not a single line of Plex will be written. I was right. We don't write any Plex at all. Zero, squelch, zero. The only Plex we've done, we've bunged into virtual machines. We don't dare change a single line of code because we will introduce 2.5 errors for every line of code we change. We put them in a virtual machine and nobody knows what they do. Hopefully one day we will chuck them away in the bin because it's rubbish. It's not rubbish, but it works. Nobody knows why it works. That's my lecture tomorrow. People who wrote the stuff are dead and there's no spec. Right. It's tricky. The most significant events that led to sort of alien escaping and things were totally unplanned and were non-technical in nature. They were things like being banned. They're things like projects failing and running in when they fail. All this good argument just never worked ever. Well, it did. You sort of do it. You know this engineer stuff? What's the problem? List the sort of 10 best solutions, take three of them, study them and build prototypes and then go to the management with the results of the best prototype and they'll go and do that. That doesn't work at all. Wait for a crisis and run in quickly. That's what you should do. Look for projects that are going to fail. That's a good tip. When all else fail, when they're drowning, when all else fails, save me. They rush in. That's the time to do it. Some predictions of future technology were correct. I remember some old blucks saying go parallel young man. The future is parallel. We said that in about 1980, mid-80s and it's completely correct. That's where the future is, parallel computing. We're going into this transition period of trying to learn how to program parallel computers. We're in this, I noticed a couple of days ago Apple released this Swift parallel functional programming language. They were like, oh, it's great. Apple joined this functional programming band wagon. Yeah, they have. Instead of climbing on board with the Haskell people and making a Cocoa Bridge that's good, they make their own one and they will gain market share due to that. In 15 years time, we'll be cursing them because they'll have all this legacy code that nobody knows how it works and will have changed language yet again. Can't they just join forces, please? Join the Haskell people or join the LN people, join the ML people. Don't make your own mistakes. Benefit from the previous mistakes that we've made. Yeah, these large legacy systems we built would be totally collapsed and are not used. I think while I talk about this tomorrow, management has this weird view that fixing up legacy code is, well, we've got all these millions of lines of code and you want to rewrite it all. Yes. It's going to be quicker. No, yes. They don't do it. So the new startups that do build, they don't take the legacy code. They just build it from scratch in the best technology of the day. Some of those are going to win. We'll go to Darwin-type survival of the fittest will happen. Software has hit complexity boundaries years ago and is in a complete mess. Functional programming offers some slight improvement on that. It's not proof. It's less things that you can shoot. Strong-type systems, things like that provide you with less ways to blow your foot off by mistake. Tomorrow's lecture, I'll keep saying three 32-bit integers in C have more possible states than the number of atoms on the planet. This machine, this is 250 gigabyte solid state disk. The number of states this machine can be in is two to the power of 250 giga. That is more than the total number of states in the universe. So when I've got a problem on my computer and say, well, I've got the same problem, I tried this and it worked, it doesn't work, that's because our machine is in a different state to start with. We need mathematics, we need strong tools to prove systems correct and we don't know how to do that. We need to compose systems from small bits where we tried to prove the systems correct and we need to build them together and we don't know how to do this. My generation of programmers in the last 30 years has created trillions of years of mess that you guys are going to have to clean up and I'll talk about that tomorrow. So I think that's about what I wanted to say. So thank you very much. Questions? What? Oh, sorry, yes. The question was, strings are just lists of characters. Why? Well, because that's the correct way to do it. No, I mean a string, well, in Erlang, a string is just a list of integers where the integers are code points and they can be unicode code points or Latin one code points or whatever you want. But there's no notion of a UTF-8 string or any particular encoding there. They're just syntactic strings don't exist. Okay, basically. They're syntactic sugar for these things with quotes around them. You see, it's just an internal representation of this literal that's got quotes around it. That's what you call a string. They don't actually exist. They're not like integers. Yes? Well, I had included, oh, well, I had list on my list. Oh, well, the list of functional languages, that was the evolution of Haskell. So, Lisp didn't play any role in the evolution of Haskell. But, yeah, okay, yes. Sure. No, no, no, no. Well, that thing I showed was an excerpt from David Turner's paper and it's what he wrote in his paper and he didn't include Lisp in that chain of history, as it were. Right. More questions? No. Okay. Thank you very much.
 Hello. Can you hear me? Anybody hear me? Anybody not hear me? Put your hands up if you can't  hear me. Yeah, I'm giving two talks here. So, I hope I'm giving the right talk. This  is one about functional programming. I've sort of tried to interleave what I've done  in functional programming with the history of what was happening at the time. So, I'm  going to go back to about 1985 when I started doing this and kind of give it a historical  perspective. I think when I started programming, there were only a few programming languages.  I had to choose between Fortran and Assembler and Kobol. And now I think there's 2,500 programming  languages to choose between. It's actually much easier to choose between three than 2,500.  And of those, there's probably only about 30 or 40 that are worth using anyway. And that's  tomorrow's lecture, how we got into this colossal mess and how we've totally fucked up all  the software structures with far too many programming languages. And I'm one of the  people who've been making programming languages, so I've kind of contributed to this. So,  tomorrow I'll admit my sins and possibly think of, talk about some little ways of getting  out of that. But that's tomorrow's lecture, not today's lecture. So, this lecture is all  about, well, the title is Functional Programming the Long Load to Enlightenment. And I'm going  to tell you about two things. I'm going to tell you a little bit about the history of  functional programming. And I'm going to interleave that with my own personal involvement with  that so you can kind of see where, how things fit in. And so, I'll run it along a sort of  historical timeline. And that timeline starts back in, for my part, in about 1985. This slide  actually, it's quite an old slide. I've used it quite a lot because it represents the world  as it was in 1998 or 1999 when I gave an invited talk to the ICFP, International Conference  on Functional Programming where I gave the history of airline. And it stops there for  a reason, which I couldn't reveal at that conference. So, I shall reveal why it stops  there and then what happened after that. So, I'm going to go back to 19, about 1985 when  I, I used to be a physicist and I got a job at Ericsson in the computer science lab. And  that was a newly started lab. And so, we were just kind of messing around with programming  languages. So, here I am in 1995. I was a young lad of, you know, how old was I then,  30 or something, you know, with a glint in my eye and didn't know anything about programming.  I used to be a physicist and I was without working as a computer scientist, which was  quite fun. So, if you look, oh, sorry, just back off a little bit. If we look at the decades  of programming, not many languages have really survived into the future. Some of them have  took with them ideas and they've lasted forever. Others, others kind of died or they're still  around because of legacy code, but they haven't influenced future languages. So, we have these  decades of programming and in the, starting off in the 1950s, that was the first stage  of programming languages like Lisbawg or Kobol, Mercury Auto Code, things like that came along.  And what lived into the future was, I guess, the Fortran and the Kobol and the Lisb. Lisb  was the progenitor of all the dynamic languages and Fortran was the progenitor of the statically  typed imperative languages and so on. And then in the 60s, APL and PL1. PL1, of course,  was at the time everybody said, well, PL1 is the language of the future. Everybody will  be programming in PL1 and it wasn't the case. It wasn't the case. It didn't work out that  way at all. 70s, basic, small talk, scheme, the born shell, C came along. Small talk,  of course, the progenitor of the object-oriented languages. I mean, this was object-oriented  done correctly. It was replaced by Java and C++ object-oriented done incorrectly. Small  talk only got one thing wrong, was a concurrency model, but apart from that, it was a pretty  decent language. And then, oh, wait a minute, I haven't got, well, it's a language which  is survived today and still used. I should have put prolog in the list, which is 1972,  but I don't think people use it today. It's highly influential and it's one of those nice  languages that should have survived. But unfortunately, not many people use it. It has survived in  niche domains like constraint logic programming, to schedule airlines and things like that.  Basically, prolog is so good there aren't any problems that are worthy of its use. Robert  Kowalski said that prolog was a solution in search of a problem, but there weren't any  problems that were difficult enough for it. So people use Java and things like that instead.  And then in the 90s, Haskell and a load of scripting languages came along. The real sort  of Haskell type language came relatively late, they came in the 1990s. The logic programming  languages came in the 70s, so actually 20 years ahead of the functional programming language.  And I'm not talking about functional programming as an academic discipline, of course, with  the church and the Lambda calculus from the 1930s, but nobody knew about that because  he couldn't actually run any programs in the type of Lambda calculus in 1936 or something  like that. And then in 2000, we've got C sharp and Scarlet and Go and 2010. I don't know which  languages will survive from 2010, possibly Julia, which seems to be a very nice language.  We'll have to look, have to give a lecture in 2030 to, probably won't be alive then.  You'll have somebody here who will have to give a lecture in 2030. Right. So these are  the kind of significant languages. I found this on the net somewhere and I sort of, somebody's  just made a list. And I'm just looking at the dates when they came in. 1957, Fortran,  first dynamic language, Lisp, 1960, first logic programming language prologue, or the  arrow points wrongly, 1970, actually I said 72, it was 70 there. Small talk 80, actually,  the small talk 72, which surprisingly was done in 1972. You could guess that from its  name. And standard ML came in on 1984, Haskell 1990, we were talking about functional programming.  Really there wasn't much functional programming before ML, I think, standard ML in 1984. Of  course, although it came out in 1984, I didn't know about it in 1984. So when I started work,  which was in 1985, what did I know about? Well, I knew about logic programming, I knew  about prologue, and I knew about small talk. And of course, everybody knew about ADA and  PL1 and the Algor family of languages. So I didn't actually realize I was a functional  prologue, I was a closet functional programmer for five years, because I started off with  prologue and small talk, kind of merged the two together to make a parallel programming,  a parallel logic programming language. And that with time became more and more functional.  So I sort of slowly sort of moved over to functional programming. Right. I just thought  this was nice as well, because if you're functional programmers, there's a very nice talk by David  Turner, which gives a history of the road to Haskell. And starts, of course, the Lambda  calculus, or the typed Lambda calculus in 1936. These are from his lecture. Lisp came  in 1960. Lisp is not actually an implementation of the Lambda calculus, because it turns out  that McCarthy didn't actually know about the Lambda calculus at the time. It wasn't influenced  by Church in the slightest. It was an independent invention. Then Algor 60, I swim, if you see  what I mean, Peter Landon, one of his, he wrote this great paper, I think it's an 8,  800, was it 600 or 800? 800 programming languages, I believe. He had this I swim notation, which  was the first, and then PAL and SASL. And in the late 1969 to 80, NPL, HOPE, and so on,  came from Edinburgh. And by a strange coincidence, I had a job in Edinburgh, because I was a  physicist and I'd just got a job working at Edinburgh. So I was fortunate enough to learn  prologue from Robert Kowalski. The prologue was very early. And as a student there, we  were all going like, well, Kowalski's either mad or he's a genius. We couldn't figure  out which of the two it was, because we didn't really understand what he was talking about.  And certainly years later, I've realized that he certainly wasn't mad. I mean, he was very  smart. And then Rod Burstle did this new programming language, and then ML and then  HOPE and then Miranda came out of that and then Haskell came out. And it's quite interesting,  because I talked to David Turner about this, and he remembers coming to Ericsson, giving  us a talk on SASL when I was doing Erlang, and we were exchanging ideas there. And we  both remembered this. And we got on talking about types and dynamic types and static types,  and I said, well, what do you think about types? And he said, oh, well, it doesn't really matter.  So SASL was dynamically typed, Haskell was statically typed. It's not a religion. I  mean, it's just a sort of practical thing. They're equally good, he said. And I thought,  that's quite nice, because he was the father of the polymorphic statically typed languages,  and yet he didn't really, he wasn't very religious about it. He's a very practical man.  And then, OK, so that's functional programming. Logic programming. It actually came earlier,  to Alan Colmarier and Philip Rosso, based on the work of Kowalski. Kowalski made a theorem  proof of the horn clauses, which could be programmed in an efficient way, and out came  logic, I mean, sequential logic, prologue. Because there was no time or anything like  that, prologue turns out to be quite easy to parallelize. And so the first parallel  programming languages came out in the early 80s, concurrent prologue, and parlogue, and  KL1, flat GHC. These are languages that very much influenced AILANG, not in the syntax  or anything like that, but in the implementation. Because when we were doing AILANG, we were  looking to how parlogue had implemented and how KL1 was implemented to gain inspiration.  This is all before I started work. This is prehistory. In 1982, something very significant  happened. Japan started, the Minister of International Trade started an $850 million  project to create a massively parallel computer based on prologue. This was a Japanese effort,  and it came out in 1982. And this guy, Ed Wood Shapiro, as an American, went off to Japan,  sent there, and he wrote a study, and he reported back, and he said, as part of Japan's effort  to become a leader in the computer industry, the Institute for the New Generation Computer  Technology has launched a revolutionary tenure plan for the development of large computer  systems which will be applicable to knowledge information systems. This was the fifth generation.  And that report didn't have much significance. I think it was largely until Fygenbaum wrote  this book, The Fifth Generation, which came out, I think in, I can't remember the date,  I think it was 83, something like that. Yeah, I think it was 83. This book caused a storm  in America. And they said, the Japanese are going to build this thing, this massively  powerful parallel computer that can do everything. And we have to do something about this. And  so as a result of that, in the US, very quickly, they formed the strategic computing initiative  with DARPA funding, which is going to fund it with $1 billion from 1983 to 1993. And one  of the people in there wrote, the machine would run 10 billion instructions a second  to see here, think like a human. You know, it was going to do real-time natural language  translation and all these things. It was fantastic. Wow, this is great. Once we built this megalip  prologue machine, I just put there, in 1987, they cut all the funding for this project  because they weren't getting anywhere. And the project kind of fizzled out by 1987. But  in 83, there was loads of money around. And in Britain, the Alvee project started, and  they chucked in 350 million pounds to build a machine, it was a declarative machine to  build Hope. Hope was a sort of, it'd come out of ML and new programming language from  Edinburgh. It was called Hope Park Square, which is in Edinburgh. And the Department  of Machine Intelligence and Artificial Intelligence were centered around Hope Park Square. And  they were going to make this declarative architecture that would execute declarative, functional,  and logic programs extremely quickly. And if you look at Hope, that's factorial function  in Hope, looks like that. And you'll notice very similar to what factorial looks like  in Haskell or Erlang or any of these programming languages. They all kind of date back from  there. So that's a prehistory. And so then I arrive at Erickson in 1985. The projects  haven't been cancelled because it's not yet up to 1987 where they realized none of this  stuff was going to work and cut all the funding. And the funding is absolutely amazing. So  it's really good. And everybody's rushing around going, what the hell, you know, prologue,  prologue, let's build declarative machines and do all this stuff. So I sort of arrived  there. And I learned prologue and I thought, wow, prologue, everybody's going to do everything  in prologue in the future, if I thought. Turned out to be completely wrong, but that's what  I thought at the time. So here we are in 1985. And at the time, everybody said, well, AIDA  and PL1 are going to be the languages of the future. Everybody's going to be programming  PL1 forever. How many of you are programming PL1? How many in AIDA? Oh, one person. Very  good. Thank you very much. Yes, right. So I take with a pinch of salt. Somebody says,  well, everybody's going to be programming in Java plus plus in the future or whatever  they say. Because these things last a few years and then something better comes. Well,  if something better doesn't come along with Sunk, because we need better stuff. In 1985,  IBM was at its height. It had 450,000 employees worldwide. And it actually started syncing  after that. Microsoft Windows was released in November. Machines had a few megabytes  of memory. So this is 1985. It's a typical PC, typical, no, it wasn't a typical PC you  could buy if you had lots of money. It's not the one you bought at home. It was one that  bought for you at work. And it had a colossal 256 kilobytes of RAM. You could extend it  up to three megabytes by adding a few expansion cards in. You needed a lot of, these are big  cards you plug them in. And it had this blazingly fast 8 megahertz clock. And you could have  a 20 or 10 megabyte hard disk. That's 1985, actually. So you have to ask yourself, you  know, that thing in 1985 would boot in 120 seconds, process a day, 10,000 times faster,  should boot in 12 milliseconds. But my machine doesn't boot in 12 milliseconds. So what the  hell went wrong? I'll be talking about that in my lecture tomorrow, what the hell went  wrong. Different subject. So using machines like this, I wanted to program this. This is  a telephony, because I work for Ericsson, this is a telephony flow diagram. It shows three  parallel processes. Time is proceeding down the screen and message passing is sent between  them. It's a three communicating finite-step machines. And I want to find a convenient  way to program that. So I wrote, right about 1985, I discovered Prolog and I started writing  these things in Prolog. And I was trying to dig out the first version. I completely lost  the first version. So the first version I could find is this documentation for version  1.06. And in the comments it says version 1.03 lost in the midst of time. So I haven't  actually got anything that goes back beyond that. So that's the first ever thing that  I could find. And yeah, so that's kind of around about 1986. I was actually developing  a programming language. I didn't know I was doing developing a programming language at  the time. If anybody had said that in 30 years time or 20 years time lots of people would  be using it, I just said they were mad, because I didn't even know I was making a programming  language. So having developed a programming language, the first significant thing that  happened was we had the good fortune to come in contact with a group of people who wanted  to use the technology we were developing. This is Shrestha Nerdling. And she had an application.  She wanted to build something. Now I would recommend, you know, it's very good if you're  making a new technology, get a user. You know, I mean, computer scientists will just invent  stuff. If they're given nothing to do, computer scientists will just invent stuff, which is  totally useless, right? Because they don't actually have any problems. Given no problems  at all, they will invent their own problems and solve them. So you want a real human being  of flesh and blood, somebody who isn't interested in programming, isn't interested in computer  science and wants to build something, right? And then you cherish them. So this is Shrestha  Nerdling. And what she wanted to do was program this thing. This is a telephone exchange.  It's an MD 110. And she worked out a better way of programming these. These were programmed  in a language called Plex. Plex was a, for its time, it comes from 1978. It was a very  good programming language. It's probably the precursor of a lot of object-oriented programming  languages. But it was proprietary. It was secret. Nobody knew anything about it. And  for that reason, it never spread. But it had certain concepts in it, like blocks and signals,  which have correspondences in languages like prologue. Sorry, not prologue. Small talk  and language like that. Above all, it had memory protection between processes. So LLang's  got a lot of things that came from Plex, actually. The memory protection in particular  came from Plex. She wanted to program this thing. And she was a great fan of what she  called fishbone diagrams. These are logic trees that are sheer decision trees. They  haven't got no cycles in terms like that. She would write diagrams like this. That's  a bit of a fishbone diagram. It's just a finite state machine with no cycles in it. But what  you want to do is execute lots and lots of them in parallel. So you've got thousands  of them running in parallel. So how do you run lots and lots of these in parallel? So  that was the question I wanted to answer. Given a finite state machine, how do you do  that? Well, one way of doing it is to run it and suspend it by putting it into a database  and then when it wakes up, pull it out of the database. That's not a really good way of  doing it. There are other ways of doing that. The way we hit upon or thought up was just  to put this in a process. It's in memory. We need a very lightweight mechanism for doing  this. So I wrote this in Prologue. And this was, oh, there we are, back again. That was,  if you look at that diagram there, it turns out to be a bit of code that looked like that.  That's Prologue, actually, because Prologue has in-fix operators. And so I could do that  in Prologue. But Prologue is a sequential language. And so the way of implementing concurrency  was you execute a sequential process. And then when it runs out of things to do, more  or less run to completion. Actually run for a certain number of inferences or until it  wants to receive a message and it has no such message. And then suspend it. Suspend it means  putting it in a database. And then just a simple round-roll in scheduler. So I wrote  that stuff. And then by 1988, this was delivered to Shestyn Oadling and her group. And they  built a telephony exchange with it, a prototype of that. But it wasn't very quick. Here you  can see I called a multiprocessor version. This is the first version that had parallel  processes in. And as you can see, it took four days to, there was four days with total  rewrite of the language. So I mean, that's just a smallish Prologue program. Maybe a  couple of thousand lines of Prologue. You could rewrite it all in a few days. And it  was pretty slow. It was doing 245 reductions a second. A reduction is just a function call.  But it was fast enough to be able to prototype this telephone exchange that we wanted to  build. For 1998, Ericsson took a decision to make a product based on that. We decided  that we would have to speed up the implementation language. Far too slow. It had to be about  8,000 times faster to make it into a product. Then we needed documentation and all this  other stuff. So we started two activities in parallel. One was the programming of the  product, which we expected to take about two years. And the other was the speeding up of  the virtual machine, which we also expected to take about two years. We thought they would  converge and be fast enough. And we could do all this stuff. So in 1998, we started  that project. We needed to develop courses. This is before PowerPoint. So it was just  sort of hand drawn overheads on slides. I'm not a very good artist. But I had quite fun  doing the slides. I think PowerPoint just sort of killed all creativity. This is a  head and tail of a list. We needed documentation. You've got to have documentation. I wrote  the complete documentation of the first airline system, which fit into one page, actually.  So that's the first documentation. I mean, it's now 120,000 files of XML or something.  It's a bit bigger than that. But that was good enough. And the users were very good.  They didn't complain if you changed the language. If the next version of the language wasn't  the same as the version they had the week before, they just happily swallowed that without  complaining. So it's very good. And we had small machines. Remember I said that machine  was pretty small. So stuff we didn't use, we removed. Nowadays, you've got whacking great  big machines. All this crap that you should throw away. You don't have to throw it away  because your machines are so big, you can swallow all the crap as well as the good stuff.  But in those days, we had to throw away all the rubbish because space was limited. Right.  That was the documentation. Performance. Performance was absolutely lousy. This is a sort of time  plot up to the late 1984. It just shows the number of reductions per second and the technology  we use to do that. And the green and red shows, green is experiments and red is production.  If you put this stuff into production, and you'll see there that there's a gap. It's  about a sort of you're in a half period when you mess around with an interpreter or an  implementation technique and then you deploy it. And you've got these phasing in and coming  out with different technologies. So the one killer reductions per second that was the  interpreters. We did a failed experiment with strand of the logic programming language developed  by Ian Foster based on KL1 and the Japanese fifth generation languages. And that's the  first and last time I ever predicted how fast something would go before I had implemented  it because we confidently told people how fast this thing would go before we'd implemented  and measured and were completely wrong. So I've never done that since then. So all the  project managers keep going, when will your program run? I don't know. How fast will it  be? I don't know. And you just stone wall forever. If a project manager asks you when  your software will be ready, just say, I don't know. I've never done it before. And never  give in. Right. Because you always get into trouble. If you say it's going to take six  weeks and it takes two years, you get into trouble. And even if you take six weeks and  it takes two minutes, you're also getting into trouble. And you never know. So just say,  don't know. Right. So that was the failed experiment. There was no production. And then there was  a jam, the Joe's abstract machine based on the Warren abstract machine. And that was  in production for quite a long time until it was replaced by a better machine. And here  we get up to 1988. So this is, I don't know if you want to know how Aelang works. Anybody  want to know how Aelang works? Briefly. Oh, jolly good. So this is how Aelang works. Each  process has got a stack and a heap and some registers. And all of that fits into about  350 bytes. Okay. And it's preallocated. So we have preallocate, actually, I think we  preallocate a kilobyte per process in that the stack and heap that grows together in  a set of registers. I'll just look at it. This is how the jam worked, actually. Aelang's  got terms, symbolic terms. Think of them as structs in C. So here's a struct containing  a rectangle, an atom a rectangle. That's a symbol. And a couple of integers, 10 and  20. So in memory, that's represented as a tag pointer. Or was it? Yeah, it's still  represented as a tag pointer. It's a tag that says, hey, I'm pointing to a tuple. That  can be on the stack or heap. And there's an address. And at that point on the heap, in  fact, for a tuple, it'll always be on the heap. It points to a tag pointer and says,  hey, this a3, arity3, that says, I'm a struct with three things in it. And then there are  three pointers. It says, hey, I'm an atom. And there's a pointer into an atom table.  And then there's something that says, hey, I'm an immediate integer. And the value of  10 is in there. This is for a 32-bit or 64-bit machine. That's the memory organization. So  if you wanted to build that tuple, you could say, push integer 20, push, stack and heap,  you say, push integer 20, push integer 10, push atom rectangle, and make tuple 3. This  is pretty much like the old Warren machine used to work. You're just moving things from  the stack and heap with instructions. Okay. So when you've done all that, you're going  to have something like that on, wait a moment, the built object, the tuple, you're going  to have a tuple that points to something on the heap. That says, I'm a struct of three  words long, and it says, I'm an atom, and here's the point. Everything's fully tagged,  and it's just sitting on the heap. It doesn't take much space. And the code to do that,  let's suppose we've got a function foo that returns a tuple 10 ABC. The complete code  just says, well, enter foo, that's just a label that says, this is the start of the  foo function. What are you going to do? Push atom ABC, push in 10, make tuple 2 and return.  Now each of these things just becomes byte code. If I take those two instructions, push  int 10 and make tuple 2, well, the push int 10 might be the byte code 16 because it's a  byte code of machine, 10 is the immediate value. It's a push short integer instruction. 20  might mean make tuple, and the argument's 2. And then there's just a little C interpreter  that just interprets that. So it's pretty simple. That's literally the compiler to do  that just spits out byte code, the emulator just executes that. It's very much like the  JVM, very much like the.NET virtual machine. The instructions in many instances pretty  similar, actually. I mean, the push integer just sort of sticks an integer on the stack,  but I can't really do anything else. So I wrote a compiler for that in Erlang itself,  because we had one in Prolog, and then I wrote an emulator for that in Prolog again, and  here it was, the jam. You can see from the handwriting it says I wanted to call it Joseph,  Joseph's super Erlang programming. No, that didn't really fit. And then Joseph's engine,  and it actually went at 3012. That was an Erlang reduction per second when it was interpreted.  We could compile this into this byte code and execute it with, again, all in Prolog.  That ran at 35. And we could compile it once a day when I went home and it would be ready  the next morning so you could run it. But that was good enough. We ran through all the test  bench suites and everything, and ran at 35. But the whole machine design was ready, and  so Mike Williams then came along. Mike's my mate who knew C. I was writing this in C,  and I had never written C before. I started writing it to speed it up. I had written Fortran  before that. My first ever C program was C virtual machine to run Erlang. And Mike read  it and said this is the worst program I have ever seen in my entire life. So he rewrote  it. So now there were three. Robert had joined me about a year before. He's writing all the  libraries. I write the compiler and Mike was writing the emulator. And we did that. And  yeah, now it beatled along at, oh, about 100,000 reductions per second. It was really quite  quick. Well, C is actually better than Prolog for implementing virtual machines. It's almost  as if he's assembler. So it's pretty good. So here we are. We're at 1990. Yeah. And we've  got this thing going. So what happens now? Show the movie. Oh, no, I won't show that.  Hop over that. And we had great fun. This is the lab in 1992. We had to illustrate concurrency  for people. Parallelism. So we thought, how do you do that? Well, we have a model train  and a telephone exchange. And we'll control them from different parallel processes in  the same virtual machine. So, and this was at a, this was the best, people who went on  the Erlang course always remember this. Because the exercise, you put two trains on the tracks.  There's one here. Can you see the mouse pointing to the left? And we put another train pointing  to the right. And the programming exercise was to swap them. And there were little sensors  that told you when. So there's really real time programming, actually. Great fun. And  there's Robert. And we showed this at a trade fair together with the telephone. It was controlling  the exchange at the same time. That was in 1992. So that was quite fun. And then what  happened? Right. Well, nothing much happened then. 1992 to 1995, nothing much happened.  We started Erlang user conferences and things. And that's one of the first ones. It was,  at that time, it wasn't open source. It was limited to Ericsson. And we had one room with  held 80 people. And that's the number of people who could come. And we had our yearly conference  with great fun. Then one of the two things, two things have led to Erlang being a successful  programming language. One of the first of these two things happened on the 8th of December  1995. A project called AXEN was cancelled. That was a big project. It was going to do  everything in C++. It had been running for about six years. And a lot of programmers  were involved in this. And it was cancelled. And it was, Ericsson had built the hardware  and the software. And the software just didn't work. By coincidence, we were working in the  same building as this project. So we knew all about it. And we'd also been itching to  program their hardware. So we managed to get hold of the hardware after a lot of opposition.  So we were programming the same application as they were programming. And we'd done it  with six people. And they'd done it with about 800 people. And at the time, words were said  and things. So we were very un-tactful in those days, I think, about the differences  here. So we got a lot of enemies by mistake, which is coincidental. But anyway, they cancelled  the AXEN project and decided to keep all the hardware and now do it in LN. Okay, because  we could do that. So we started in LN group. And that started this OTP stuff. I moved from  a lab into a production organization. We formed this OTP group. And I was technically responsible  for this. And we started building this OTP system. And so in 1996, this project called  AXD started. And stuff happened really, really quickly. We built up a group. We retrained  60 programmers, became LN programmers, and they programmed away. And off we went. And  1996 to 1998 not much happened. They were just kind of building their stuff. This is typical.  You have these periods of stuff that happens really quickly. And then you have these long  periods where nothing appears to happen. And then things happen really, really quickly.  But in 1998, nothing much happened until we get to the end of the slide. That's the reason  why the slide ends there. Because, well, I have to go back a bit, see why it ends here  is, well, in 1998, the AXD is a tremendous success. It works stupendously well. And it's  sold all over the place. And it was such a success that Ericsson banned it, banned Erlang.  Right. And there were reasons for that. So I don't really want to go. Well, two of the  reasons were it wasn't Java. And the second reason it wasn't C++. And Ericsson had taken  some strategy decisions to only program in Java and C++. So it wasn't really that they  didn't, it wasn't what it was that upset people. It was what it wasn't that upset people. So  they decided to ban it. And that's why this slide stops there. Because I had to give a  talk at ICFP about the same date after it had been banned. And so we were rather in this  awkward position of saying, you know, going out there and saying, why are those great,  you know, Ericsson's using it. We're doing all this wonderful stuff. I didn't really  want to say it had been banned because that would sort of, you know, stifle any enthusiasm  in the audience. You know, maybe I'll go and try it. And then they know that it's been  banned. And so I just sort of forgot to tell them that, which was funny. So I met Vianna  Sirstrup and he said, oh, C++ was banned 11 times, he said. So I thought, we've only  been banned once, I think. It was, yeah, so we were banned. Now that was really bad news,  actually. Well, at the time it was really bad news. I thought I couldn't sleep, I couldn't  get ulcers, oh, dear, what are we going to do? So, well, what happened after that was  quite fun because, for any moment, we were banned. So after it was banned, there was about  a four-month period where the computer science lab people sort of went into a little huddle  and went, what should we do, what should we do, what should we do? Well, we can't fight  the technical director because he's a very big, big, powerful man. So I know we'll all  quit. We said, start a company. We want to use Erlang, right. So then Erlang, after four  months, became open source through a mechanism that still amazes me that we actually managed  to persuade the Erricks of management, well, if we're not going to use it, release it as  open source. And we managed to do that amazingly. I still don't understand how. And four days  after it released as open source, we all left by a strange coincidence. And the matter,  well, it turned out, you know, there's Dilbert Carty, venture capitalist, and just hand you  money and stuff. Well, that was in the golden days of 1998. So four days later, we formed  Blue Tail. And the Erricks and the Erlang development split into two groups. Basically,  the people had been in the computer science lab. We all left and started a company. And  the people inside Erricks had built the commercial product stuff. They went into flying under  the radar mode. They didn't really want to annoy anybody. And so we keep changing the  name so they wouldn't notice Erlang. It was quite good. Now, seriously, if your project  is banned, change the name, okay? No, I'm serious. Years later, I was working in Erricks  and then my boss came in and said, this project you're doing, do you want the good news or  the bad news? What's the bad news? Well, the project you're working on has been cancelled.  So what's the good news? We're starting a new project. Just change the name. It's taken  six months to catch on. Right. It's a very good method. Right. So it's split into two.  And so now I'm not actually in Erricks anymore. I'm now outside Erricks. And I haven't been  watching carefully what's been going on. Haskell is now becoming pretty popular. Prologue has  lost popularity totally. It's kind of sunk like a stone. It's niched into constraint  logic programming. And interest in parallel machines has gone. There was a whole flurry  of trying to make parallel architectures gone. Because every single project that tried to  make a parallel machine failed. And every single research project that tried to parallelise  legacy code failed. Failed managed to get a 15% speed up after massive efforts. I mean,  people have been trying to parallelise as long as Fortran has been around and they've  never got more than 15%. And everybody's arguing about dynamic and static typing and  lazy evaluation and egress. We're all having great arguments. This is 1998. Right. In this  period now from 1998 to 2014, this was the... BlueTale was formed in 2008. Things now are  on the track to where we are today. After two years, BlueTale was acquired for $154  million, which was kind of nice because we had formed it and known stock in it. And it  was quite fun. And a guy called Alexey Sheplin, I don't know if I'm pronouncing his name correctly,  started building an XMPP server in Erlang using the Ukraine. BlueTale was acquired by  Altium Web Systems. Altium Web Systems was acquired by Nortel Networks. Nortel Networks  went bankrupt. Everybody got fired. And then out of the embers of these groups, then three  companies formed. TailF formed out of the embers of the collapse of Nortel Networks.  Clana was founded and these are founded in 2005. In 2006, we'll learn more about those  later. 2006, Alexey Sheplin was awarded the Erlang user for the year. 2007, I wrote a  book on Erlang because I hadn't written one for 14 years. Then things started, then the  application started coming out. Facebook chat was suddenly announced. Two guys in Facebook  had written a chat server in Erlang. It was deployed now and it was running the chat services  inside Facebook. 2008, this book that I had written about Erlang, that stimulated the  Haskell people. Andrew Sullivan wrote this, suddenly O'Reilly said, why are we publishing  books of our fucking small programming? And I've been saying for years, publish the stuff,  get the books out so people can learn to do it. And the whole movement started building  up then. 2009, WhatsApp was founded. Actually quite interestingly, because of a number of  reasons. One was they were looking at the Facebook server at the time, the Facebook chat server  and that seemed to be good. It was the highest performing XMPP server that you could make  on the planet. XMPP server had captured more than, I think about, okay, so a company called  Process One had taken this and were competing with a Java server. The Erlang server was  not only faster than the Java server, I think it was about four times faster, but it was  free. And the Java server cost money, so they had a product that was four times faster  and free. So that swept the world. We had 60, 70% of the XMPP market. XMPP is this instant  messaging protocol, XML-based protocol that's used in, corporations tend to use it more  and they're open Java servers, for example, for using XMPP. That server was the basis  of the Facebook chat engine. And so at that time, oh, and there was now one or two books,  I'd written my book and my good friend Francesco Cisarini and Simon Thompson. Francesco was  a master's student that I supervised at Ericsson and he went on to form Erlang solutions. He  subsequently wrote programming Erlang. I can never remember which is which. The O'Reilly  book. And so the WhatsApp people said, whoa, okay, so we're going to build this application  and they started building it in Erlang with 10 engineers in 2009. Same year as the Erlang  books came out and then a load of more books came out. And then in 2014, of course, WhatsApp  was acquired for $19 billion by Facebook, which is ironic really because by then they  had dropped Facebook chat and re-implemented it in Java plus plus or something. And the  reason for that was they said they couldn't get any, you know, the Erlang stuff didn't  fit into their infrastructure. So what they had built themselves with their own engineers,  they then bought later for $19 billion from somebody else to buy not only the technology  but the user base, which I think is interesting to say the least. So there we go. So if you  look back at this, you'll see in this time scale, when you're developing a technology,  it seems to go in sort of periods of sort of, there's a gap about three to five years  before you sort of rush into this new area that we're going to use this new technology.  We get all excited and you start a project, you start a company or something like that.  And then nothing seems to happen because you've got to do three to five years work before  there's a result. And then they pop out three to five years upstream and then there's a  massive flurry of attention. So Erlang's gone like that for the last, we keep on going  like, oh, nothing's happening, nobody's using it. And then suddenly you all start tweeting,  hey, WhatsApp's been sold for the largest acquisition ever and it's all programmed in  Erlang. Oh, that's cool. And then so the Erlang user conference in San Francisco suddenly,  it was quite funny, they had parallel sessions but the WhatsApp guys were talking about how  they built WhatsApp application in Erlang and there were some parallel sessions. But not  many people went to the parallel sessions. In fact, no people at all went to the parallel  sessions and I think the schedule in the smallest room or something. It was a great room change  at the last moment. Anyway, so how it spread has actually been rather like the spread of  publishing, printing from the Gutenberg, did the first printing press. There was a 14-year  delay. It took seven years to be an apprentice and once you'd been an apprentice after seven  years, you had to work for your master or whatever it was called, for a seven-year period and  then you could go and start your own company. About every 14 years, it was a doubling. What  we've seen in the Erlang development is actually the sort of Erlang DNA started in the computer  science lab. It stayed there for quite a long time. It split into, it split into BlueTale,  this is outside Ericsson by the way, it split into BlueTale. BlueTale lasted three or four  years. It split into TailF and Clana. This is a sort of genetic material. Clana is a  banking, online banking place in Sweden that is the hottest IT banking startup in Sweden,  now employs about, I don't know, lots and lots of people. It was expanding. It's all  written in Erlang, the front end, back end written in Java and things like that. TailF  they do net comps and sold into Cisco and places like that. Then Erlang solutions sort of split  off and does consulting. They cross-owned BASCHO which is done React database and TriFort.  BASCHO is done React database which found itself all over the place. There are other  things outside that consortium. CouchDB, for example, is quite a few databases written  in Erlang. CouchDB is written in Erlang and was chosen by CERN for the Large Hadron experiment  and helped discover the Higgs boson. Erlang helped discover the Higgs boson which is  quite nice because I'm an ex-physicist. Where have we got to? Oh, yes, technical. In the  same period as these companies and things were going on, I think we've come back full  circle now to looking at parallelism again because the thing that Erlang is kind of pretty  suited for, which gave it a boost in 2004, 2005 was how to handle concurrency because  the multi-core computers came along. In 2007, Intel made, I think it's called a Phoenix,  I can't remember the name Phoenix or something, an 80-core network on chip architecture which  did 1.1 teraflops at 62 watts. That's totally amazing performance. 2007, Ty Lira came out  with the Ty L64 and I managed to get hold of the first production batches of those things  and we took it into the lab and ported Erlang to it. We took one, we had a telephony application,  we ported it to the Ty L64 without doing it. It ran 33 times faster. Just the first time.  Didn't do anything to the code at all and we're very pleased about that. We showed it  to the management and they said, why doesn't it go 64 times faster? We said, who's he?  I don't know. I wanted it to go 64 times faster. I'm looking at adaptive as made this  parallel board. I think these network on chip architectures are really, in 2015 we'll  probably see 1,024 cores commercially available running at about 15 watts. These are supercomputers  on a single chip and I think the key to the future is actually low energy. The people  making the chips say these are high performance chips but nobody can think of applications  that need that performance unless we simulate that and unless we do whole brain simulations  and things like that that need massive computing power. There are very few problems that need  that amount of computing power. On the other hand, we do need low energy computation and  low energy computation can be achieved by massive parallelization and by dropping clock  frequencies. There's a new generation of processors which become highly parallel with  very low clock frequencies which have different funny cache behaviors and learning to take  code or learning to program those is essential for generating low energy applications. I  think that's very interesting. The modeling programming model actually fits into that  quite nicely because caching is extremely important there. All Elling processors just  have their own little cache and heap. Having written it with processors you've already  ensured that those processors are cached. They can't look at anybody else's memory or  anything like that. I think it's well placed for that. Just a few observations. The predictions  that people were making in 1985 were almost completely wrong. The predictions as to which  languages would be used in the future turned out to be completely wrong. Predictions about  use of legacy code turned out to be completely wrong. I remember quite clearly when I worked  for Ericsson talking to the head of strategy and he said, in the future everybody will  be programming Plex because that was the language that we programmed in. I said, no, we won't.  He said, yes, we will. It's company strategy. New products will be programmed in Plex as  we have always promised our customers backwards compatibility with Plex. I said, no, no, it  won't happen. 20 years time, not a single line of Plex will be written. I was right.  We don't write any Plex at all. Zero, squelch, zero. The only Plex we've done, we've bunged  into virtual machines. We don't dare change a single line of code because we will introduce  2.5 errors for every line of code we change. We put them in a virtual machine and nobody  knows what they do. Hopefully one day we will chuck them away in the bin because it's rubbish.  It's not rubbish, but it works. Nobody knows why it works. That's my lecture tomorrow. People  who wrote the stuff are dead and there's no spec. Right. It's tricky. The most significant  events that led to sort of alien escaping and things were totally unplanned and were  non-technical in nature. They were things like being banned. They're things like projects  failing and running in when they fail. All this good argument just never worked ever.  Well, it did. You sort of do it. You know this engineer stuff? What's the problem? List  the sort of 10 best solutions, take three of them, study them and build prototypes and  then go to the management with the results of the best prototype and they'll go and do  that. That doesn't work at all. Wait for a crisis and run in quickly. That's what you  should do. Look for projects that are going to fail. That's a good tip. When all else  fail, when they're drowning, when all else fails, save me. They rush in. That's the time  to do it. Some predictions of future technology were correct. I remember some old blucks saying  go parallel young man. The future is parallel. We said that in about 1980, mid-80s and it's  completely correct. That's where the future is, parallel computing. We're going into this  transition period of trying to learn how to program parallel computers. We're in this,  I noticed a couple of days ago Apple released this Swift parallel functional programming  language. They were like, oh, it's great. Apple joined this functional programming band  wagon. Yeah, they have. Instead of climbing on board with the Haskell people and making  a Cocoa Bridge that's good, they make their own one and they will gain market share due  to that. In 15 years time, we'll be cursing them because they'll have all this legacy  code that nobody knows how it works and will have changed language yet again. Can't they  just join forces, please? Join the Haskell people or join the LN people, join the ML  people. Don't make your own mistakes. Benefit from the previous mistakes that we've made.  Yeah, these large legacy systems we built would be totally collapsed and are not used.  I think while I talk about this tomorrow, management has this weird view that fixing  up legacy code is, well, we've got all these millions of lines of code and you want to  rewrite it all. Yes. It's going to be quicker. No, yes. They don't do it. So the new startups  that do build, they don't take the legacy code. They just build it from scratch in the  best technology of the day. Some of those are going to win. We'll go to Darwin-type  survival of the fittest will happen. Software has hit complexity boundaries years ago and  is in a complete mess. Functional programming offers some slight improvement on that. It's  not proof. It's less things that you can shoot. Strong-type systems, things like that provide  you with less ways to blow your foot off by mistake. Tomorrow's lecture, I'll keep saying  three 32-bit integers in C have more possible states than the number of atoms on the planet.  This machine, this is 250 gigabyte solid state disk. The number of states this machine  can be in is two to the power of 250 giga. That is more than the total number of states  in the universe. So when I've got a problem on my computer and say, well, I've got the  same problem, I tried this and it worked, it doesn't work, that's because our machine  is in a different state to start with. We need mathematics, we need strong tools to prove  systems correct and we don't know how to do that. We need to compose systems from small  bits where we tried to prove the systems correct and we need to build them together and we  don't know how to do this. My generation of programmers in the last 30 years has created  trillions of years of mess that you guys are going to have to clean up and I'll talk about  that tomorrow. So I think that's about what I wanted to say. So thank you very much.  Questions? What? Oh, sorry, yes.  The question was, strings are just lists of characters. Why? Well, because that's the  correct way to do it. No, I mean a string, well, in Erlang, a string is just a list of  integers where the integers are code points and they can be unicode code points or Latin  one code points or whatever you want. But there's no notion of a UTF-8 string or any  particular encoding there. They're just syntactic strings don't exist. Okay, basically. They're  syntactic sugar for these things with quotes around them. You see, it's just an internal  representation of this literal that's got quotes around it. That's what you call a string.  They don't actually exist. They're not like integers. Yes? Well, I had included, oh, well,  I had list on my list. Oh, well, the list of functional languages, that was the evolution  of Haskell. So, Lisp didn't play any role in the evolution of Haskell. But, yeah, okay,  yes. Sure. No, no, no, no. Well, that thing I showed was an excerpt from David Turner's  paper and it's what he wrote in his paper and he didn't include Lisp in that chain of history,  as it were. Right. More questions? No. Okay. Thank you very much.
Joe_Armstrong_-_Functional_Programming_the_Long_Road_to_Enlightenment_0_2687.png Joe_Armstrong_-_Functional_Programming_the_Long_Road_to_Enlightenment_2688_4139.png Joe_Armstrong_-_Functional_Programming_the_Long_Road_to_Enlightenment_4140_4499.png Joe_Armstrong_-_Functional_Programming_the_Long_Road_to_Enlightenment_4500_9131.png Joe_Armstrong_-_Functional_Programming_the_Long_Road_to_Enlightenment_9132_11507.png Joe_Armstrong_-_Functional_Programming_the_Long_Road_to_Enlightenment_11508_15131.png Joe_Armstrong_-_Functional_Programming_the_Long_Road_to_Enlightenment_15132_15179.png Joe_Armstrong_-_Functional_Programming_the_Long_Road_to_Enlightenment_15180_16583.png Joe_Armstrong_-_Functional_Programming_the_Long_Road_to_Enlightenment_16584_17171.png Joe_Armstrong_-_Functional_Programming_the_Long_Road_to_Enlightenment_17172_17891.png Joe_Armstrong_-_Functional_Programming_the_Long_Road_to_Enlightenment_17892_18071.png Joe_Armstrong_-_Functional_Programming_the_Long_Road_to_Enlightenment_18072_18131.png Joe_Armstrong_-_Functional_Programming_the_Long_Road_to_Enlightenment_18132_18443.png Joe_Armstrong_-_Functional_Programming_the_Long_Road_to_Enlightenment_18444_19583.png Joe_Armstrong_-_Functional_Programming_the_Long_Road_to_Enlightenment_19584_20819.png Joe_Armstrong_-_Functional_Programming_the_Long_Road_to_Enlightenment_20820_21659.png Joe_Armstrong_-_Functional_Programming_the_Long_Road_to_Enlightenment_21660_22907.png Joe_Armstrong_-_Functional_Programming_the_Long_Road_to_Enlightenment_22908_23795.png Joe_Armstrong_-_Functional_Programming_the_Long_Road_to_Enlightenment_23796_24347.png Joe_Armstrong_-_Functional_Programming_the_Long_Road_to_Enlightenment_24348_24899.png Joe_Armstrong_-_Functional_Programming_the_Long_Road_to_Enlightenment_24900_26315.png Joe_Armstrong_-_Functional_Programming_the_Long_Road_to_Enlightenment_26316_27587.png Joe_Armstrong_-_Functional_Programming_the_Long_Road_to_Enlightenment_27588_28703.png Joe_Armstrong_-_Functional_Programming_the_Long_Road_to_Enlightenment_28704_29003.png Joe_Armstrong_-_Functional_Programming_the_Long_Road_to_Enlightenment_29004_29087.png Joe_Armstrong_-_Functional_Programming_the_Long_Road_to_Enlightenment_29088_30263.png Joe_Armstrong_-_Functional_Programming_the_Long_Road_to_Enlightenment_30264_30335.png Joe_Armstrong_-_Functional_Programming_the_Long_Road_to_Enlightenment_30336_30395.png Joe_Armstrong_-_Functional_Programming_the_Long_Road_to_Enlightenment_30396_31295.png Joe_Armstrong_-_Functional_Programming_the_Long_Road_to_Enlightenment_31296_32675.png Joe_Armstrong_-_Functional_Programming_the_Long_Road_to_Enlightenment_32676_33587.png Joe_Armstrong_-_Functional_Programming_the_Long_Road_to_Enlightenment_33588_33647.png Joe_Armstrong_-_Functional_Programming_the_Long_Road_to_Enlightenment_33648_34199.png Joe_Armstrong_-_Functional_Programming_the_Long_Road_to_Enlightenment_34200_34319.png Joe_Armstrong_-_Functional_Programming_the_Long_Road_to_Enlightenment_34320_35411.png Joe_Armstrong_-_Functional_Programming_the_Long_Road_to_Enlightenment_35412_35483.png Joe_Armstrong_-_Functional_Programming_the_Long_Road_to_Enlightenment_35484_35531.png Joe_Armstrong_-_Functional_Programming_the_Long_Road_to_Enlightenment_35532_38339.png Joe_Armstrong_-_Functional_Programming_the_Long_Road_to_Enlightenment_38340_38447.png Joe_Armstrong_-_Functional_Programming_the_Long_Road_to_Enlightenment_38448_38543.png Joe_Armstrong_-_Functional_Programming_the_Long_Road_to_Enlightenment_38544_40559.png Joe_Armstrong_-_Functional_Programming_the_Long_Road_to_Enlightenment_40560_41651.png Joe_Armstrong_-_Functional_Programming_the_Long_Road_to_Enlightenment_41652_43631.png Joe_Armstrong_-_Functional_Programming_the_Long_Road_to_Enlightenment_43632_44771.png Joe_Armstrong_-_Functional_Programming_the_Long_Road_to_Enlightenment_44772_44867.png Joe_Armstrong_-_Functional_Programming_the_Long_Road_to_Enlightenment_44868_45635.png Joe_Armstrong_-_Functional_Programming_the_Long_Road_to_Enlightenment_45636_46103.png Joe_Armstrong_-_Functional_Programming_the_Long_Road_to_Enlightenment_46104_46295.png Joe_Armstrong_-_Functional_Programming_the_Long_Road_to_Enlightenment_46296_46343.png Joe_Armstrong_-_Functional_Programming_the_Long_Road_to_Enlightenment_46344_47711.png Joe_Armstrong_-_Functional_Programming_the_Long_Road_to_Enlightenment_47712_47819.png Joe_Armstrong_-_Functional_Programming_the_Long_Road_to_Enlightenment_47820_48263.png Joe_Armstrong_-_Functional_Programming_the_Long_Road_to_Enlightenment_48264_48911.png Joe_Armstrong_-_Functional_Programming_the_Long_Road_to_Enlightenment_48912_50531.png Joe_Armstrong_-_Functional_Programming_the_Long_Road_to_Enlightenment_50532_51035.png Joe_Armstrong_-_Functional_Programming_the_Long_Road_to_Enlightenment_51036_51467.png Joe_Armstrong_-_Functional_Programming_the_Long_Road_to_Enlightenment_51468_51719.png Joe_Armstrong_-_Functional_Programming_the_Long_Road_to_Enlightenment_51720_52007.png Joe_Armstrong_-_Functional_Programming_the_Long_Road_to_Enlightenment_52008_52751.png Joe_Armstrong_-_Functional_Programming_the_Long_Road_to_Enlightenment_52752_54107.png Joe_Armstrong_-_Functional_Programming_the_Long_Road_to_Enlightenment_54108_54155.png Joe_Armstrong_-_Functional_Programming_the_Long_Road_to_Enlightenment_54156_56975.png Joe_Armstrong_-_Functional_Programming_the_Long_Road_to_Enlightenment_56976_58487.png Joe_Armstrong_-_Functional_Programming_the_Long_Road_to_Enlightenment_58488_65099.png Joe_Armstrong_-_Functional_Programming_the_Long_Road_to_Enlightenment_65100_66911.png Joe_Armstrong_-_Functional_Programming_the_Long_Road_to_Enlightenment_66912_69767.png Joe_Armstrong_-_Functional_Programming_the_Long_Road_to_Enlightenment_69768_73943.png Joe_Armstrong_-_Functional_Programming_the_Long_Road_to_Enlightenment_73944_82151.png Joe_Armstrong_-_Functional_Programming_the_Long_Road_to_Enlightenment_82152_82415.png Joe_Armstrong_-_Functional_Programming_the_Long_Road_to_Enlightenment_82416_82559.png Joe_Armstrong_-_Functional_Programming_the_Long_Road_to_Enlightenment_82560_85330.png