Functional Programming in 40 Minutes • Russ Olsen • GOTO 2018

Thanks, I'm Russells and I want to talk to you briefly about

functional

programming

this morning. I'm kind of an expert in

programming

languages. I've been learning programming languages ​​and occasionally writing books about them for most of my career and lately. I've been doing

functional

programming, so a couple of things about this talk before we really get started. You might be thanking functional programming in 40

minutes

. How are you going to cover functional programming in 40

minutes

? And I'm thinking, what am I going to do? What do I do with the last 10 minutes because I think the whole point of this talk is that functional programming has been bewildered and people get very excited about new technologies or technologies that are new in themselves and start talking about them in very expansive terms about how it's going to work. change everything and in fact, functional programming really is a fundamentally simple idea and that's what I'm going to try to convey this morning.

I want to warn you that I am a closure programmer, so my functional programming style is closure, so necessarily my point of view and what I am going to tell you will have a kind of closure twist. I'll try to point out places where this is the way closure does it and other programming languages ​​do it differently. but keep in mind I'm kind of a closing programmer so I really want to cover three things this morning and really one main thing and the main one is what is functional programming, where does it come from, what are the ideas behind functional programming , as. we get to them and that's most of what I'm going to talk about this morning and then from there I'll move on to what it's like to be a functional programmer, what it's actually like to do it, and in particular what I like to do as a beginner.

I may be from the object-oriented tradition and start programming in a functional style. What is that light like? That transition and I'll finally try to answer the question, which is maybe a little subjective. Can you make it work? I'm kind of a hands-on software engineer. I write applications for my day job, so this will be a kind of functional programming for you, not for ordinary programmers who want to do it. It writes applications and libraries, so let's start with what it is and what there is. When I first got into functional programming, you know, you Google functional programming, how do I learn functional programming?

And there was one thing that I saw over and over again and that is functional programming forget everything you know about programming or worse yet functional programming forget everything you think you know about programming yes I think software developers programmers here happen to know quite a bit about programming what we know about programming we know about things Programs are full of names and you assign values ​​to those names. Programs are full of conditional logic. They are full of iterations. They're full of procedures and subroutines and things like that. There are all kinds of data types found in every programming language. strings and boolean there is one raised and hashes or maps, another if you are doing object-oriented programming, then you have classes, inheritance and methods and finally we have the correct programs and this is, I don't know everything we know about programming if we are doing object-oriented programming, Are we going to forget about all this?

Are we going to forget about the real comments? No, of course, it's not what we really want to do with functional programming. I think it's more of a refactoring, okay and it's more like I'm going to take some of the things I know about programming and keep them, but I'm going to refactor my ideas about how to program, so I think about it, I imagine you're working on some common and common application. I don't know an accounting app and I apologize to people who actually work on accounting apps. I think they are boring applications, but some application and maybe your application has a design, there are a series of modules or services and they all go together in a reasonable way. well, it's not perfect, but it works and it's fine, you have a pretty good design, but time goes by and requirements change and you start fixing bugs and maybe add a new module, rearrange things a little, maybe add another one, maybe you will fall apart. of a couple because you don't need them anymore and then maybe you start adding dependencies that didn't exist before, this is what happens in ordinary systems as they go through their life and after a while you start to develop what we technically call is a disaster, it gets to the point where it works, but it works, but it's hard to explain, it works, but the next bug you have to fix is ​​actually much harder to fix and then it should be and you spend a lot of time.

You know you're in this situation when someone says how does this work and you're like, well, it works this way, except when this happens, except when you have this, except on Tuesdays when it's raining, you know we've all been there, right? It just works and maybe users or customers like it, but it's getting difficult and complicated, so what do you do in those situations? I have my counting system and it becomes a disaster if you do that. You're lucky your boss or maybe you whoever is deciding you sit down and say I'm starting with a blank sheet of paper I'm starting with the completely blank sheet of paper as if that's the funny thing about the blank sheet of paper let's redesign the system there is a blank sheet of paper what is the first thing you do when you redesign something from a blank sheet of paper?

The funny thing is that you collect all the pieces that already work well. Nobody you like rewrites something from scratch. every line often when you're rewriting a system, refactoring, redesigning it, what you do is you incorporate all the pieces that you say, oh, this piece works well, it's just not in sync with everything this other piece works well, maybe I'm going to change them a little bit, but there are pieces that work well, there are pieces that you throw away, certainly, but there are pieces that you keep, so you have all these pieces that work and what you're saying is that the reason my design doesn't work is because the pieces I don't have a primary idea of ​​how they all go together.

I need a paradigm to put this system together, so a redesign is mostly or a refactoring is mostly, let me rearrange the pieces I have, maybe add some new ones eighth. a new paradigm, so maybe in our accounting system we have a message bus, so we put all our pieces together, but we have this new idea of ​​organization, it's a message bus, what about programming? And by programming I mean something like traditional. The conventional type of object-oriented programming is that getting dirty needs refactoring. I think maybe so, so you remember I said, "Oh, it works this way, except for Tuesdays, Thursdays and Saturdays." That's one of the signs.

Well, this is from the Java tutorial. during the runners type process it first binds whether the type parameter is bound or is an object as the type parameter is not bound right? It has that feeling of ad hoc Ness that you know is what happens on Tuesdays, Thursdays and Saturdays and it is not my intention to choose. In Java, I think this has been kind of a sign that maybe object-oriented has gotten to the point where it doesn't work for us anymore. One thing I'm sure of is that if they ever build the monument to programmers, Software Development may be a giant statue of a keyboard or something.

There will be a plate at the bottom. One thing I'm absolutely sure of is that those words won't be on the board right now, but it's not just Java. I quite like Ruby and here. is a description of the hell-protected methods that work in Ruby, but the receiver is always itself, it's either the lookup class or an object, it's a bit complicated, but for the latest on this sort of thing, just look at the C++, which is quite complete. of complicated rules like this, okay, maybe our object-oriented approach to programming has gotten a little complicated, maybe we need to do something else, maybe we need to start with a blank sheet of paper, and if I have any sympathy for forgetting everything.

You know, about programming, you start with this blank sheet of paper, except the first thing we do with a blank sheet of paper is incorporate all the things that work correctly, the idea of ​​a program or service works, we can keep those namespaces working or increase work now maybe we're going to change these things a little bit as we go, but everything works, we're not going to throw away the idea of ​​a string in functional programming, you don't have to forget everything, so Just like our accounting system, what we are looking for is a new organizing principle, we need a new paradigm to bring all the things that work together into one functional whole, so where can we find a new paradigm?

Well, it turns out that there is another group of people, there is another group of people who were doing work very similar to the work that we mathematicians are doing now. No, it wouldn't be a surprise if I told you well that there is a huge overlap between computer science and mathematics, I think computer science. Science is probably a subbranch of mathematics, but I think what the software developers we work with don't really appreciate is that mathematicians, the people who do really serious things, have the same kinds of problems that we do, so If you've ever liked designing the system and you say oh I'm going to have this abstraction and that's going to be part of my system and I'm going to have this other one and I'm working up to a point where I want to have my system do something and then you have five or seven abstractions and you're trying to keep them all in your head, you're taking notes and writing all over the board trying to keep all those abstractions together until you get to the point. where you have done something that is functional well, mathematicians do more or less the same thing at least the abstract ones this is the cover of a book called principia mathematica that was published in the early 20th century by two British people and what they were trying to do was I do is derive all mathematics from very simple principles, right, and let me tell you, this is serious business.

Let me also tell you that I have never read this book, so I don't intend to, but it's just page after page after page of the most ridiculous abstractions you can imagine until you get to this page and on this page in the middle of this page they prove something. really interesting. One plus one equals two. Now you think your life is hard. Shame on the mathematicians because the significant part is two significant things. on this page one plus one equals two and the page number look at the page number is three 179 it took them 379 pages to prove that one plus one equals two mathematicians have the same type of problems they have these abstractions that they are trying to drive towards some goals something in this case one plus one equals two well, is there something we can borrow from mathematicians to help us?

They have some organizing principle that will help them do their job that maybe we can steal and the answer is yes, they have functions and you say, well, we have functions, subroutines, procedures, methods, it's not the same as a mathematical function it's a relationship between two sets, okay, there's an input set and an output set and it's a mapping from one to the other okay, there's no time involved, it's not like you mathematicians in principle compute a function, actually right, this is a very abstract thing, so this could be the function for like double the number, one goes two, four goes to eight, that kind of thing. now these things are different the mathematical idea of ​​a function is different from our idea of ​​a procedure method a subroutine or a function those things we have because our things are code there is a mechanism and in principle our subroutines procedures functions can delete a can update a database, they can calculate some result from the input, they can change the input, they can't calculate anything, they don't return anything, well, we can do whatever we want, it's just code and it's not exactly the same as a function math.

The mathematical function is always the same for any given input, it always gives you the same result, it's not that five can give you a 42 on Tuesdays, Thursdays and Saturdays and not at other times, that would be a different function and, in particular, not change. or time mathematical functions, you know, it's summer, rain, spring, it doesn't matter, they are always the same. Mathematical functions also exist, right, they are values ​​that you can manipulate and if this were ten or fifteen years ago, I could go. In a long talk about first class functions, I think first class functions leak into all major languages.

A function is something you can do or really a procedure, a subroutine, you know, ourcomputer and things are also things. that you can make their values ​​that you can pass first class functions in a programming language, and what if we wanted to borrow this idea of ​​a function from mathematicians? Well, we can't really like to borrow it because there's something completely different. abstract, but we can have a bunch of rules in our functions that make our functions act something like mathematical functions that people call functions that behave according to these rules pure functions, it's not a term I really like because it's kind of as well as good, bad, you know, and this is just an engineering decision, so what would happen if we just made them completely? arbitrary rules and apply them to our programming stuff and the main rule is that you only look at your input, you only look at the parameters and it only produces output, it only produces the result, okay, so what does that mean?

Don't change anything. no side effects, no going in and changing the 4th element of your array, if there is an array parameter it means you shouldn't delete the file, update the database, any of that, just look at the parameters and transform them into some result , all good, we are doing it. This is in the hope that it will make our programs easier to write and understand and that is the only reason we do it. It's not a good, bad thing, we just do it in the hope that it will make our programs understandable. Well, would it actually make our programs easier to understand?

Well maybe and this is why let's say we start with the three element array X and we call some function on of that function now the question is what is functions in X, right, just an absurdly complicated sequence? of functions to calculate Y, what is X, it's the same thing, you can see how these rules can help you understand your programs, right? It had this what I call a bunch of features. I still have the same thing. I don't have to go through 25 pages of code trying to figure out if some put something in the middle of of our current programming language that we think might work for us that we think are working right now and now we're going to incorporate these special rules for functions and see where that takes us, so we think about that for a while and then we have a problem and the problem is that in most programming languages ​​data structures like arrays and hashes or maps and lists and things like that are mutable, so if you had a small array of three elements any time you wanted, you could look at that middle element and insert some other value into it.

You can mutate your matrix. That's a problem because if we go back to our example and we have that incredibly complicated functional expression in the middle and we change it a little bit. that we just introduced a new value in To solve this particular problem, let's make all of our data structures immutable. Once you create that array, you can't change it. Once you make that hash, your map, you can't change it, we're just going to make them. completely immutable, you can see how that solves the problem. Now I can't change any of the data in my data structures, but you might think well, how can you do anything if you don't like mutating anything?

The answer is actually quite a bit. Simple, we provide all of our data structures with an operation that says: give me a copy of yourself, except it's the same as you, except a little different, so give me a copy of yourself, sir. ABC array that is exactly like you, but the middle element is Q, if it is a hash or a map, give me a copy of yours that has all the keys associated with the same values ​​except this one which is different or this new one, or delete one, okay? so we do that and now we don't have to worry about anyone changing or data being deleted from under us, but now we have another problem and that other problem is the correct copies and it could be framed this way, what if I have a million? array of elements and I want to change three elements in the middle.

Do I change the first one and make a copy of a million items and then change the second one and make another copy and after a while I have three or four million items? arrays that I've created and things like that turn out that no, you don't have to do that, so there was the problem, right? I'm going to copy. I have a 27 LM array here that I'm trying to mess with. the element in the middle I have to copy all 27 elements turns out we can do better than that turns out some very smart people have come up with something called persistent data structures and here persistent doesn't mean saving to the database or saving to a file it's just an unfortunate word they chose for something completely different, but what persistent data structures are are their versions of all the familiar data structures, like arrays, hashes, lists and trees, and all that, there's basically one for everyone familiar . data structures and they are there, they have two key characteristics: one, they are immutable and two, they support this VIP, this copy in the modify operation, but they do it very efficiently without much copying, which seems ironic because of the way that works, think about that. that 27 element array, what if you implemented that 27 element array?

I guess all the letters of the English alphabet and the exclamation point, what if you implemented it as a kind of tree and each node in the tree has kind of three slots, so each node? has is like a block of three and that block of three, if it's an inner node, it points to something or if it's a leaf node, it actually has the right data and that's how I represent my array behind the scenes. well if I want to get to the twenty second element I just have to traverse a couple of nodes and I'm there at my twenty second element but what if I want to modify this which really means making a modified copy of this let's think about how many copies we really have to do right if we want to modify the middle element there, obviously we would have to copy that little block of three nodes there, we would have to copy the one that we set at the point We would have to copy the one that points to it and then we don't have to copy anything more because we can reuse everything else from the old from the original so you get this.

The new and the old one share most of the data. particularly as the data gets bigger and bigger, which is exactly what you want now, you might be thinking, but what if that data in the above changed this from under me? Everything is immutable, so you see how this all crashes. together, okay, so I think that solves our problem of immutability and principle. Now I'm showing this as three elements but really that's just to see it on the slide, in real life people tend to use more like a branching factor of 32. so all the nodes are 32 wide and if you do the Calculations turn out that a three-element tree like this 32 nodes wide can support over a million elements, so it's actually quite efficient if you put your mind to it.

Well, here's my Hokey icon, it's a lock for immutable data structures, so now we have everything that we borrowed from our original language, we have these pure mathematical functions and we have immutable data structures. now we've built this beautiful functional world, we've built this beautiful functional world where there are no side effects and it's easy to think about the programs because you never have to dig deeper to see who the hell is changing my matrix and now we have another problem and that other problem has to do with those side effects we got rid of. Look, if people still use two business cards, I would print business cards and have my name on them and me and the only thing that is the business.

The card would say they are side effects, if you think about what a side effect is, like writing a file or deleting a file, updating a database or accessing some services. Side effects are what we get paid to do all the things our customers care about. side effects our client doesn't care about our code, right, we care about the code, we want the code to be easy to understand, fundamentally, the person behind that accounting system, the banker or whoever, doesn't care at all about the accounting system, they care that the database is updated, reports are generated, files are created, services run correctly, we are all in the business of side effects and in fact our clients are not they think about them, the side effects, they think about them as the desired effect and what we've just done is we've built this beautiful, lovely functional environment that can't do anything right, which seems to be a bit of a problem, so what we need It's a bridge from our beautiful, lovely functional code to the real, messy world of side effects, we want our programs to be able to do things, so how do we do it right?

Here is the point where I have to take off my functional hat and put on my closing hat because all programming all functional programming languages ​​approach this problem differently but in general they are more or less the same but here are some of the closure solutions to make the bridge out of the messy world. A problem in the outside messy world is how to implement mutable. been inside my program, okay, think of the classic hit counter in a web application. Congratulations, you are the 57th visitor to this web application. If you think about the functional world that I just described, you can't do that, there is no mutable state, there is nothing. that can change so what we need is some way to represent the mutable state which closure does this through something called atoms and an atom is the closest thing the closure has to a variable it's a container for some mutable state that's what It's an atom well that sounds like a variable what's the difference the difference is that what's the way you update an atom because an atom is a bridge between the functional lovely that we all are that we have built in the messy outside world by the one that people pay us to mutate and affect and what's the way you update an atom: you throw a function at it, okay, so if that's a hit counter, you would throw a function at the atom that knows how to increment a number and what the atom does is throw a function at it. the atom takes that function it gets the current value of the atom sense that in the function it gets the result that comes out of the function then it evaluates the function and the value that comes out of the function becomes the new value of the atom, okay a bridge between the nice, clean, functional world on the one hand and the messy, state-filled world of real life on the other.

Now, to get a real sense of the power of this type of approach, let's think about what happens if it becomes necessary. I'm trying to update this atom in two different threads and that and the updates arrive at the same time. This is the classic, oh god, I don't want to miss type of update problem that anyone who has played with threads is familiar with. Well, what atoms do is you know that both functions are going to come in, they're both going to see the same value of atom 59 and you know this is where the problem lurks because we don't want to miss an update. they both calculate 60 as the atom's new value, but one of those functions will get there, go in a little faster and change the value to 60 and what will happen at that point is that the atom will notice it when the second function comes in and tries . to update the atom you will notice that the value changed from below and what does it do: just run the function again.

This is kind of collision detection and you know, re-executing, so it's similar to what a database does with transactions. Think, oh, is it okay to run that function a second time? What about the side effects? Guess what. No side effects allowed. The only side effect is updating the atom and that's what we're controlling, so atoms are a nice bridge between clean functions. world we are building and the messy outside world and are the things that the closure uses to maintain the state of the program. Well, there's another problem with state, which is how do I update the database, delete the file, write the file, access the web service, the kind of things I need. do something to the outside world and there are a lot of different solutions for this, including a lot of internal closures, but most of them depend on some kind of signal and placerequests of one type or another in the queue and then there is some nasty stateful side effect decoding connected to the queue that is taking things out of the queue and doing things with it, so you make a request, hey, update the base of data and somewhere on the other side of the queue there is some messy code that is withdrawing that request and doing some side effect and the reason you have the queue there is so you can sequence there is a clear sequence of which of these operations to that things that happen all at the same time close your agents, which is a form of this has the same kind of bridge to the functional world as atoms, in the sense that what it throws at the agent is not data, but you throw a function at it and the function runs in sequence and is what does the nasty stateful write. file delete file whatever, so here is our functional world, we have all the things that we extracted from our old programming styles, arrays and namespaces and things like that, we have these pure math style functions, we have data structures immutable and we have the bridge out of the nasty stateful world, okay and that's what I'm concerned with, that's what functional programming is functional programming in the no, you don't have to forget everything you know about programming, so, what is it like to program in a functional style and in particular what is the program and functional style like if you are new to it? yeah, no, there's no magic here, okay, I think it's a better way to write programs, but there's no magic, nothing, okay, you still get errors one by one like this.

It's a new slide. I put up the slide the day before yesterday because the day before yesterday. I guess I spent half a day looking for it and for some reason you still have that kind of thing, you can still have redundant code, we can be working on something together and you go in the hallway and you sit down and write some things and I sit and write some things and then, At the end of the day, we realize that we just solved the same functional programming problem and we're not going to help you with that, maybe it will help you talk about it and solve it faster, but that kind of stuff is still going to happen, still you can write bad code, right?

I have so many conversations, you know, you have that conversation, right, oh, you're following, you're, you're, you're in the system and you find something and you're. like it's as bad as I think it is and you go to your colleague and he says yeah yeah that's as bad as you think you still have the database is still down right in the database it always goes down a little bit of magic. What you do have is with threads, a bit of magic that functional programming gives you is with threads, functions take their input, operate on it and give you the correct output, it reduces the amount of state, but particularly overwhelmingly Immutable data structures mean that one thread can't change the data under another thread, one thread can get the wrong version of the array or the hash or whatever, but it can't, it can't change things under another thread and In particular, you can't understand the situation where one thread is in full update and the data structure is complete garbage and another thread looks at it, which can't happen with immutable data structures because either the thing is there or it's not there and the new version exists or not when the new one is released. version of your array or your hash or whatever exists, is at least consistent, so there is some magic in threading, it doesn't solve all your threading problems, think atoms, but it eliminates an entire class of them and, after all, isn't that what funk is about?

Our programming paradigms are supposed to work, but what is it like to program using effectively? These are rules, right? They are arbitrary rules that we say we are going to adopt in our programs because we believe that those rules will help us build better. programs well, initially it feels like programming using handcuffs, right, you know, if you've never programmed with the beautiful data structures, you spend your first week like, oh, I'll just change the third item to the sense that no, no I can, I need to. returns something and it really feels like you're weighed down by all these rules and it's hard to see why you have to program with these rules in your gut, but you do it for a while and after a while you realize that, oh, it's good.

The code is easier to understand. I can reason about the code because no. I spend a lot less time going through all the code to see what happens after a while. Those handcuffs feel like a bicycle. With arms like this, there are all kinds of rules for riding a bike, right, it's just that most of us can only ride a bike and on a fairly flat and even surface, but it reduces the friction between you and the place you want to go. , and that's really my feeling about functional. programming well and we have left it well, we are doing quite well, so does it work?

I think that is the last question that I want to try to answer and for that I would like to present to you pedestal pedestal is a library or, actually, a set. of libraries is produced by the company I work for for an ech and related pedestal and is open source and widely used in the closure world, so forget about the fact that it is produced by my company, that's not really important , it turns out that it is a production library that I am familiar with and the pedestal is that library in the closure world that, oh, I have a request that came.

I need the parts of the parameters that I need to route it to the right place. I need to authenticate it, it's provided by the closure or Sorry, the pedestal provides the pipes to do all that, it's that library, there's basically one or more in every programming environment, okay, but think about it, the pedestal is just a giant stack of production shutdown code written in a functional style, so let's look inside. pedestal what what's on the pedestal well, there's eighteen thousand seven hundred and six lines of code and pedestal as of last week. I have to tell you that closure is a pretty dense language, so eighteen almost nineteen thousand lines of code, that's a lot of closure. closer than in most apps, what if we look a little deeper?

What's in those approximately nineteen thousand lines of code, there are 28 protocols, a closure protocol is a set of method signatures or function signatures and is the way that interfaces are defined between different parts of the application or closure library It makes sense that a library defines a bunch of interfaces, so there are 28 protocols on the pedestal, there are eight of these bridges to the outside world, right agents and atoms and things like that, there are nine types of registers, a kind of enclosure record is like close when closure gets object-oriented programming, it's like here's the thing and it has the fields in these operations, only nine of them, there's a multiple method, a multiple method, it's a completely general form of polymorphism , okay, and then there are 944 functions, think about there are nine, all those little numbers, there are twenty-eight of these and eight of these and one of these and then there are 944 functions and if you don't remember anything else from this talk, remember this pie chart, this giant production functional programming stack is almost entirely functional and has a small portion of interfaces and then a trivial amount of everything else and if you want to know what functional programming is like, how do I get up every morning and I write programmer type applications, this is what you spend everything on. of your time or most of your time just writing functions if that sounds a little boring yes it is boring it was boring in that good way of I can do the same thing over and over again without having to negotiate with my language without having to negotiate with libraries I just write these simple, testable functions for the most part and then maybe some protocols, so there we have it, that's kind of a functional programmer's guide to functional programming.

Works? I think so. I hope you try it and find out. for you thank you for listening to you