Transcription

Good afternoon, NDC. Good afternoon. Thank you. Have you had a good few days? I have. It's been a blast. And they have asked me to come along and close out the conference for some of you, those of you who were wise enough to be here, because there's some strong competition in this spot, by talking to you about something that I call the art of code. Now, does anyone recognize the language that this little intro sequence here is written in? Logo. This is, not only is this logo, this is original Amstrad logo from 1985, because the first computer that I ever had was this. The Amstrad 6128. It was rubbish. I mean, it was brilliant, because I'd never had a computer before. But the games that it had were all this kind of green screen, and they weren't much fun compared to the games in the arcades and everything. And you couldn't do very much with it. No modem, no dial-up, no BBS or bulletin boards or internet. But what it did have on it was this logo programming language. And logo got me hooked, because using logo, I could make the computer draw pictures. And that was a big deal in 1985, because I'd never seen, I could put things on that screen using logo that maybe nobody had ever seen on any screen before. And I got hooked on it. And I got this lovely kind of feedback loop where I liked it because I could make the computer do what I wanted. And every time I did that, I'd get this little thrill and this rush, and I'd go back and I'd have another go. And throughout my entire career developing software and designing systems, that thrill for me has never gone away. And I hope for all of you here as well. You have good days and bad days, but you still get that rush when all your tests are green or when you hit monitoring and it's 100% or something just works, and you're like, I did that. I made that work. And over the last three days here at NDC London, we've had some amazing, brilliant people telling us how to solve useful, important problems, how to design scalable services, deployment strategies, information security, the ethics of artificial intelligence and machine learning. I'm not going to talk to you about anything useful because I am going to talk to you about art. And all art is quite useless, says Oscar Wilde. Now, I don't entirely agree with this quote. I like this quote a lot better. The function of art is to hold a mirror up to nature. And if we want to use art as a tool to explore and understand the world around us, we can hold a mirror up to it. But before we can do that, we need to invent the mirror. And that is where science and technology and engineering come in, because for centuries, we humans have built machines and tools to help us explore and understand the world around us. We've created scanning electron microscopes that have allowed us to see things like this. This is shards on the eyelid of a beetle. It's been there the whole time. And nobody had ever seen it until we invented machines that could take photographs of something that's only a handful of micrometers across. This is crystals growing in a dish of soy sauce. This is the stems inside one strand of a banana leaf, this amazing, beautiful, microscopic world we had never, ever seen. And we've sent machines and cameras and telescopes and people into space. And we've looked back. We've seen our planet Earth rising above the moon. We've looked back from beyond the rings of Saturn. This is us down here. This is the pillars of creation. This is 6,000 light years away in the Horsehead Nebula. And until we invented machines to show us these things, nobody had ever seen it. And within the last 30 years, maybe, we've started exploring another hidden world that's been there the whole time until we developed the machines that allowed us to go in and see it and play around with it. It's a world of mathematics and information. Throughout the 1970s, there was a guy called Martin Gardner who wrote a column for Scientific American magazine about mathematical puzzles and curiosities. And certainly, the most influential of his columns he ever published was this one, October 1970, where he described something called Conway's Game of Life, created by an English mathematician called John Conway. Now, as games go, Conway's Game of Life does not look terribly exciting. It is a game for no players played on an infinite board. And it has four rules, the rules of life. The first rule, each of these cells on our grid can either be living or dead. If a cell has zero or one neighbors, it will die of loneliness. If a cell has two or three neighbors, it survives to another generation. If a cell has four or more neighbors, it's like being in London. It dies of overcrowding. Or it moves to Germany. I don't know. But it's not there anymore. And finally, and this is where it gets a little bit spooky weird, if a dead cell has exactly three neighbors, it will come back to life. And that's it. That is, you now understand everything that there is to understand about the rules of Conway's Game of Life. Now, when Martin Gardner's article was first published, 1970, very, very few people had computers. And so they used pens and graph paper to play the game of life. And they drew diagrams like this. Now, these five shapes are what we call the tetrominoes. They're the five Tetris tiles. And this shows you the evolution of each of those shapes under the rules of Conway's Game of Life. But looking at this, it's like going to a museum where they have the butterflies pinned in a glass case. You can see what the butterfly looks like. But you don't understand anything about a butterfly from looking at this kind of representation. It wasn't until we started using computers to actually simulate this stuff that we really understood the behavior we were looking at. Because these four patterns, they all stabilize quickly. But this one over here, this is just going to keep going over and over and over. And once we could visualize things like this, exploring the game of life became addictive. People started saying, are there patterns that will move across the grid and just keep going? Are there limits? Is the game bounded? Or is it infinite? This was one of the first shapes. This is known as a glider. Repeats itself every six generations. And it just keeps crawling across the grid forever. And once we realized gliders were possible, people started looking for more. And they found hundreds of these shapes, spaceships, they call them. These incredibly elaborate, beautiful creations that just glide across this grid, driven by four simple rules. And that's it. One of the earliest questions that came up in the game of life, can you create patterns that will grow infinitely? There's a guy called Bill Gospe. He was a founding artificial intelligence researcher and computer scientist, some of you may have heard of. And his team at MIT in the 1970s, they created something absolutely wonderful. They created a thing called Gospe's glider gun. Now, what the glider gun is, is it's a stable configuration. And every 27 generations, it creates a glider and sends these gliders streaming out across the grid. And Gospe's team discovered lots of configurations while they were exploring this. They also discovered this thing here, which was called the eater. Now, we have a glider generator and we have a glider consumer. We can generate signals and we can destroy signals. We have one and we have zero. And if we have one and zero, we have binary logic. And we can use that to create logic gates. So this thing here is an AND gate built in the game of life. These little highlighted cells are our inputs. Now, what we're going to do first of all, we're going to start the circuit running. And then we're going to say, OK, we're going to take that blocker out so that our input A becomes true. There we go. A is now switched on. We have no output signal. We only have one input. Let's flip the inputs. What happens if we switch B on? Well, B is on, but we still have no output signal because this is an AND gate. In order to get an output signal on here, we need to enable A and B. We switch on both of those inputs. We switch on our circuit, and there we go. We have an AND gate. Now, the brilliant thing about this is that if you have logic gates, you can make circuits. And if you can make circuits, you can create computers. And if you can create computers, you can run programs, including this program that you may have heard about a little while ago. It's a thing called John Conway's Game of Life. And it goes a little something like this. Now, Conway's Game of Life is just one of a whole category of systems that exhibit very, very complex behavior based on what look like very, very simple rules, simple inputs. You've probably heard of this thing called the butterfly effect. It's a term we get from a branch of science called chaos theory, the idea that weather prediction is impossible because if a butterfly flaps its wings, that input is going to change the output, and you're going to get hurricanes instead of sunshine in Tokyo two weeks later or something. And over the last few decades, mathematicians everywhere have started studying systems in a different way. For a long time, math was only interested in problems you could solve. Give us the solution. If you can't give us the solution, this problem is not interesting. We're just going to go and find something else to look at. But mathematicians kind of embrace this whole different school, a different way of thinking. We created imaginary numbers. Now, the basic rule of an imaginary number, we have this number i. And in the natural world, negative numbers don't have a square root. 2 times 2 is 4. Minus 2 times minus 2 is also 4. So how do you get what times what equals minus 4? Well, nothing. It doesn't exist. And mathematicians go, no problem. We'll just make something up. We'll invent i. It's an imaginary number. And i squared equals minus 1. And this is where the rest of the world goes, you can't do that. And mathematicians go, we can do anything we want. It's imaginary. We don't care. But then once they've developed this and they've come up with a rigorous set of mathematics around it, you can do some really interesting things with it. Now, this thing here, 0.8 plus 1.2i, hang on a second. Give me one second. There's a bunch of slides that have gone missed here. And this is not making a huge amount of sense. Da, da, da, da, da, da, da, da, da. Yeah, no, we're good. We're good. We're good. We're good. One slide is missing. Right. Now, this number here, 0.8 plus 1.2i, this is what's called a complex number. A complex number is like a project plan. It has a part that is real, and it has a part that is imaginary. And it is very difficult to predict what is going to happen next once these things get involved. Now, there is a whole study of systems and the behavior of systems that we can talk about. This thing here is called an Argand diagram. And the blue bit is imaginary. The red bit is real. So 0.8 over there and 1.2i plotted up there. And this way, we can plot numbers in complex mathematics in this kind of space. And we can do arithmetic with these numbers, just like you used to do in high school. So we take 0.8 plus 1.2i. You just expand the numbers out as you go, and you multiply. And all you need to do is remember that anywhere you have two blue numbers multiplied together, the result is going to come out negative. It's going to come out backwards. So this 1.2 times 1.2i, well, you square them, but then you stick a minus on the beginning. And you take negative complex inputs. You get complex numbers out the other end. Now, what's really interesting is when you start studying the behavior of systems that are driven by these. Let's take a really simple function here. We're going to take some real number, x. So we're back in ordinary mathematics. And every generation, x is going to go to x plus 1. So 1, 2, 3, 4. And you can already intuitively see you know how this system is going to behave. You can be confident you understand its behavior all the way up to infinity. Let's try another one. So if we take this example, x equals 2 minus x, it's going to go to there. 0 minus 2, 2 minus 2, 0 minus 2, round and round and round. If we apply the same thing to this complex number, what we're going to do is we're going to keep taking that number and squaring it. First time we square it, it goes to here. We square it again, it goes to here. We square it again, it ends up over here, and then over here. And then it disappears off to infinity. We're going to move it ever so slightly. And we're going to run the same sequence again, this time 0.6. And it goes to here, and here, and here, and here. But it doesn't escape this time. It goes into this little kind of weird almost circular orbiting pattern. Now, those two points are right next to each other, but they exhibit dramatically different behavior when we iterate them over and over again by squaring them, and squaring them, and squaring them. And eventually, this one disappears. Now, the first really rigorous study of these kinds of systems was done by this guy. It's a Polish mathematician called Benoit Mandelbrot. And Mandelbrot was fascinated by the mathematics of real life. He had this quote, clouds are not spheres, mountains are not cones, coastlines are not circles, a bark is not smooth, nor does lightning travel in a straight line. Now, Mandelbrot had a brilliant job. He taught mathematics at Harvard. And when he got bored, he went to IBM and played on the computers. Because this is the 1970s when IBM had computers and nobody else did. So he would come up with these wonderfully complex mathematical ideas, and then he'd go over to IBM and spend a couple of months playing around and simulating them, and then he'd go back to Harvard and talk to his graduate students about all this kind of stuff. And he was the first person to see the shape which now bears his name. His name was Mandelbrot, but everyone calls it the Mandelbrot set, and I know that I'm going to do that. So let's just call it the Mandelbrot set. Basically, he took each of these numbers in this grid, and he said, we are going to square this and add it to itself, and square it and add it to itself. And we are going to see whether it stays on the grid or not. And if it stays on the grid, we are going to color it in black. And if it disappears and vanishes off the grid, we are going to color it in a different color depending how quickly it, what's called, tends towards infinity. He started off with these very, very low resolution renditions of this image. But the one that you're probably used to, all of us have seen, is this, the Mandelbrot set. Now, the astonishing thing about this, from this incredibly simple mathematical rule, there is an infinite amount of complexity. We're going to take a Mandelbrot set here, and we are just going to start magnifying, and we are going to start zooming in. And when we get to around about here, we're going to say that's one times magnification. And we're going to keep zooming and zooming and zooming. And by the time we get to about here, that original shape is now the size of this building, and we are still zooming in. When we get to around about here, that is 2 to the 20 factor magnification. The original shape is now bigger than London, and we are still zooming in. And around about now, the original shape is bigger than the United Kingdom, and we are still zooming in. And we are still zooming in. And we can continue zooming into this shape forever. It never repeats. It is what's called self-similar, which means it resembles itself at different scales, but it never repeats exactly. There is an infinite amount of detail buried inside this one shape. And this has been there the whole time. Nobody invented this. We discovered it. Now, the Mandelbrot set, some people have called it the thumbprint of God. Now, I'm not a very spiritual person, but I do play a lot of computer games. And I love that thing in a computer game, where you're doing something silly that maybe isn't part of the main campaign, and you find that the game designers left something there to persuade you that you were supposed to be here and you're on the right track. And this thing has been hidden in mathematics since our universe was created. And no one ever saw it until we humans. We invented computers, which means taking lightning and sticking it in a rock until it learns to think. And we invented advanced mathematics. We invented high-definition color displays and rendering technologies, all this kind of stuff. And this is what we found, something that was hidden there the whole time nobody had ever seen until we built the machines and the technology to allow us to visualize it. Now, in this day and age, just putting pictures on a computer screen is not actually that big a deal anymore. This was from Tron, which was a movie Disney made in 1982, first film to have completely computer-generated sequences. Tron did not win the Academy Award for Best Visual Effects. It was disqualified, because using a computer to make a film was cheating, according to the Academy of Motion Picture Arts and Scientists. They changed their minds eventually, and they gave it a Lifetime Award. But we've got really, really good at using computers to simulate things. Luxo Jr. was the first completely computer-generated film, 1985. Jurassic Park, 1994, the first time we had computer-generated characters on screen with human actors. And it looked convincing. It looked compelling. It became part of the story. A couple of years ago, we had this guy on our cinema screens. Do you know who this is? Because there's one bunch of people who say, that's Peter Cushing, and he's my grandfather, and he's dead, and you shouldn't have done that. And there's another bunch of people going, that's Grand Moff Tarkin, copyright Lucasfilm Entertainment, 1978. We own him. And who is it? Is it the actor or the fictional character? It's triggered this really interesting ethical and legal debate. But the point is, we can put, I saw a review of The Last Jedi, the last of us film, which says, we've now got living actors playing dead characters and dead actors playing living characters. It's come full circle, thanks to computer technology. And we're at the point where we can do anything. You could turn to your computer and go, you know what? I'm bored. What would it have been like if they'd made friends with Nicolas Cage playing all the parts? And we can just do that now. Now, the reason we can do things like this is that we have created computers and algorithms that work on the same principle as some of the most complicated firmware in our own brains. You ever lie on your back in a field on a sunny day, and you're watching clouds, and your brain is kind of filling in shapes for you? This cloud looks like a rabbit. That looks like an airplane. That one over there looks like a house. And you're running all of these pattern recognition algorithms and filling in shapes and recognizing things. And one of the things that we are hardwired to do is to recognize faces. Now, we've got very, very good. We don't entirely understand how they work. But we can now create something called a convolutional neural network. You build a whole stack of layers of logic, and you give it input. You say, these are cats, and these are dogs. Learn. And it goes away, and it learns, and it learns, and it learns. And eventually, it creates an algorithm that you can give it a photograph, and it will say with confidence, that's a cat or that's a dog. Now, that doesn't sound terribly difficult, right? I mean, how hard can it be to tell a difference between a puppy and a muffin? It can be a lot harder than you think. But we're getting good at this. But what gets really interesting is when people take the dog detection algorithm, the dog detector, and they wire it backwards. And they say, this is now a dog amplifier. And the machine goes, all right. And then you give it a picture like this, and you say, amplify the dogs. And the computer says, this is a horrible idea. Please, please, please don't make me. And you say, neural network, find the dogs and enhance the dogs. And it goes, you're going to regret this. And you go, no, no, turn up the power. Maximum dog amplification. And you get stuff like this. This is a whole new kind of art that has become possible because of machine learning that nobody had ever even thought of before. And the technique that's used to do this is something called deep dreaming. It came out of a project in Google in 2015. And this kind of, it's really unsettling, isn't it? Because you're looking at it, and what's happening is those same circuits in your brain that we've learned to emulate in hardware, those circuits are going, dog, no, it's not a dog. Dog, no, it's not a dog. Dog. And your peripheral vision is finding patterns you recognize. But then when you look at them, it turns out you've been tricked. And so you get the very, very complex perception around what's going on with it. Now, this is just one of a whole bunch of ways that people are using modern technology and software as artists to create new kinds of art. Why don't I introduce you now to a guy called Robert Felker, who I met in Warsaw the other week, who's doing some really, really interesting stuff. When I start a new artwork, it's just an inspiration. You just have a feeling. So between the first idea and the end result, there's just the same feeling. It's not about the visual. I'm not interested in what you see. I'm interested in what you feel. I'm Robert. My everyday job, I'm a Flutter dev and project manager. And I'm also a Flutter artist. Previously, I was kind of locked by the tool. I can do a lot of stuff, but only what the tool permits me. When I found Flutter, it opened a door inside me. Now I can really push further. Generative art is a lot of research, like a lot. It's a lot of failure. It's a lot of failure finding the color, finding the form, understanding the good behavior of light. What's really good with Flutter is the speed of the feedback. It's nearly instant. Currently, artists do not understand the full potential of the tool. When you start Flutter, you have to be When you start Flutter, you start with material design, or you start with the iOS component. And you think, this is Flutter, but this is just the tip of the iceberg. If you want to push, then you start to enter the Flutter engine. And the Flutter engine is like the jewels of the crown. Each time I start to code, I just feel joy. So some people are painting, some people are cooking. I just do Flutter. I'm Fluttering. And this is an example of one of Robert's works. This is a photograph he took in Tokyo at night that he then used machine learning to do a depth perception analysis to identify from the photograph the depths of all the elements in this, and then use software and tools to creatively rebuild the photograph working in layers. And I think this is quite beautiful. It's kind of hypnotic. And every time you watch it loop through, it reveals something new. And this is just one of hundreds of ways that artists are using code to create new kinds of artworks we've never seen before. But what if we stopped talking about using code to create art, and we start talking about code as an art form in its own right? Now, this very famous book, one of the great textbooks or sets of textbooks in computing science, Donald Knuth's The Art of Computer Programming. And we can debate for a long time. Is programming an art? Is it science? Is it engineering? Is it typing? Is it, you know? But I'm sure many of you have reviewed code that came from somewhere. Maybe somebody on your team was tired or out of their depth with the tool. Maybe you were just having a bad day, and you looked back at it a few days later. And you're like, I don't know what this is. It's not engineering. It's not art. I don't think it's terribly creative. I wouldn't dignify it by calling it hacking. I have no idea what this is. But fortunately, there is now a safe space for this kind of code and these kinds of programs. And it is the International Obfuscated C Code Contest. The goals are to write the most obscure C program, to show the importance of programming style in an ironic way, to stress compilers with unusual code, to illustrate some of the subtleties of the C language, and to provide a safe forum for poor C code. I'd just like to share some examples with you. So this was a guy called, I think, Jonathan Mills contributed this. This is the entire source code for this program. Are there any C programmers here in the room today? You want to tell me what this does? And it's just code, right? There's only one screen of it. How hard can it be? Let's just run it and find out, because why not? We'll just run the makefile, and then we'll run it, and there it is. It's Flappy Bird running in a terminal. Here's another one. Let me zoom out, give you a little bit of context. So this code actually generates and draws the Mandelbrot set in a text window. And it does it in a relatively kind of compact code base that's shaped like the thing it draws, which I think is rather neat. Now, brevity is one of the objectives of obfuscated code. You want to do something really surprising with a very, very small amount of code. This is the entire source code for a program by a guy called Oscar Toledo Gee. If you copy and paste this into your web browser, it plays chess. It doesn't draw a chessboard. It plays chess. It is a chess algorithm implemented in just under a kilobyte, including JavaScript, HTML, graphics, behavior, logic engines, all the rules of chess, and an engine that is actually better at chess than me. This thing beat me in games in that much JavaScript. Now, there are some astonishing examples of programs that do wonderful things with very, very small amounts of code. But none of them is quite as good as this one. This was submitted to the International Obfuscated Contest by Simon Rasinkovic in 2005. And it was accompanied with documentation saying, if you compile this using this compiler, it will print its own source code. There's nothing here. This is an empty file. But that compiler had a quirk that if you fed it empty input, it would create a C program and compile it that produced no output. And so he quite rightly said, this program prints its own source code. Now, the Obfuscated C competition went, OK, one, very clever. Two, have a prize. Three, we're changing the rules. From now on, all programs have to have at least one character of input. Otherwise, they are just this program completed again. But this idea of a program that prints its own source code, it's something called a quine. The word comes from this book, which some of you may have read, which is a kind of fascinating riff on mathematics and recursion and fractals and poetry and music and stuff. And it turns out that writing a program that prints its own source code is actually surprisingly hard. Now, you're not allowed to just read it from disk and print it. That would be cheating. You have to generate the source from within itself. So let's write one. I'm going to write a quine for you now using C Sharp. So we need a class program with a static void main method. And then we obviously need to right line the class program and close the bracket. And we need to right line the static void main. And now we need to right line the right line. And then we need to right line the right line with the. And you very quickly get tangled up in, oh, this is just going to be strings all the way down. But every language out there has quirks, loopholes that we can exploit to make it do things that it wasn't supposed to do. Now, in C Sharp, there is a feature called string templating. So we can define a string that looks like this. And we can put placeholders in it. These little things here say, when you see an argument, put that in the string at this point. And then we are going to feed this string back into itself as a placeholder variable so that when it gets to that bit, it prints itself. And it doesn't go into an infinite loop. What it does is it prints itself. It prints its own source code. And different languages have different loopholes you can exploit to make coins. JavaScript coins are very easy, because every function in JavaScript has a to string that prints it. So this JavaScript function prints itself. In JavaScript and ECMAScript 6, this is a coin. And I didn't believe this, because that doesn't look like anything. So I ran it in a console. And sure enough, that's the output that gets produced when you run it. But what's really interesting, this is an idea I got from a guy called Leon Bambrick, who wrote a great post about this, is can you make a coin in HTML? Now, HTML, you're like, is it a real programming language? I'm not touching that argument. Can you write a coin in it? Well, let's find out. Here is some simple HTML source code, title, head, body, couple of paragraphs, and a link to Leon's original thing on this. And this is what it looks like in a browser, right? Start breaking some rules. So first, we're going to put some style on that says, display everything as a block, even things that are supposed to be invisible. This star will match everything. We run that in a browser. And now we can see our CSS. Our source code is coming through in that browser. Now we're going to put some rules in that say, well, before HTML, we want you to display this. And afterwards, you display this. Now, the slash HTML is actually down here off the bottom of the screen. Because it knows it has to draw it, but we haven't told it where to put anything. And the safety is off at this point. We have no idea. The browser is like, you're on your own, kids. Have fun. We play in a bunch more rules, style. Here, we have to put a backslash to escape the slash because a web browser is actually running three different parsers. It's parsing HTML, it's parsing CSS, and it's parsing JavaScript. And they're all fighting over who gets to eat the next bit of input. And at this point, if we put slash style, our CSS parser is going to go, yep, I'm done. And HTML is going to choke on the rest of this chunk here. So we have to escape it. Now, we have before and after tags. Now, there's no way of generating these. We just need to go and plug in head, body, title, anchor, paragraph, and we get this. Now, you'll notice that down here, we've got this A, but we don't have the href equals with the web address we want to link to. Can we do that using HTML and CSS? Oh, yeah. No problem. If you see A with an href, we want you to take this attribute and put it into some content and stick it in before the thing. And there you go. And the last thing that we're going to do, just to make it look nice, is we're going to put a margin on there and change the height of the HTML. And there we go. We have a web page that actually prints its own source, which is completely useless and utterly pointless. But how many of you learned something you didn't know about the HTML parser when you were watching that little run through there? Let's have a look at some more. Here is some source code. Who wants to tell me what language this code is written in? C. C? C? Any other votes for C? Well, let's apply a C preprocessor to it. We'll take out the comments. Include standard iod.h. Main chart. I mean, the formatting on this is a little wonky, but yeah, this is fine. This is completely valid C code. But what happens if we apply Ruby syntax highlighting and highlight the strings? Because that looks to me like perfectly valid Ruby code, right? Let's try running it and see what happens. So I'm going to take that program, polycoin.c. There it is. And now I'm going to feed that program into the GCC compiler, and I'm going to run it. It's got a warning, but we're way past the point where we care about warnings. And there we go. That program prints its own source code. And now, because why not, we are going to run the same thing through the Ruby interpreter, and we are going to get, look at that. It prints its own source code. Now we're going to run it in Python, because we can. And it prints its own source code. And now, hey, in for a penny, let's run it in Perl and see what we get. And it prints its own source code again. And apparently it'll also do it in C++ if you can find an old enough compiler. This is a polycoin. This is a program that is valid in more than one language at the same time. And in this example, it always prints its own source code. Now, who would like to tell me what language this program is written in? Well, let's break it down, all right? Let's do some syntax highlighting. So we've got system.console, which is kind of like a .net-y kind of a thing, right? And then we've got this chunk here, which is an XML namespace. We've got a console.log and a foreach in lowercase. So that smells kind of JavaScript-y to me, right? We've got an AdaTextIO procedure. We've got begin in capital letters, which is either COBOL or SQL. It's definitely from the 1970s, and it lives in a bank. And up here, we've got act1, scene1, enterHX, which doesn't look like any program I've ever seen. Now, this is an excerpt from something called the Ouroboros Quine. It's a Ruby program that creates a Rust program. And the Rust program creates a Scala program, and the Scala program creates a Scheme program, which said Shakespeare all the way around the circle, 128 languages, until you end up with a RC program that creates a REX program that creates the original Rust program again. This was written by a Japanese developer called Yosuke Endo, who's one of the contributors to the Ruby core language. And the fact that it exists at all is astonishing. This is what the source code to that quine looks like, which is also incredible. And if you zoom in on the end of the source code, you'll notice that the last four lines all just say buffer for future bug fixes, because they don't want to mess up the shape of the source, you know? Now, this is the most astonishing thing about this. All 128 of those languages can be installed on Ubuntu Linux by going apt-get REX, apt-get Shakespeare, apt-get TC. So there is a GitHub Actions continuous build pipeline for this thing, that whenever changes to it are committed, it runs them through all 128 languages and tells you whether it succeeded or not, which I just think is fantastic. And, you know, weird, but I love the fact that we can do that. But let's backtrack a little bit. In that chunk of code we looked at, there was some C, and there was some JavaScript. But there's also Act 1, Scene 1, Enter AJAX. Now, that is an excerpt of a program written in the Shakespeare programming languages, one of a family of what are called the esoteric languages, ESOLANGs. And Shakespeare is designed to let you write computer programs that are also Shakespeare plays. This is Hello World in Shakespeare, the infamous Hello World program. Now, all variables in Shakespeare have to be declared as the characters in the play. So we have Romeo, and we have Hamlet. Act 1, Scene 1, that's a namespace and a block. Enter Hamlet and Romeo. This is variable scope we are dealing with right now. And then the way variables work in Hamlet is when they say nice things, they increment. And when they say insulting things, they decrement. So at this point, Hamlet is talking to Romeo. And Hamlet says, you lying, stupid, fatherless, big, smelly, half-witted coward. You are as stupid as the difference between a handsome, rich, brave hero and thyself. Speak your mind. That puts the letter H into Romeo and then outputs it, because H is the first character in Hello World. The next chunk here will print E, and so on. Hello World in Shakespeare is about three pages of fairly florid prose, which is fine, because it's Shakespeare, and that's what it's supposed to look like. How about this one? Can anyone tell me what programming language this is written in? This is whitespace. Let's have a look at that with syntax highlighting applied. Whitespace is a programming language that only cares about spaces and tabs. It ignores everything else. It's brilliant if you want to hide programs inside other programs. Mix up your tabs and spaces, and you can put whitespace alongside anything else. This is Hello World in whitespace. Let's take a look at the Hello World souffle. Now, this is a programming language called Chef. And Chef is designed for writing programs that are also recipes. Now, 72 grams of haricot beans, 101 eggs, 108 grams of lard, 111 cups of oil, 33 potatoes. It's a valid program, but would you like to eat this souffle? And so a guy called Mike Worth looked at the Chef programming language and went, challenge accepted. I'm going to write a Hello World program that's actually a sensible recipe you can make in your kitchen. And he came up with the Hello World cake with chocolate sauce. Now, I think this is brilliant. If you compile this on a computer, it says Hello World. If you compile it in a kitchen, you get an edible cake with a kind of chocolate sauce ganache that you can pour over the top of it. But the thing I think about this that's beautiful is if you didn't know about Chef, you'd think this was just a recipe. It fits so well into two different domains of human creativity that from one, you'd have no idea that it also worked in the other one. I'm going to show you how to square a number in a programming language called Pete. That is how to square a number in Pete. Pete is named after the Dutch artist Piet Mondrian. And Pete is a graphical language where the instruction set is dictated by what happens when you cross from one color into another. Every Pete program starts with an instruction pointer in the top left traveling towards the right, traveling due east. So what's actually happening here is when we cross from light blue to dark green, that says input a number. Prompt the user and put that on the top of the stack. When we get to black, turn the instruction pointer through 90 degrees. When we cross from green into red, that means whatever's on the top of the stack, duplicate it. When we cross from red to yellow, multiply the top two numbers off the stack, multiply them, put the product back on the stack. When we cross from yellow into red, that is output. Whatever's currently on the top of the stack, commit that to standard out. When we cross white, that is a no operation. We reach the end of the grid, we turn right again. And then we follow this blue instruction set until we end up with black on all sides, which means you have reached the end of the program. Please hold. So that's a completely Turing-complete language whose instruction set consists of areas of light and shade and the transition between colors. This is Hello World in Pete, one of many, many examples. But you could hang this on the wall in your house, and somebody could come in and take a look at it. They'd have no idea they were looking at Hello World. They'd just think you like kind of slightly weird 16-bit art, you know, the Windows 3.1 school of expressionism. Now, we've talked so far about this whole idea of using. We've talked about using code to create art. We've talked about code that is art. And over the course of MDC, you've probably seen a couple of speakers here doing live demos, which are the tightrope, the high-wire act, the death-defying circus thrill of the technology industry. Because someone is coding something on a laptop live, and it might work, and it might not work. And there's always this element of kind of risk, and then it works, and everyone's like, yay, and you get a big round of applause. But generally, as an industry, we don't like that. We like consistency. We like reproducibility. We like automation. We like being able to do the same thing over and over and over again. If you've ever worked in a place where there is a server under a desk or maybe in a rack somewhere that's running Windows 2003 Small Business Edition, and you're not allowed to touch it, do not put Windows Update on that, or the payroll will stop working on pain of immediate gross dismissal. And we have a name for these kinds of boxes that everyone is frightened to touch. We call them snowflakes, snowflake servers, snowflake processes. It's completely unique. But if you go out in the snow, and you pluck a snowflake out of a blizzard, and you watch it melt on your hand, you have just been part of a performance that will never, ever be repeated anywhere. Your participation in that has created a unique human experience that nobody else will ever understand or be part of. And maybe we can do the same kind of thing using code. This guy here is Sam Aaron. And Sam is the creator of a programming language called Sonic Pi. Was anyone in the last talk in this room yesterday where Lara did her talk about programming with music? And she was showing us how to write computer programs whose output is not text or graphics. It's music, and tones, and sounds, and melodies. And she ended up doing this wonderful layering thing. Because Sonic Pi is a live coding music synthesizer. I'll give you a very quick demo of how Sonic Pi works, which I'm not going to live code for you, because I don't want this to get too meta. Now, when you start Sonic Pi, it gives you a prompt, and you say, play this note, and it plays that note. Now, Sonic Pi runs all your instructions in parallel unless you tell it not to. Imagine if JavaScript did that. If you want things to happen one after another, you have to put sleep instructions in and say, we want to introduce some kind of delay to this as it goes along. And where it gets really interesting is we can go in, and we can start putting loops around our notes and our musical patterns. So we got 16 times do that, and we've got the world's least exciting bass line going on there. So let's crank up the tempo a little bit. We're going to say, use beats per minute 244. Do, do, do, do, do, do, do, do, do, do, do, do, do, do, do. All right, we're getting somewhere. And we're going to change it, because the sine wave is not a terribly exciting noise. We're going to use a built-in synthesizer here called TechSource. Now, this is interesting. But where it gets really interesting, as you'll have seen in Laura's talk yesterday, is when we introduce the concept of something called a live loop. Now, live loops allow you to run multiple components of your program simultaneously at the same time. So I'm going to put a live loop there around that bass line. And then I am going to drop another loop in over the top of it. And I'm going to say, this time, I'm going to put a live loop around that bass line. And I'm going to drop another loop in over the top of it. And I'm going to say, this loop is called cymbals. We want to synchronize it with the main loop so that they play in time. And we're going to put a cymbal track on that. And then I'm going to jump over to another buffer where I prepared something for you earlier. I'm going to paste this into the program. Now, you'll notice I haven't restarted it. This is all happening seamlessly in real time. So now we've got this awesome bass line. And we've got this drum track that we did. And I'm going to put a counter in here. And I'm going to put a number for i in the middle. Every time we play a note. And I'm going to say, if i is divisible by 3, play a different note. And now I'm going to say, well, how about if i is divisible by 5, play a different note. Anyone guess what's coming next? 15. If i is divisible by 15, I want you to play this note. So there we go. That's Fizzbuzz with the output as a musical riff, as a melody, the Fizzbuzz riff. Now, Sonic Pi is fantastic. It's an enormous amount of fun to play around with. I've seen people do live coding with multiple musicians. That picture at the beginning was Sam on stage with the London Philharmonic Orchestra doing live coding in the Royal Albert Hall. It's an absolutely astonishing tool and just one of the brilliant and creative ways that we're coming up with to use code to do fascinating and unexpected things. But I want to finish today. I've talked to you about all kinds of things that other people did. I want to finish by telling you about something that I did. Now, you are probably familiar with the trope of the Rockstar developer, because we've all read job advertisements from people looking for a Rockstar senior front end, Rockstar JavaScript engineer, Rockstar senior Java software developer. This has been endemic in our industry for years. And last year, Paul Stovell put this on Twitter. He said, to really confuse recruiters, someone should make a programming language called Rockstar. And I had this experience, because I thought, this is it. This is my purpose. This is why I was put here, because what the world clearly needs is a programming language that allows you to write programs that are also bad 1980s heavy metal songs. And so Rockstar was born, a dynamically typed Turing-complete programming language for creating computer programs that are also song lyrics, heavily influenced by the lyrical conventions of 1980s hard rock and power ballads. Now, Rockstar was created in a bar as a joke. That will become important shortly. So I'm in a bar with a laptop and a beer, and thinking, could you make a language where rock songs could compile to something? Now, I used to work in VBScript and Perl a lot. And I've done work in Ruby. So I'm used to languages which try and borrow a lot of elements from natural language and incorporate them into programming syntax. So I thought, all right. First of all, if you want to write songs in it, there's more than one way to do it. Like the Perl idiom, Tim Toadie, you know? So hello world in Rockstar is say hello world. Or scream, or whisper, or shout. These are all syntactically valid. Programming requires variables and assignment. Now, you're probably used to int x equals 5, var my string, the message. Now, we don't need int, because Rockstar is a dynamically typed language. We are going to take those out. We don't need semicolons on the end, because if JavaScript can live without them, so can we. Now, the equals sign in the middle, how do you sing that? Let's just put is. x is 5. My string is hello world. The message is Flutter rocks, because I forgot to update that. That should say NDC rocks. Now, there's this ongoing debate about casing. You ever had one of those arguments longer than an hour about Pascal case versus camel case versus kebab case versus underscore case? And I saw Douglas Crockford, the guy who created JSON, give a talk two years ago where he said, we have all these stupid arguments. What we want are variable names with spaces in them. Well, guess what? When you're inventing a programming language in a bar, you can name anything you like. So Rockstar has variable names with spaces in it. It's not a complete free-for-all. There are three kinds of variables. Simple variables work like they do in JavaScript and Ruby. Common variables have to start with my, your, the, and a. And proper variables need capital letters. So we can write programs about Dr. Feelgood and Black Betty and Billie Jean and all these great characters who inhabit the world of rock and roll. Now, initializing variables, we normally do with numbers. Fizz is 3, buzz is 5, the limit is 100. I didn't want to do this, because it doesn't sound terribly metal, really. I thought, how can you define a numeric literal without having to use digits in your source code? And I had this idea. What if we take the lengths of the words, modulo 10, and we treat those as digits? So ice is 3, 5. The limit is a lovestruck lady killer, 1. That's 10, 10 modulo 10 is 0, 0. We've got 3, we've got 5, we've got 100, without having to put digits in our source code. It works with floating point numbers, as well. And see, decimal pi, 3.1415, blah, blah, blah. In JavaScript, var pi equals, well, it's kind of almost, you'll probably get something close to that back out, because hey, JavaScript, right? In Rockstar, my heart was ice, a life unfulfilled. Waking everybody up, taking booze and pills, 3.1415926535. Easy, right? You've got to be able to do arithmetic, right? Now, we have these common ways of talking about English. How much is it? Oh, the total is the price with the tax. Well, what about the net amount? Oh, that's the total without the tax. How many do you need? Give me the quantity of the product. How fast were you going? Well, speed is the distance over the time. We have these things. It's easy. But this mathematical convention also allows us to write a girl with a dream, a man without a face, the wings of the night, and a whisper over the water. We need comparison. Your love is a lie, true or false? Well, is it? The whiskey ain't the answer. My heart is stronger than steel. My soul is weaker than water, as strong as a lion, as low as a snake. We need function syntax. Now, the sort of simplistic version here, let's have a function modulus. It takes a number and a divisor. Those are our input arguments. And while a number is as high as a divisor, put a number without a divisor into a number and give back a number. This is how you implement modulus when your building blocks are just addition and subtraction and loops and stuff. Now, this works. But we can do better, right? Because midnight takes your heart and your soul. And while your heart is as high as your soul, you put your heart without your soul into your heart and give back your heart. Now, at this point, I'm about three beers in. I have a parody specification that is just complete enough to implement fizzbuzz. And I have fizzbuzz in Rockstar. And I stick this thing up on GitHub. And I'm just like, hey, everyone, introducing Rockstar, a proposal for a Turing complete programming language. And I think this is going to be funny for like three hours. It gets 2,000 GitHub stars overnight. It makes the front page of Hacker News and just kind of starts this buzz. It made it into a Boing Boing magazine. Cory Doctorow wrote a thing about it in there. It made the front page of Reddit. People on Reddit were actually saying complimentary things about it. The weirdest thing that happened is I got an email from Classic Rock magazine, which is a real music magazine that has nothing to do with computers, saying, what's this Rockstar thing that we keep hearing about? So I wrote a little thing for it, did like an email interview for them. And I'm thinking, all right, this can't possibly get any weirder. And then people start filing issues against my parody specification. And I'm looking at these. And some of them are just ideas, like what if all the numbers go up to 11? And I'm like, no, arithmetic's hard enough as it is. But some of them are like, there's undefined behavior. And I'm like, what do you mean there's undefined behavior? Why do you care? And they're like, I built a Rockstar compiler in Scala over the weekend, and it has edge cases. I'm like, you did what? And within about a week, there was a Scala interpreter. Someone had built a compiler for it in Rust. Somebody had built a Rockstar to Python transpiler. And the fascinating thing is all of them had managed to do like 95% of it just based on this random stuff I came up with in a bar as a joke. And some of it makes no sense. And if I'd known it was ever going to be real, I'd, of course, have done it differently. But programming is like that. Now, I really liked the idea of Dylan Beattie, the creator of Rockstar. And I didn't think I'd done enough work at this point to really earn that. And I also wanted Rockstar to be, you know, Scala and Rust and Python are all very well. But I wanted it to be something accessible, something that anybody could just open up in a web browser and write some Rockstar code and see what it did. And so this time last year, I basically spent about five weekends reteaching myself how to build compilers and parsers and metacircular evaluators and stuff. And I built a Rockstar interpreter in JavaScript, which is definitely the stupidest, dumbest thing I've ever done. And it's online. And it is here. It is at codewithrockstar.com. And everybody here in this room is welcome to go and try this, put some code in there, and you will then be a Rockstar developer. Now, I just want to shout out one thing. The logo here in the top left, I wanted to borrow some real, over-the-top, excess 1980s rock and roll heavy metal influences. And I looked at Judas Priest and Iron Maiden and Motley Crue and all these kinds of people. And then somebody said, have you thought about Microsoft consumer products, 1980 to 1982? And I was like, that is exactly what I want. That logo type is perfect. So thank you, Microsoft, for letting me recycle your old logo, be green. Now, I do have some certified Rockstar developer stickers to give away here at NDC. So come up afterwards with your codewithrockstar.com code on your phone, and I will certify you. You will become a member of the world's most prestigious developer program. But to end the talk today, I'd like your help in something. Now, I showed you some examples in there of Hello World and Pete that just looks like a painting and the Chef Hello World chocolate cake that could just be a cake. And if you like, the test of whether Rockstar really succeeds as a language is, can you perform a Rockstar program and have people just think it's a bad heavy metal song from the 1980s? And so with your indulgence, I'd like to close NBC and this talk by performing live Fizzbuzz in Rockstar. Fizzbuzz in Rockstar. That night takes your heart and your soul. While your heart is as high as your soul. Put your heart without your soul into your heart. Give back your heart. You remember the Fizzbuzz riff? Fizzbuzz in Rockstar. Your desire well, is love struck like a killer. My world is nothing. Fire is ice. Spilling is water, till my world meets desire. And midnight taking my world, fire is nothing. And midnight taking my world, can't take nothing. Shaft is fun, take it to the top. And midnight taking my world, fire is nothing. Shaft is fun, take it to the top. And midnight taking my world, can't take nothing. You save us, take it to the top. Whisper my world. And midnight taking my world, can't take nothing. And midnight taking my world, can't take nothing. Thank you very much, NDC. Thank you for coming. Thank you for your time. Thank you for listening. Who's coming to PubConf? If you thought that was silly, we've got way more stuff in store for you tonight. If you're coming to PubConf, I will be emceeing tonight. We've got 12 amazing speakers lined up with five-minute funny talks. There are still tickets on sale. If anyone doesn't have plans tonight, pubconf.io. If you are not coming to PubConf, thank you very much. I will see you somewhere out on the road. Have a wonderful weekend. See you soon. Bye-bye. We'll be emceeing tonight. We've got 12 amazing speakers lined up with five-minute funny talks. There are still tickets on sale. If anyone doesn't have plans tonight, pubconf.io. If you are not coming to PubConf, see you soon. Bye-bye.