# Welcome to Grokking Simplicity

This is decidedly about the industrial uses of functional programming.

### definition paraphrased from Wikipedia
- 1. a programming paradigm characterized by the use of
mathematical functions and the avoidance of [[side effects]]
- 2. a programming style that uses only [[pure functions]]
without [[side effects]]

### side effect
Side effects are anything **a function does other than returning a value**

- sending email
- modifying global state
- Blinking a light
- making a web request
- Applying the brakes in a car

### pure functions
Pure functions are functions that depend only on their arguments and don’t have any side effects.
- **Given the same arguments, they will always produce the same return value**.
- Functional programmers emphasize the use of pure functions because **they are easier to understand and control. **

The definition implies that functional programmers completely **avoid side effects** and only use pure functions. But this is **not true**.

The problems with the definition for practical use
- Problem 1: FP needs side effects
- side effects are the very reason we run our software. What good is email software that doesn’t send emails?
- Problem 2: FP is good at side effects
- 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 is especially confusing to people who are introduced to FP through the definition.


## Distinguishing actions, calculations, and data
- Actions
- Actions (everything above the line) depend on when they are called or how many times they are called.
- Calculations
- it doesn't depend on when or how many times they are used.
- can be executed
- Calculations are opaque, meaning that you don’t really know what a calculation will do until you run it.
- Data
- it doesn't depend on when or how many times they are used.
- can not be executed
- Data is inert and transparent.

Functional programmers prefer data to calculations and prefer calculations to actions.

### a simple scenario that illustrates the three categories


## How does distinguishing actions, calculations, and data help us?
- Data and calculations do not depend on how many times they are run or accessed
- By moving more of our code into data and calculations, we sweep that code clean of the problems inherent in distributed systems.
- The problems still remain in actions, but we’ve identified and isolated them. Further, FP has a set of tools for working with actions to make them safer

## What is functional thinking?
Part 1: Distinguishing actions, calculations, and data
Part 2: Using first-class abstractions