The Art of Functional Programming

Oh, my goodness! We're in three dimensions! I'm really excited about it. I have missed you all. It's great to see you. See you. See you. Very far away. Very far away. I'm really excited to see everybody virtually tuning in at home.

My name is Anjana Vakil. I am here to talk to you about React. Just kidding. No. I'm here to talk to you about functional programming. Which is sort of related to React, because it is the programming paradigm behind the way that we work with everything in a functional framework like React. So I want to talk to you about functional programming, because I think that it is a really beautiful paradigm. A really beautiful way of understanding what programs are, what entities they're made up of, how those entities behave and interact. In other words, a programming paradigm, that I think is pretty great. And I don't think I'm the only one.

Because functional programming has some really nice characteristics. So first of all, functional programs are really easy to predict. They're very predictable. Which means that they're easy to test to make sure they're doing the right things. And they're easy to debug to make sure that when they're not doing the right things, we find out why and we fix it. And so that is why as programmers, I think we should most of us find functional programming pretty easy to love. Give it up if you got some love for functional programming. Yeah. Functions. Functions. Whoo. But I actually think that functional programming is also pretty easy to be scared of.

Give it up if you got some fear for functional programming. Yeah, me too. Me too. Exactly. Because it's got this reputation, which is unfortunate, but probably pretty well deserved of being this very opaque kind of academic scary world full of weird words, like terms from category theory and stuff like that, that you need a Ph.D. to understand. So it's pretty easy to be a little afraid of.

I think that functional programming actually in its core principles can be really simple to understand. And so I kind of make it my mission to try to make functional programming more accessible. You might know me from this talk I gave called Learning Functional Programming in JavaScript. If you haven't encountered functional programming before or if you know somebody that hasn't and wants to, check that talk out. It goes into a lot more about how functional programming really works under the hood. And to go even deeper, you can also check out a course I have on frontend masters called Functional JavaScript First Steps. This talk is not going to be really going into the details of how we do functional programming except in so far as to answer the questions of how we do functional programming in the real world.

So what is functional programming just in a high level? Well, it is programming with functions. That's super insightful. My talk is over. Bye. Okay. So just kidding. Functional programming is programming with functions, as you probably know. In fact, it's programming with a special type of functions called pure functions. So what is a pure function? Well, a pure function is a function that turns input into output. You give it input values and it returns an output value. And that is literally all that it does. It returns an output based on its inputs. So you maybe give it a width and a height value as inputs and it maybe returns that aspect ratio by dividing them as its output. Very simple, very predictable, because that means a pure function is totally deterministic. So if you give it the same inputs, it will always give you the same output. And that's because it doesn't involve any kind of state.

Where state is values changing over time, those don't exist in the functional programming world. So any time you call a function with the same inputs, you're going to get the same output. So deterministic, safe, predictable, makes programmers happy.

So this also means that pure functions can't do side effects. So a side effect is anything the function might do that is not returning its return value. So that means there's a lot of stuff that we're usually used to doing that we can't do in functional land. We can't, for example, log to the console. That's a side effect. That's not returning a value. We can't touch the DOM. That's a side effect. That's doing something other than returning a value. We also can't even look at what's in the DOM or look at the state of the world outside of our program. For example, by checking what a certain element has as its value for a certain attribute. Because that would be looking at something other than our inputs, and that would mean that that could change, and you could call the function with the same inputs and still get a different result. Can't have that.

So no logging things, no touching the DOM, no even looking at the DOM or anything else outside of the inputs. Every function has to just look at its inputs and just return its output. Okay. We're all on board, right? Yes. Yeah. Cool. So that means we can do nothing. What can we do? If we can't touch anything, we can't, like, affect anything in the world, all we can do is return values. What are we supposed to do? Well, so functional programming can do whatever we need it to do, but we have to get used to some techniques for kind of relating to the real world and still keeping to our functional pure kind of deterministic world here. So this is what we're going to be looking at today is how does functional programming work in the real world and not in the nice little academic math-y circles where it exists on like this other plane of reality. But in our world where we want to draw things on screens, for example. So how about we draw some art on the screen, yeah? Woo! Okay. So we're going to make some generative art and look at how that helps us understand how functional programming relates to real world trying to do things, because making generative art I think is a really good example of doing some things that functional programming often feels like it isn't really capable of doing or very good at. So generative art usually needs some kind of side effects.

If you're trying to make art, you've got to draw some pixels on the screen at the very least, right? You're probably going to need some element of repetition. You're going to want to have recurring motifs in your artistic work. You might need some representation of state, because maybe you want to be altering different parts of the image in different ways, changing values, right? But we don't have state, so how do we do that? And you're probably going to also want to include some element of organic seeming variation, so usually generative art involves some aspect of randomness.

Guess what randomness is? The opposite of deterministic, right? So how do we deal with all of these things in a functional universe? This is what we're going to be looking at today, and along the way we're going to make some pretty pictures. Yay! All right, let's do it.

So, side effects. How does functional programming handle them? Well, it doesn't. What we can do, though, when we need to do side effects, like, for example, drawing something on the screen, touching the DOM, we can take those side effects and push them to the very, very outermost edge of our program. So we can sort of create, like, you can think of it as a protective shell around our program where all of the messy side effecty imperative stuff can live on that very outermost edge. And then inside of that, we can keep all of the internals of the program pure and functional, so deterministic, so safe, predictable, testable, debuggable.

So what we want to do is push all of the messy side effects out to the outer edge, the imperative shell, that will wrap around a pure functional core. With me? Let's look at what that seems like in real life. So here's an example of, I have a simple little SVG that I'm calling art. We'll see if that holds true once we see what art we draw. And what I've got is a function that is not a pure function. So I'm calling it impure set SVG contents. Which that's going to do is do all of the side effect stuff. It's going to grab my art element out of the DOM. It's going to quick and dirty set its inner HTML to basically do a side effect here, to change something in the document. And that's basically going to be our outer imperative shell. So this is not functional code. This is not pure. It's impure. But everything that happens inside of it, what we can do is we can use pure functions to generate the art that we want to stick in there. Inside of that nice little shell that's doing the side effects for us. So what I can do then is get a pure function, which I can call get art, that will take in whatever parameters I need to give it, and then create the contents in a pure, deterministic way, which my impure SVG contents will put onto the page in a imperative non-functional way. Cool? All right. I see a few nods and a few people still waking up after coffee. I'm with you.

So let's make some patterns, and maybe that will be a good way we can fill in our contents from our little imperative shell program. So patterns are fun for generative art. So how can we make patterns where usually patterns involve some element of repetition? How do we do repetition in functional world? So in functional world we don't have state. We don't have values that can change over time, which means we also don't have things like for loops, right? Because a for loop means you have some kind of value that you're going to increment or change on each loop that you go through. So instead, what we're going to do is instead of this imperative way of thinking about repetition as a form of iteration, in functional land we're going to think about repetition as a form of recursion. So recursion is going to be the subparadigm that we use to achieve repetition in functional programming.

Probably not super new to folks, but it's actually really interesting how iteration and recursion relate, or at least I think it is. I have another talk where I go into more detail about how these work in JavaScript and how they relate to each other. If you're curious about iteration versus recursion, they're not actually enemies. You can check out my talk recursion, iteration, and JavaScript, a love story, from JS Heroes 2018. But suffice it to say today we're just going to stick with recursion, so how does that work?

Let's try to make this a little pattern with these kind of successively smaller and smaller diamonds or squares. What we can do is create a recursive function to draw this pattern. I'll call it get pattern, because I'm great at naming. And this will take in a couple of colors and then a certain width for how big we want this pattern to be. And like any recursive function, this is going to be a good recursive function that doesn't blow up my computer, because it has two parts. It has a base case where there's actually no recursion happening whatsoever, where, basically, if I have a small enough width, I'm just going to return a rectangle of a certain color, whatever the first color is, and that's it. I'm going to be done. No recursion. However, if the width is bigger than that, then I'm going to make a recursive call in my recursive case. I am going to not only give back a rectangle or a square, in this case, of a certain color, but also rotate a little bit and then use my same get pattern, with the colors swapped, to generate a smaller rotated pattern of the same structure with the opposite direction of colors. And by recursively calling itself and itself and itself, we're going to get this repetitive, trippy pattern drawn. Simple recursion. We're with us so far? We're good? I see thumbs. Excellent. Thumbs from the live stream. Excellent. All right. Fabulous.

Now, this was kind of a simple example because this pattern looks recursive, right? It seems to be recursive. What about a pattern that doesn't really have that vibe to it? What about a really standard grid? How would you draw a standard grid if you can't use a for loop? If you can't use iteration. I'm going to let you ponder that while I take a sip. How would you draw this grid recursively? Okay. I can't hear anything that you're saying, but I appreciate you. So let's look at one way that we could do this. Which we'll see, if it was what you said, you can just yell yes. So what we can do is start with a base case where we just draw one tile.

Just one tile. It's not so much to ask for. And then what we can do is check. Are we trying to draw more tiles than this? Do we have more columns and rows to draw? And if so, then we can treat those as smaller grids and we can recursively draw grids.

For example, we can draw one recursive grid that goes to the right. That kind of draws the rest of the row after my little base tile. And then we could do another recursive case where we draw all of the columns and rows below my first row.

So this is what that might look like in code. I know this is a lot. Bear with me. But what we've got is a base case where basically we're figuring out from the width and height that we want and the number of columns and rows that we want, we're figuring out what the width and height of this particular tile should be. And basically, we're returning that. And if we don't have any more columns or rows to return besides just one, then we're done. But if we have more columns, that means that we need to draw the rest of the row. So we're going to recursively call this function, which I've called getTiles, to get this little tiled pattern. We're going to call getTiles to draw everything to the rest of this row to the right. Basically drawing another tiled area that's just of a reduced width and only one row. Cool? And then what we're doing is, if we have more rows below that to draw, we're doing, again, another call to getTiles with a reduced number of rows and all of the columns, so basically drawing the entire rest of the owl. Cool? All right.

So what we've got then is we can use our getTiles function. And what we're doing is we're passing in a little makeTile function. This is also very functional vibe, right? Passing functions around. Because then we can change what that makeTile does to draw different things. Right now, I'm passing in a very basic tile that's just drawing a little orange rectangle. And so this is what we get. We get our nice 5 by 5 grid, when we call our getTiles with our makeBasicTile function. Yeah? Cool. Now let's try to do something more interesting.

All right. So to do something more interesting than having just the same square repeated over and over, we're going to need some notion of state, some notion of a value changing.

Right? But we don't have state. It's functional land. All we have is values. They don't have time. Every call to every function that we make with the same values is going to give us the same thing. So how do we handle state? Well, what we can do is represent the state that we care about with data. And on a certain call to a function, we're going to pass in whatever inputs the function needs, along with the current state of the world that this function might care about. And then what we can do is return not only the output value of this function, but also an updated new object. Not the old object modified, but entirely new object that represents a new state of the world in case it has changed. So by treating state like data and treating it as part of the return value and the input can keep track of where we are in the image or in time or in whatever we're trying to do. In this case it's going to be where we are in the image. So let's try to use this principle to draw a slightly more interesting piece of art where we have a checkerboard. Now I'm using the same get tiles function where it's going to draw a grid. But this time instead of passing in my basic tile I'm going to pass in a checkered tile where what we're going to be doing is passing in an array of colors and keeping track of state, in quotes, with an index that's going to tell me which color I'm currently on. So I'm going to be then changing that index in the new piece of state that I return out of this function which I can then use to pass into the next call to this function and start with a different color. So if I pass in two colors, this is going to flip-flop between them. And if I pass in a longer array, it's going to rotate one after the other through them. Cool? So we get this checkerboard pattern. With me? Okay, all right.

So it's like, cool, we can play checkers, I guess. But what else can we do with this? Well, I don't know if you've noticed or if this reminds you of anything, but we can actually make fashion y'all. Whoo! All right. So, I don't know if folks at home can see, and I apologize for the geometric chaos of this outfit. But do you like my outfit? Thank you. It's functional. No, so I found these, I found these pants in a shop in Budapest Hungary recently called Palmetta Design, shout out to the designers of the world, making it happen. And I, of course, was like, A, I need these pants, B, I need to figure out how to make this pattern. Which is what I'm going to make you all do right now. So, this is basically the pattern that we need to make some dope fashion. How would you make this using nothing but what we've seen so far? Oh, we're thinking, we're thinking. I see a lot of scratching, I see a lot of nodding, I see a lot of eh, all right, let's see.

So, because what we've got is something that's a little bit off-kilter, let's first of all take this and notice that if we were to rotate the whole thing or un-rotate it, we would get a more regular looking grid. And if you notice here, this is actually the same tile, the same pattern repeating over and over. So, let's take a look at one of these chunks of pattern and zoom in and do you notice anything? This is four different checkerboards. So, what we've got is we've got a big square checkerboard, which we already know how to draw, then we've got kind of a narrow smooshed one and a wide smooshed one, which are starting with the alternating color so that they line up nicely with the alternation. And then we've got another small square one. So, we know how to draw all of these four different checkerboards. We already have a function that does it. So, what we can do then is take those four checkerboards and smoosh them together into a single tile and use that as the tiling function that we pass in to our getTiles. And then we rotate the whole thing and we're done.

So, here's a bunch of code. But basically, this is just doing exactly what I just described. So, what we've got is we're just picking a ratio of how far we want that wide, narrow split to be. We're figuring out the dimensions and then we're creating like the big square checkerboard, the smooshed narrow one, the smooshed wide one, and the small square one. And we're basically just concatenating them all together in one big return value. And then the only piece of interesting change that we're doing is we're checking whether, based on the number of tiles in one of those checkerboards, if it's even or odd, we're going to decide whether or not we need to flip the first color so that everything lines up nicely and we get the alternating pattern. But this is basically it. So, what we've got now is some wearable functional programming. I'm pretty proud of us. I don't know about y'all. But yeah. Whew!

So, the time I am not sure of now because I don't have it, but I am going to press ahead because what we've been seeing so far are things that are really regular and really predictable. So, let's now try to make things a little more interesting by adding some irregularity. How do we do that? How do we add a little bit of organic variation to our art? How do we incorporate randomness is what I'm asking you?

So, how does functional programming handle randomness? Well, you can probably guess. It does not. We do not do randomness in functional programming. Because if we did, then we wouldn't be able to predict what the return value given certain inputs should be, right? And that would break our entire brain and all of the wonderful advantages of predictability and debuggability and testability.

So, we're going to do the same thing every other piece of computation does because actually all computers are deterministic even when they're pretending not to be. And we're going to use pseudo-randomness. Where we're going to generate values that have the same distribution as random values, but we can actually predict which values we're going to generate based on a seed that we give to a pseudo-random number generator. So, the random number generator that we can use, the pseudo-random number generator could be something like simplex noise. Simplex noise is really cool for generative art, because basically what it does is it generates a field of values, like a grid of values for you, which if you zoom out and look at it on the large scale, it looks like totally random. But if you zoom in and look at a smaller portion of the noise field that it generates, actually you can see that the values are related one to the other, so you get this nice kind of organic smooth transition from one pseudo-random value to the next. So this is a really handy algorithm for doing generative art. And so what we can do is we can get a simplex noise package from a very impure source of the outside world, but then what we can do is we can impurely grab a noise field that is going to predictably give us the same random values. So how this works is if I instantiate a noise field with this algorithm, with a particular string as a seed, I get a certain 2D grid which I can then query at a certain point and get a certain value. So I take my 2D field. I give it an x, y coordinate and I get a value out. And if I generate this field with a different seed, I'll get a different value. If I generate a new field with the same seed, I get the same value. So this is deterministic. It's pseudo-random, it's not actually random. But for our purposes, it works just as well. And so what we've got now, we can do like a make random tile function, where I'm gonna pass in the noise field as data that this cares about and some colors and an index for each tile to represent each tile. And then I'm gonna use that tile index to figure out a particular specific random value from the noise field that will represent this tile, use that to randomly choose a color for this little tile, and then increment my tile index on each call to this function so that I'm getting a different value for each different tile. And what this gives me then is a kind of noisy but chosen out of the colors that I picked kind of noisy field. And where we can take this then is to actually start randomly changing or jittering some property of our art based on these values that are pseudo random but different enough from tile to tile, that they look random to us, to our silly human eyes. So what I've got here is I'm drawing these little clocks. Each of these tiles is going to be a circle with a particular color and a particular clock hand that's rotated a certain number of degrees. And all I'm doing is using the same concept, using the tile index to figure out a random number of degrees to rotate this tile. And in this case I'm actually not choosing a random color.

And in this case I'm actually not choosing a random color. I'm alternating the colors, same as we did in our checkerboard, to create this kind of nice repeating but also random pattern. So this is an example of how we can even in a pure functional world incorporate that organic variation and pretend that we have randomness.

Okay. I'm super overtime. So let's recap real quick. Look at everything that we did. We figured out how to do side effects. We actually drew some stuff on the screen by putting it all in an imperative shell around our pure functional core. We figured out how to do repetition. Always with recursion. We don't need no for loops here. We're fine. We got recursion. We figured out how to keep track of state by basically just treating it as more data and making sure that if we need to change something in the state we return new data instead. And we figured out how to deal with randomness by in our imperative shell generating a field of values which we can then use to simulate randomness in our programs.

So we have just done a lot of functional art. Be very excited and proud of yourselves. I think we did a great job. You can check out the code for these examples on observableHQ.com. You can follow me on Twitter.