 We tried to get her last time for the functional con. She couldn't make it, but I'm glad she's here. And I'll let her introduce herself. Thank you for coming. Thank you for having me. It's 9 AM in the morning, and I'm apparently giving the opening keynote for this conference. I'm not a morning person. I can only assume that this means that Nuresh is trying to kill me. But I'll try and soldier on. So what I'm going to do today to get you warmed up for the entire three days of the conference is I'm going to do some live coding for you. I'm going to actually just write a game. And I'm going to show you some interesting techniques for doing that. But before I start that, let me just talk about the state of JavaScript currently because I'm just going to come right out and say I'm a hipster. That means, by my definition, that I like to feel special and smarter and more superior to other programmers, which means that obviously I go into functional programming because functional programming is a splendid tool for making other people feel stupid. But the state of JavaScript today there is sort of not doing it for me. We've got these giant frameworks everywhere. I mean, jQuery is good, okay? It's tiny, but we've got like Angular and Ember and other giant things. Like Angular actually has dependency injection. Do you know what that makes me think? It's like, it's enterprise programming, isn't it? And that's not really what I sign up for. It doesn't make me feel like I'm doing anything special because in functional programming, you have this vocabulary from mathematics which is just amazing for confusing people. Like you've got the closely arrows, you've got the you need a lemmas. I'm not sure what a you need a lemma is, but apparently you need one. And cyber histomorphic primomorphisms. That's a real thing in Haskell and there's nothing like a word, like actually I heard in practice a lot to learn how to say cyber histomorphic primomorphisms. And there's nothing like it to make other programmers feel like, what's going on? I have no idea what's happening here. The sad thing there is that none of these actually translate very well to JavaScript. None of these things, which are fantastically useful in Haskell, are actually useful in JavaScript, which makes the preposition of doing functional programming in JavaScript a bit harder than I'd like to. Fortunately, there's this thing called functional reactive programming now. Or I should say, there's this thing called functional reactive programming and then there are lots of libraries trying to implement that and apparently not succeeding because it's like a trademark term or something. But we've got a lot of libraries implementing the general principles. This turns out to be not just useful, but actually very powerful in developing clean applications using JavaScript. It's not just the idea of doing functional programming, so you can point at others and feel smug about them understanding what you're doing. But it actually turns out this is a great way to structure your applications. I'm going to show you the basic principles of it in a bit. I'm just gonna walk through the sort of technologies I'm gonna be using today. This thing called reactive extensions, which is not quite an implementation of functional reactive programming, but it's the one that's sort of taken off. It started in C sharp. It was invented by this fellow, Eric Maya, and at Microsoft and it sort of spread out towards other platforms. You got one for Python, you got one for Java now, and of course you got RxJS for JavaScript. Written by another fellow at Microsoft called Matt Podwisoki, and I seem to have got my images confused because that's pretty sure that's not him. Don't know who that guy is. So we're gonna be using RxJS to write our games. I'm also gonna be using ReactJS because that's the new thing right now for doing sort of functional programming. That's a UI framework. I'm not gonna be using the whole thing, I'm just gonna be using the bit that's rendering to the DOM, to the screen. And that's it really. I'm gonna show you the principles of functional reactive programming here. So essentially, at the core of it, is the idea of essentially a stream of data which in our act is called an observable. And this is asynchronous. Although as you can see here, you can create them from arrays, the simplest way of creating one. So that's not really asynchronous, that's just gonna feed us all the elements of the array. And I put six ponies in for you because who doesn't like ponies? And the idea is that to get things out of this stream, this observable, you can subscribe to it. And the subscribe method takes a function and it takes the variable p for pony and you can do things like console.logp and all the ponies are gonna come out. I made a cheat function for you which looks a bit prettier. It's just called log. So when I run this, I would expect all the ponies to come out of the stream. And indeed they do. You can't see all of them on screen at the same time. But we've got four of them at least, four and a half. And the interesting thing about this is you can treat it sort of like a JavaScript array. Like you can filter on it, you can map over it. You can do a lot of things. But I'm gonna show you the basics. I'm gonna map a function because I want to express my appreciation for ponies. So I'm just gonna go straight out and say that I love p and map that function over the observable. That's gonna have about the same effect as if you were to map over an array. So you can see we now love these ponies. But this isn't quite right though because some of these ponies are rather boring. So how about we filter out some of them? Applejack, who likes Applejack? So let's just keep the ponies, whose names end with an E. That's close enough I think. So let's apply a regular expression match on the P. Now we only love Twilight Sparkle and Pinkie Pie. That's close enough. Of course Pinkie Pie is best pony, but Twilight can get to be there as well. So that's a basic idea. But it gets more interesting because we, as I mentioned, these are asynchronous and we can actually extend them over time. Like I've created a stream for you right here which takes the observable interval constructor, which just takes a number of milliseconds. And what that will do is it would create a stream which every 500 milliseconds in this case, it's going to produce a number incrementing. It's gonna start at zero and then tick up one, two, three and so on. And I'm zipping that with our pony stream, which means that the stream that I'm creating using the zip constructor will wait until both of the streams that I'm passing in have yielded the interval and the ponies and then yield and then call this function to figure out what is going to output. And that's just, I'm picking, it gets two arguments, the values from the two streams. So the R in this case is gonna be the pony, so I just return the pony. And that should give us a stream which yields one pony every 500 milliseconds. It's about two ponies a second, that's pretty good. Yeah, and of course we can still do, we can still map and filter. Like, see now it's mapping asynchronously. And this one's interesting, if we now filter on pony standing with E, I'm starting it now, takes about this twilight in about two seconds, then pinky, and then we're complete. So you can see that all of the ponies are coming from the underlying stream, but we're filtering out some of them. They're still coming out at a rate of two per second, but this stream isn't actually yielding every 500 milliseconds. It's yielding whenever there is a pony that we actually care about. So that was the basics. What can we do with this? Actually, we can build a complete game. And I say, I've got my news out. Hopefully this is safe. So let's show you what I got here. I wrote some functions already which are just too boring to write on stage. First of all, what you're seeing on the right is actually a natural document. And there is an element inside it called the canvas, which is just a div, and it's got a background image, which is the sky of a sequestria at this moment. I've got this function here because one of the principles of functional programming is that we strive towards purity, which means that a function should not have side effects if you can avoid it. And we're going to try and stick to that. And more importantly, values, data structures, should not change at all. At least once you've returned them from a function, they're not allowed to change. So I've got this function here, which helps us cope with that. It essentially, it takes an object, it takes an optional other object, it merges the two and it makes a copy of it. So I'm going to use this to update my data structures, making copies so that we won't have to change them to update the game state. We've got this function on screen, which is just to determine whether things are inside that frame, essentially. And I've got this bind key function, which simply takes the name of a key and will return an observable stream, which will contain the name of the key whenever the key is actually pressed. So I'm going to use that for input. Okay. Now, first of all, we're going to have to get as a rendering function. I'm going to try and render the ground first. Well, so I think I should probably explain the game that I'm trying to make. You played robot unicorn attack. It's essentially, it's a side scrolling game with a robot unicorn running across the ground, leaping over obstacles, catching the stuff of dreams. So I'm going to, I don't really like robots and unicorns, I like ponies. So I'm going to try and do something similar, except with a pony. I'm going to have some ground just moving along. I'm going to have a pony running along the ground. Then I'm going to have things that she can jump and catch. And I'm going to have things that she has to avoid or the game will end. So first let's start with the ground. Oh, that's just a library I'm using for the, that's what gets me the keys. So essentially, if I call bind key space, I'll get an observable stream, which occasionally yields the word space. And the reason I can just go space instead of whatever key code that is, is my strap. It's just to help me a little. Okay, so I'm going to represent objects in the game by a simple data structure. I'm going to have a variable ground in which I will store the properties of the ground. First of all, it needs an ID, which is going to be ground. That's going to map to CSS class essentially. So I got some CSS already installed that, as you can see, which gets me essentially the images for the objects. So ground is just gonna be a ground texture. And it will need an X coordinate. I'm going to put that at 384. I'm also going to introduce the idea of a base coordinate. And I want this to be optional. So what I'm doing here essentially is that I'm saying that the axis for this object is offset by 128 of in that direction for the ground. Essentially what this means is when I render it, I take base X plus X, and that's where the object is going to be. This is going to be useful later because, well for one thing, I'm using this as an offset because the texture for the ground actually has an end point. And I don't want to render that. I just want to have the ground sort of scrolled by seamlessly, so you can't tell that. That is actually just really leaping back. Just gonna try and render this, and I'm gonna show you how to do it later. I need a rendering function. It's called makeElement. It will take one of these nodes, and it will return a reactDubNode. It's gonna be a div, and it's going to have a class name of node.id. I believe it also needs a key of node.id to keep react happy. And I'm going to add some CSS to position it, left, and it's going to be node.x plus either node.baseX if it exists, otherwise, zero, and then pixels. Do you see a problem here? Well the thing is, I'm not guaranteed because this is JavaScript, so we don't have integers really. I'm not guaranteed that this is gonna be an integer, and I believe that the pixels CSS style actually requires that. So I'm going to do a trick. This is like hardcore JavaScript optimization. How would you round off a JavaScript number to get an integer? Master round, yeah? Master floor, I'd say, to make sure it's just clipped. Yeah, it turns out master.floor or master.round are actually not very efficient. So this is the thing that they did in ASM.js to make it really efficient, because you have a bit-wise or in JavaScript and the bit-wise operations only work on integers. So if you just or, any number with zero, that's apparently a really efficient way of getting an integer out of a JavaScript number. So now you know how to make a choice really fast. That's node at base y, just doing the same thing here. Magic trick zero plus px. Okay, so this gets us a div, which I then have to pass on to react for rendering. The idea of react here is that you create sort of a data structure called a virtual DOM which represents what you want to actually put into the DOM. And then we have to tell react to please actually put that into the actual DOM. So I'll have a function render scene, which takes a list of these nodes and put them on the screen. Render component, actually it's not render, render, nowadays. Umdiv, which has no properties. This is just to contain our elements, nodes.map, make element. So what I did there is I took my list of nodes matted over make element, which turns every node in the list into a div. Then I pass this list of divs on to react at render. And I also need to tell it where to put it and that's gonna be my canvas, which I got earlier. So let's see if that still compiles it does. So let's just try and put that on the screen. Render scene, ground. Well, list of ground. Ah, that's the ground. Now we need to make it move. So this is where reactive extensions comes in. So this is just a static data structure now. But I need to turn this const ground into const ground stream, which is essentially going to create a stream of these nodes with a coordinates updating at regular intervals. So the ground will actually stop moving. So the way to do that is to create an RxObservable interval with a decent frame rate. Let's go for 33 milliseconds. That is, I think, about 30 frames per second. And then we map a function over that. A function which takes x, which is going to be the incrementing number. And then returns this data structure. Balance parentheses, okay. So at this point, I want to take this x and I want to turn it into an appropriate x-coordinate for the ground. So I've arrived at this formula through science, which means blind experimentation. X modulo 64, multiplied by a negative eight. So what this does essentially is, because we've got a number that starts at zero and increments by one every 33 milliseconds. And when it hits 64, I want it to wrap around and start at zero again. So I get from zero to 63 endlessly. And that's what the modulo does. And I take that number and I multiply it by negative eight, which means that it's going to start off at zero, then it's going to be negative eight, then negative 16 and so on until it reaches negative, whatever eight times six to three is. Then it wraps around, which will cause this texture to move gently towards the left. Then just before we reach the end of the texture, we loop it back to where it started. So it sort of looks like a seamless and less texture. So this current stream should do that now. Yes, which math function? Up here, from the interval stream. As I mentioned, this is going to be a number every 33 milliseconds, which counts upwards. So zero, one, two, three every 33 milliseconds. And I'm just taking advantage of the fact that this is an incrementing number to make the animation. So let's try and render this. I should be able to just subscribe to that stream. Oh, sorry. That's ground stream, subscribe, render scene. Does that look good? Trick question, obviously. Render scene takes a list of nodes. What comes out of the ground stream? Just one node. So I'm going to do some trickery here. I'm not going to subscribe to the ground stream. I'm going to subscribe to a constructor called zip array, which is sort of like the zip that I showed you earlier, except that instead of doing that function, letting me select which of the streams I'm interested in, it just gives us back an array of the elements of each stream, which is exactly what we want here, isn't it? So we'll just zip the ground stream. That's going to essentially turn the ground stream into from a stream of nodes to a stream of lists of just that current node. And that we can subscribe to render scene. So if this works, fingers crossed, the ground is going to start scrolling. And it does, cool. So we've got moving ground. We're nearly there. Now let's put some ponies on, shall we? I think it's probably time for that. Let's just move the ground stream a little down a bit. I have to keep this organized. I want the rendering functions on top and then I want the streams beneath here and the subscription right at the end. So I'm going to make, I should ask you by the way, do you have a preference for ponies in this case? No? Let's go for Pinkie Pie then. Pinkie Stream, because actually Pinkie Pie is saying a pony I would prepare it, so I don't really have a choice. First actually, I want to make a tick. Because I'm going to reuse that one of it. Just the same as earlier. Incrementing number interval 33 milliseconds. And I take that tick and in this case, I'm going to scan over it. The scan is sort of like reduce some JavaScript arrays. Except that instead of running through the entire array and then producing a result at the end, it lets me produce intermediate results based on the previous value of the stream. So the first thing it takes is the initial value of the stream. That's going to be one-on-one notes and it's going to be called Pinkie. It's going to have a base Y of 276 that puts Pinkie right on the ground when she's at Y zero. And she starts at X zero and Y zero. And that should do it, shouldn't it? So we need a function. And the scan takes, first it takes the previous value of the stream, of the scan, which is going to start out being just this node that I put here. And it takes the input, which is going to be, well, it's going to be nothing we care about right now. Let's just call it X. So, inside this function, I need to implement the game logic for Pinkie. So, I'm actually going to, let's just see if we can get her on screen first. So that's really simple, we just return P. And I need to add Pinkie to the zip array. Pinkie stream. And this is great, yes it does. Let's see, Pinkie bit, that's it. Excellent, we're getting somewhere. Now let's make her jump. That means we're going to need a physics engine. I've got 34 minutes left, that should be more than enough time. So I'm going to have a function called velocity, which takes a node, essentially. And let's call it node, let's make it readable. And I'm going to introduce some more values to the node data structure. I'm going to have a velocity, a VX and a VY for the velocity on each axis. And what this is going to do essentially is, let's say I make the VX1, that would move Pinkie one pixel forward, each tick. And the velocity function should apply this. So I'm using the source function that I showed you on top of that. My magical data structure function. Which first of all makes a copy of the node. And it also takes another object, which is going to be merged with the copy of the node. So I can use this to update the X and Y coordinates. It's current X plus, it's current VX is going to be it's new X. Likewise for Y, there we go. And now let's apply this to Pinkie. So we start off just by going P equals velocity of P. So that applies whatever velocity she has. And of course right now she has nothing. So let's add gravity. Let's apply gravity to Pinkie's position. So essentially every tick, we increase her downwards velocity by the value of gravity. And what is gravity at the Earth's surface? Yes indeed, 9.8 Newtons. So rounding that off to pixels, I'm making it 0.98. That's Newton to pixels. I think that's like mostly scientifically legit. All right. So now gravity's working on the, yeah. That's a slight problem. Hello, she falls through the ground. That's not supposed to happen. Actually let's do some BDD here. Going to outline the use case. As Pinkie pie given that I'm falling when I hit the ground, then I stop. We need to implement this. And that's fairly straightforward. Actually, we know that if her white corner is zero, that means she's on the ground. So we just have to make sure that it never goes below zero because that would make her actually fall through a solid object and that's not supposed to happen. So essentially, if her p.y is greater than or equal to zero, that means she's on the ground or below it. And she's moving downwards. Then we put her right on the ground at zero and we make her stop. So now she should stay, but gravity's still applying just so you can't fall through the ground. Which is going to matter because now I'm gonna make her jump. And to do that, I'm not gonna be using tick here. I'm going to be using, actually I'm gonna modify tick a bit. Instead of just this interval, I'm going to make it, I'm going to make use of the minor key function for the space bar, which is going to be the key that I hit when I wanted to jump. And I buffer that over the interval tick. So what this will do, the bind key, as I mentioned, is going to produce the word space every time I press the space bar. And what buffer does is that it collects each value coming out of the input stream, the bind key, every time this one yields a value. It doesn't care about the value yielded, just that when it happens, that's when we cut off the buffer. So what this will do is it's going to give us a list of all the spaces that were pressed inside of 33 milliseconds, which is usually either nothing or one, or if I'm really, really quick, it could be more than one. But the idea here is if I press space at least once in 33 milliseconds, that should be enough to make Pinky jump. So right now, I'm just gonna see that it's still working. Yes, it is. Except now this X is not the incrementing number, it's an empty list. And I'm gonna rename that to keys. And so when I hit the space bar, essentially if the first value of keys is space, then I make her move upwards at a decent speed, 20 pixels per second. Sorry. And let's play some sound. Soundworks. You've probably heard this sound before. Not very original when it comes to sound effects. So this is the idea. I set her moving at an upwards velocity. Gravity is going to eventually move that into a positive value, which means she's going to start falling. And then once she hits the ground, she's going to stop. Let's see. Yes, excellent. What's the problem? Oh, there she is. She can still keep jumping, even if she's not on the ground. She actually has to be on the ground to be allowed to jump, yeah? So we're going to have to change this a bit. We're going to have to check if Py is zero, if she's on the ground, then she can jump. It's not better. Okay. That sorts Pinky's game logic. Now let's make something that she can catch. So, I mean, given the sound effect, how about she catches coins? Is that seem reasonable? So let's make a coin stream. Oh, let's make an initial coin value first, just to keep it tidy. It's going to have the ID coin. It's going to have an X velocity of negative six, and no Y velocity, which means it's going to come scrolling across the screen to the left. It's going to start way off screen at 600 pixels, and it's going to be positioned just below the top of it. So the idea is that this point is going to start off screen, and it's going to scroll slowly towards the screen, eventually appearing, and then Pinky has to jump to catch it. Oh, this one's on, isn't it? So let's make the coin stream. No, actually, because this one needs to know where Pinky is, because when she touches it, it will have to change state. It gets caught. So I'm going to have to actually scan Pinky stream to do this. So same as previously for Pinky, except we start with the initial coin value, and a function which takes the previous coin and Pinky, Pinky's current node, because that's what we're scanning over, and we apply velocity, and so first of all, let's just get it on screen, and we also have to make sure that it restarts when it goes off the screen to the left. So I'm using my own screen function from up here, which essentially it just checks if the X-con is a bit off screen, and if C is off screen, then, sorry, if it's on screen, then we just keep returning C. Otherwise, we reset it to initial coin. So it's going to essentially loop back to its original position when it goes off screen. So let's see if it shows up. Oh, of course not. What did I forget? I have to add the stream to the zip. Now let's see if that's a coin. Now there should be. There it is. It's a Dosh coin. I can't catch it, though. I need to fix that. That's fairly simple, because I've written another function. First of all, if it's not moving upwards, this is going to be how I determine what state it's in, because essentially, in its initial state, it's moving leftwards, and when Pinky touches it, I want it to stop moving leftwards, and I want it to stop moving slowly upwards. That's like when Super Mario catches a coin. And then go off screen and then restart, and play a sound. So if the Y velocity is here, that means it's still not being caught. And I also made a function called intersects, which I haven't shown you. It's just magically in there. It's not very fancy, but it's just a lot of numbers. It's really boring. And what it does, it allows me to test whether two nodes are sort of touching each other. These nodes then actually have bounds because they're not allowed to read the dom. So I'm using an approximation, but it works out. So essentially, if she touches the coin, and the coin is still not yet caught, then make it caught. First of all, we play some sound. Hopefully you recognize this one, too. And we set her X velocity to zero and her Y velocity to negative one, which makes them move very slowly upwards. And if it is caught, then each frame we want to make its velocity a bit faster. Multiply by two each take, which means that it's going to start moving very slowly and then it's going to start moving faster and faster until it's gone. So let's see if that works. She can still jump. What's the coin? Where's the coin? There it is. I caught it. And it plays a nice sound and it moves off screen. And let's try that one more time. Cool. Okay, 20 minutes left and I'm nearly done with the game. Once again, it's a longer break. Okay, so one more thing I want to do, which is essentially just like the coin except the exact opposite. I want an obstacle, but she has to jump over otherwise she goes into the end game state. Essentially game over. I'm going to put that on top because in this case I need to pipe this one into Pinky because Pinky has to and it just wants to touches it. And it doesn't care whether Pinky has hit it, it just keeps going because it's just an obstacle. Actually just an obstacle. I think most people who follow My Little Pony on the Internet know that there is a problem with haters. Haters don't like people who like ponies. They're going to have a hater which Pinky has to avoid or she'll get very sad and go into game over. I'm going to scan the hater of a tick. Going to need an initial hater just like previously and the ID is going to be hater. Its velocity is going to be negative eight so it may be slightly faster than the coin. Same principle though. Source of screen. Why 300 that puts it on the ground essentially? Scan of the initial hater. Let's see in keys, we don't care about keys here. But the C, the H, it should be. H for hater. Same here. H is velocity of H and we just return H. Oh, sorry. Same thing on screen. H, then H as initial hater. There we go. Put the stream in the render thingy. So that should get the hater but now of course Pinky doesn't end game once she hits it. That's the hater just passing by. Now we have to make Pinky actually react to the hater. So I'm going to introduce one more value to Pinky, the game over flag which is going to be false and then obviously once she hits the hater that turns to true. And I'm going to need to change how I scan over Pinky a bit because now I need not just to track a key process with tick but I also need to know where the hater is. So I put the hater stream in there too and I scan over that which means that now I'm not getting just keys here, I'm getting keys and hater and I'm doing some ESXD structuring here. What I get as the second argument is a list and the first element is keys and the second element is haters so I just destructure that into the variable keys and hater, very convenient. So that should make us unchanged except now I can track the hater. So that goes first. If P touches hater and P is not in game over then P game over is true. PID is changed a bit because I want to ruin the game over stage and I change her animation. She just keeps running normally. That's just an animated GIF and when she goes into game over I want her to change expressions. Stop running, look very sad and then just as in Super Mario I wanted to sort of jump up a bit slower than usual and then fall down actually through the ground this time which is why I'm putting this in front of the normal loss of physics so I can override them just a bit but first I want to play the end game sound and then I want her velocity to be negative 15. So a slightly less forceful jump and if I'm in game over every tick I apply a slightly lower gravity of 0.5 and then I actually exit. I skip the rest if she's in game over so bypassing the loss of physics essentially. So let's see. It's hard not to jump across the hater. I might need to jump because I don't like it. Let's see if it actually goes into game over and does what it's supposed to do. So that was the game. One more time. That's the hater. I can keep playing this forever. It's remarkably addictive for such a stupid little game but that was the game. I don't know how many lines this is, not a lot and it's actually completely pure functional programming. The non-pure bits are handled by Rx and react for us. At the end is the only place where I'm actually causing side effects. That and the input event from bindkey. So all of this is just functions which are entirely predictable. They take an input value and they output an output value and the output value is always the same given the input value which is about as functional as programming can get. This isn't entirely true. There's the matter of playing the audio which is actually a sound effect. You can get around that. It's boring. So I've cheated just a bit there. But mostly, what I've shown you is some basic functional programming principles that actually make sense and turn out to be very useful in JavaScript at least game development. So to apply this to URI programming as well and you can certainly apply it to backend development these streams are really cool for doing I.O. and database queries and especially tracking message buses, for instance. So that was it. That was the game in JavaScript in about 40 minutes. Concluding, here's my cheat page in case I'm officially messed up completely. This is just the game. This is just the game. It's hard not to play. So what you're seeing is RXJS. And that's the URL for that if you want to take a look. I also want to mention some alternatives to RXJS. There's this other thing called Bacon which it's a different take when essentially doing the same thing. The advantage of Bacon practically is that it's a lot smaller than RX. The advantage of RX is that it's more complete. It allows you to do a lot more just out of the box. Which one is better? Depends on the situation. Depends on your personal tastes. You should check out both. They're very cool. Finally, I'd like to tell you about this other thing called Elm, which is not just a reactive library. It's actually a language. It's sort of like... Imagine if you got Haskell, except it was designed by the usability experts at Alkohol or something like that. It's sort of Haskell without the scary bits. It's composed of JavaScript. It's built completely around the principles that you just saw of purity, mutability structures, and reactive programming. It's really, really cool. And it puts the front back in doing type functional programming. And it compiles very nicely and cleanly to JavaScript. It sort of masks out the bits of the DOM and whatnot that I was using React to not have to deal with right now. So if you want to try something slightly unusual and very, very cool, you should check out Elm. And that was it for me. Thank you very, very much. I should mention my slides are actually just a web page. And if you go to this URL, you actually get the whole editor that I was using. You can play the game. You can write the game if you want. And just generally play around with that. Okay. Do we do questions? All right. Any questions? There's a question slide. I think it is way too early for questions there. I think we are in agreement. Cool. Then I guess we'll take a break. Or do you want to do the introductory talk straight away? All right. I'll leave the stage to you.