This is the final section of my book A Functional Programming Kickstart. There is a discount intended for those who need it.

Kim, my wife, and I used to travel a lot. Sometimes you'll be far from home having a great time and you'll look to buy a shirt or something that you think fits in wherever you are.

Kim would ask if it is something we'd ever wear once we get home. She used to refer to it as the "puka shell necklace".

We bought items that we did use at home. One of my favorites is this tiny Ibrik we got while chaperoning a trip to Turkey. We don't use it every day, but every once in a while we feel like Turkish coffee and this is the perfect way to make it.

This small item cost us just a few dollars but is easy to pull out and use when we want it.

That's pretty much what I want to leave you with here.

This book has been your vacation to a land where pure functions are just a way of life.

I'm not asking you to return to your home world of programming with a huge proprietary framework or unwieldy design pattern that requires you to change all of your code.

I'm asking that you look at these small, safe, isolated tools and techniques and consider when it would be appropriate to use them in your code.

Add them a little at a time.

Oh look - this is just map() let's use that here.

Pace yourself.

If you are an iOS or macOS developer, you will probably need to adopt many of these techniques at some point as you incorporate SwiftUI and Combine.

The other thing I want to say is that these ideas are both very old and very new.

I mentioned earlier that the ideas of functional programming are rooted in mathematics that is a century old and have been applied to computer science for sixty years.

John Backus addressed this in his 1977 Turing Award lecture, "Can Programming be Liberated from the von Neumann Style? A Functional Style and Its Algebra of Programs".

John Hughes also takes this head on in his famous 1990 paper, "Why Functional Programming Matters".

Functional programming, as they both show, is built on a solid foundation and the reasons for embracing its style still exist.

What about this new-fangled category theory stuff?

The ideas of functors goes back nearly eighty years to the work of Eilenberg and MacLane. The application of functors to computer science dates back to the last century.

Monads are also quite an old idea in mathematics, they were introduced to solve the problem of "how do we have a program that does anything interesting if nothing is able to change".

Some people take the approach that we took in our GUI apps. We had a non-mutating view and model with a middle layer built from reference types.

In languages like Haskell there are no reference types and they needed a way to work with I/O and other effects. In 1995, Wadler formalized the idea in a paper titled "Monads for Functional Programming".

Applicative Functors were introduced by McBride and Paterson in 2008 in "Applicative Programming with Effects". Tons of other functors are discussed in the literature and other mechanisms such as free monads, monad transformers, and effect systems. In 2019 Mokhov, Lukyanov, Marlow, and Dimino introduced a functor that sits between applicative functors and monads in their paper "Selective Applicative Functors". This functor allows effects that are declared statically like applicative functors and functors but that can be executed dynamically like monads.

We've seen a lot in this book.

Take small steps.

Pace yourself.

Don't let the bullies get you down - there are plenty of this-is-so-obvious-why-don't-you-get-it people out there. But there are also so many really nice people and they are willing to help you.

They've helped me a ton.

And by the way, we've quietly achieved a very important magic trick. We've turned you into a functional programmer.

Taaa - daaaaa.