Bonus: The Mindset of a Functional Programmer

I started this book by saying that it has an audacious goal: to demonstrate to OOP developers the benefits of:

1. Immutable variables (algebraic variables)
2. Immutable data structures
3. Pure functions
4. Expression-oriented programming
5. Functional error handling

As I went along in creating the examples, you also saw the additional benefits of declaring data types: that they make the signatures of pure functions incredibly meaningful.

After we finished the To-Do List example and switched some of that code from using Try to using Either, I then showed how this gets you ready to use the “IO” types in the ZIO and Cats Effect libraries.

The mindset of an FPer

As you dig into ZIO and Cats Effect, remember a few things:

• The biggest thing is that FPers think of ourselves as mathematicians or architects, writing algebraic code or creating blueprints.
• Terms like equations and blueprints imply that the description of our code is separate from the execution of the code. (As I mentioned, FPers don’t like Future because it begins running immediately.)
• Writing FP code is all about immutable variables, immutable data structures, pure functions, with data types and functional error handling that tells readers exactly what’s going on — all of which you’ve seen in this book.
• Side effects mess up our equations and blueprints, so we don’t allow them. Instead we handle them with types like Option, Try, and Either — and when we really get into FP we use the more industrial-strength IO and ZIO types.
• I mentioned that you can’t mix types like Option, Try, and Either inside for expressions, so that’s one reason a type like ZIO has so many capabilities: whatever your ZIOs do individually, you can combine them all together, as desired.

These are the ways that FPers think about their code. If you understand the reasoning and desires behind this mindset, you can understand FP.