if only composing functions was this easy I have tried to grok functional programming a bunch of times now. I would be lying if I said that I understand it fully, but at the very least I think I now understand enough to think about it in a meaningful way. The trouble with trying to “get” FP is that there isn’t actually one idea; there are actually two big ideas that you need to get your head around, preferably without mixing them unnecessarily. The first is about functions and the second is about types. In this article I want to show you both of these ideas, and hopefully illustrate why they are important in isolation, and then how to bring them together. I’m going to use javascript to illustrate the examples because it happens to lend itself well to using functions in the way we need to. Don’t be put off however, they are , not tied to a single language. If you hate javascript then let me assure you I won’t be using any of it’s insane parts, and you can just as well apply these concepts to other places. concepts Functions: The universal building block There are a few ways in which the idea of a function is a bit different in FP, but those differences have some really big implications, as we will see. Take a function like which gives us the nth item in an array: teensy nth, You’ve got two arguments, and , which when called will return the element at the specified index, but in functional programming, we need to change this a little bit to get the first big insight: a function should only ever takes . It’s a kind of one input, one output type of deal. n arr one argument Wait though, how can that even work? Add needs two numbers minimum after all. The answer is that if you need more than one argument, you simply return that waits for the next argument. When you’ve got everything you need, you return the result. another function It’s almost the same, but we’re doing a kind of piece by piece supplying of arguments. is now itself a function, waiting for the array part to be specified. This concept has the completely non-semantic name of “currying”. nth(3) For most people, myself included, the way you have to use the new function feels weird, because you have to have a series of bracketed expressions that look a little bit disconnected from the actual function call. That’s why most functional libraries like or provide a function called that converts normal functions into the best of both worlds, where you can call it normally or piece by piece. For example: nth ramda lodash curry Now we can call and and the effect is the same. The little function I added should give you a nice idea of why this concept actually makes sense: The fact that is curried means that we can build a more specific version out of it, simply by letting us space the arguments out over time. This idea of building up the arguments is called and a function made this way is said to be . So whichever array we give to , we’re always going to get element 3. nth(3)(powers) nth(3, powers) third nth partial application, partially applied third That little nugget alone can be used in your everyday programming to improve code reuse. Often you just need to think about the best way to arrange the arguments so it becomes as general as possible. The rule is typically . So that’s the array you’re working with, the string you want to manipulate, the object, number, array, whatever. put the data as the last argument With one more little tool, we can really turn the humble function into the universal building block of programming. That tool is called . compose This might start to seem complicated, but stay with me and we will break it down. takes 2 functions and and a variable It then runs and the result is consumed directly by To get concrete with , goes into , which produces , and that’s consumed by producing . compose f g, x. g(x), f(). thirdPlus1 x nth(2) 4 add(1), 5 is like an assembly line. You put something in, it’s picked up by one of our functions, transformed, and then passed on to the next to be transformed again. Something I tripped up on when I was first wrapping my head around this is it’s nature; so the first argument in is actually the last operation that gets run. If you look at the implementation it makes sense, but it’s a tricky one for sure. compose right-to-left compose Of course that’s fairly arbitrary, and you could just as well flip it all around. In functional programming that function is called , and it’s really as simple as specifying the transformations left-to-right. In fact a few languages actually have a first class operator for this kind of thing ( , , , , , ). pipe unix R Swift F# overload for C++ proposal for javascript Either way, like curry, many implement and , usually in a way that lets you specify any number of functions, so we’ll just use those from now on. Let’s just look at one more example that’s a little closer to real life. functional libraries compose pipe We’ve defined a couple more helpful generalised functions that play well with Most are actually just turning methods into normal functions ( ), or taking something syntaxy like reading an object property and turning that into a function ( ). compose. map, join property So our newly composed function is implicitly receiving an “x” value, which is the name of our colour. That is fed into giving us the “Blue Lagoon” array. That array is given to , a function that takes a transform function and an array and applies the transform to every element in the array. here is partially applied with the function, so what comes out is an array of hexadecimal representations of each number. turns our new array into a string, and finally pops a “#” on the front to turn it into a proper hex colour. namedColorToHex property map map toHex join prefix Like the greats Bach and Motzart, who weaved masterful compositions from the same 88 piano keys, we’ve used and a bunch of to write a program that’s nothing more than sticking different lego blocks together. No loops, no special syntax, no intermediate variables. Just descriptions of how to transform data. If you’ve kept up with everything so far, congratulations! You now understand the first of the two big ideas in functional programming. compose general functions Well, almost. I mentioned earlier that there are a couple of ways functions in FP are different. The other major way is that your functions should be “pure”. That means: You don’t use anything you weren’t given as arguments to compute (no global state) You don’t modify anything you’re given, you always just give back a new copy (no mutation) A good way to think about this is: If the answer is no, then its probably not a pure function. If I give this input to a function, will I always get the same output no matter what? Of course, what does that mean for errors? API calls? Random number generation? Well that’s the next big idea. (Algebraic) Types If you’re coming from OOP then you probably know what an interface is; Basically a sort of blueprint of what should be implemented on an object. This concept is also important in functional programming, but of course in a slightly different way. There is a function on the Array object called , which as described above, runs a function on every element and returns a new array. The array is a kind of for values, and the function lets us get at those values without pulling them out of the array. But what if you could on other types, like object? What would that even mean? map container map map Well you could run a function on every keyed element in the object, changing the values but preserving the structure. That’s pretty reasonable; Now we can map an object. Now, it’s completely against the rules but if you just go ahead and add to the Object prototype, then we have a common interface between Arrays and Objects! map Now we have a new, more general concept of a — something which has a reasonable definition for . Functional programming ( ) calls this idea of a mappable a Functors are just containers of values, where you work on the container instead of the value directly. mappable map and math Functor. I hope your mind is running wild at what else could be a Functor. The answer is a number of things — given the right treatment, and every functor can have it’s own interesting little domain. Let’s take a moment here and imagine a Container where the stuff that goes inside be a normal value, but it also might be null/undefined/junk. What we might want from this special container is that the value if it’s there, but not cause errors if it’s not. Of course we should be able to crack open the container and get at the meaningful stuff —the normal value, or the “nothing” — and respond accordingly. might map We’re going to build this Functor — often called a — but to avoid exposing some gritty javascript details I’m going to use a library called . From the github page: Maybe daggy Library for creating tagged constructors a.k.a. “union types” or “sum types” Don’t worry about exactly what that means, let’s learn by doing. We’re going to break this bad boy down. First of all we use daggy to make a “sum” constructor for a — this is the thing which will encapsulate possible nothingness. We name it Maybe, and that it can be either a “ ” which has an “x” value, or it can be a “ ” with no value. Maybe Just Nothing Next we implement a function for our , in which we use a daggy function called (as in ) to do a sort of switch/case on the type. If it’s a type, we run the function we supplied to on the “x” value and pop it back inside a new . If it’s a then we just give back another . map Maybe cata catamorphism Just map Maybe.Just Nothing Maybe.Nothing Finally we make a and an and run the same on both of them. We see that runs without error on both, and as expected we see a transformed value on the and on the invalid one. validThing invalidThing map map validThing Maybe.Nothing So there’s two problems with what we have now. The first is that it’s not really a realistic example — who is actually just creating nothing values? And the second: even if it were realistic, our value is still trapped inside the ! We need a way to bring it out, so let’s revisit the compositional-colour example from earlier, and see if we can’t make it a bit more error proof. Maybe Breaking it down, the first change is that we’ve got ourselves an function. It takes a function for the case, a function for the case, and the object. So when this is run, it’s going to see if the is a , and if so it will return the extracted the value with the run over it. If it’s not, then it will return the result of the . extractMaybe Nothing Just Maybe M Just successFn nothingFn Then we’ve got another new function called . This checks if the object actually has the property we’re trying to get at, and returns a of the value if it’s there, and a if it’s not. safeProperty Just Nothing We define a function that always returns it’s argument (we’ll get to why shortly), and a new variable called . defaultColor Finally we changed the function to use instead of (remember compose goes , or in this case, ) which means we’re getting a out the other end. Because of that, we need to use the function defined on in order to change the value, and remember, nothing happens if the value is ! So we wrap all the other transformations in a map, and at the end we can call to pull out the value. The Nothing case returns a function that gives us the , and the case gives us the value run through the function, which is… well just the value! namedColorToHex safeProperty property right-to-left down-to-up , Maybe map Maybe Nothing extractMaybe defaultColor Just identity My reaction when I first came across this kind of code was a kind of amazement; I was so used to handling errors with these try/catch blocks, null checks, and non linear code that would separate everything into if/else blocks. Now there’s a function which wraps up error handling, and even better in a way that still let’s us reason about code in a linear way. The handling of a conditional is just one more step in the chain of transformations! Containers in containers Imagine if you had to go a bit deeper into an object. If you use safeProperty every time, you’re going to end up with inside . Example: Maybes Maybes This could get out of hand; before you know it, you’re running which is not sustainable. We need a way to flatten those into a single Luckily, FP is way ahead of us. map(map(map(xyz))), Maybes Maybe. Sidenote: The idea of flipping the arguments of a function is quite common. If you’re playing along at home, why not try to write a function called that takes a function that takes two arguments, and returns a flipped version of the function. flip In functional programming, this idea is called a few names, sometimes flatMap, sometimes chain, but the one I think is clearest is . Basically that says run a function inside the container that returns another container, and then flatten those two containers into one. That kind of two ideas right — first , and then . In the case of an array for example, would just say if I have an Array of Arrays of Numbers, then turn that into an Array of Numbers. Let’s implement for Maybe. flatMap map flatten flatten flatMap Quite simple, though I should say this is not what you might call a rock solid implementation! So now if we know we’re running a function that returns a , then we just instead of , and voila! No more containers in containers. Maybe flatMap map So in a way we’ve made the type a more powerful tool by equipping it with some interfaces like and . This kind of type we call an . And this kind of type has some really interesting properties when you follow certain laws. Maybe map flatMap Algebraic Data Type And it’s not called algebraic without reason — you can write equations about how these different interfaces can be written in terms of each other. For instance, we wrote as , and then (also sometimes called ). But you can actually write the flatten function first, and construct from and . If you write (less than or equal to), you can derive every other comparison function automatically. There are many interfaces you can equip a type with. flatMap map flatten join flatMap flatten map lte Conclusion So we’ve seen what I consider to be the two big ideas of functional programming — function composition, and types. On top of that we’ve seen how to bring them together. If you’ve followed up until now, you have enough understanding to go out and learn all these arcane terms, get deeper in the laws and relations of algebraic data types, and how to write a whole program in terms of function composition. If you’re interested to learn more, I think is an book. It goes over everything from this article in a much deeper but still accessible level. He also has a bunch of great talks online that can help you get to grips with some more specific aspects of FP. Brian Lonsdorf’s “Professor Frisby’s mostly adequate guide to functional programming” amazing To make full javascript applications using this methodology, my colleague at has written a phenomenal library called which let’s you handle async in the functional style, and provides an alternative to promises and observables that feels great to program with. wearereasonablepeople Aldwin Vlasblom Fluture
