Chapter 1 from Grokking Simplicity by Eric Normand
In this chapter
- Learn the definition of functional thinking.
- Understand how this book is different from other books on functional programming.
- Discover the primary distinction that functional programmers make when they look at code.
- Decide whether this book is for you.
In this chapter, we will define functional thinking and how its major distinction helps working programmers build better software. We will also get an overview of the journey ahead through two major insights that functional programmers experience.
Problem 1: FP needs side effects
The definition says FP avoids side effects, but side effects are the very reason we run our software. What good is email software that doesn’t send emails? The definition implies that we completely avoid them, when in reality, we use side effects when we have to.
Problem 2: FP is good at side effects
Functional programmers know side effects are necessary yet problematic, so we have a lot of tools for working with them. The definition implies that we only use pure functions. On the contrary, we use impure functions a lot. We have a ton of functional techniques that make them easier to use.
Problem 3: FP is practical
The definition makes FP seem like it’s mostly mathematical and impractical for real-world software. There are many important software systems written using functional programming.
The definition is especially confusing to people who are introduced to FP through the definition. Let’s see an example of a well-intentioned manager who reads the definition on Wikipedia.
Functional programmers distinguish code that matters when you call it
Functional programmers distinguish inert data from code that does work
Functional programmers see actions, calculations, and data
Step 1: The user marks a task as completed.
This triggers a UI event, which is an action, since it depends on how many times it happens.
Step 2: The client sends a message to the server.
Sending the message is an action, but the message itself is data (inert bytes that must be interpreted).
Step 3: The server receives the message.
Receiving a message is an action, since it depends on how many times it happens.
Step 4: The server makes a change to its database.
Changing the internal state is an action.
Step 5: The server makes a decision of who to notify.**
Making a decision is a calculation. Given the same inputs, your server would make the same decision.
Step 6: The server sends an email notification. **
Sending an email is an action, since sending the same email twice is different from sending it once.
If this doesn’t make sense to you now, don’t worry, because we’re going to spend the whole first part of this book understanding how to make this distinction, why we make it, and how to improve our code because of it. As we’ve talked about before, the distinction between actions, calculations, and data is the first big idea in this book.
The three categories of code in FP
1. Actions
Anything that depends on when it is run, or how many times it is run, or both, is an action. If I send an urgent email today, it’s much different from sending it next week. And of course, sending the same email 10 times is different from sending it 0 times or 1 time.