# Functional thinking in action Chapter 2


## Welcome to Toni's pizza

- Welcome to Toni’s Pizza. The year is 2118. It turns out people still like pizza in the future. But all of the pizza is made by robots.
- Robots are programmed in JavaScript.
- Toni has applied a lot of functional thinking to the code that runs her restaurants.
- Two levels:
- Principles of stratified design
- First-class abstractions functions

## Principles of stratified design

- Distinguishing actions, calculations, and data
- Which parts of our code are easy (calculations and data) and which need more attention.

### Example actions
- Roll out dough
- Deliver pizza
- Order ingredients

### Example calculations
- Double a recipe
- Determine a shopping list

### Example data
- Customer orders
- Receipts
- Recipes

We’ll learn how these three categories interact when they call each other in chapter 3.

### Organizing code by “rate of change”
- Toni’s software has had to change and grow with her business. Using functional think- ing, she has learned to organize her code to minimize the cost of making changes minimize the cost of making changes.


### Three main layers
- business rules, domain rules, and tech stack.
- Will go deeper into stratified design in chapters 8 and 9.

### Draw a spectrum
- On the bottom, we put the stuff that changes the least frequently.
- On the top, we put the stuff that changes the most frequently.

## First-class abstractions functions

- Functions that take functions as arguments
- use the timeline diagram to understand how actions will execute over time


### Timelines visualize distributed systems

- Toni’s one robot makes good pizza, but it’s not fast enough.
- She is sure that there is a way to get three robots working together on one pizza. She can divide the work into three parts that can happen in parallel: making the dough, making the sauce, and grating the cheese.


### Multiple timelines can execute in different orderings


### Hard-won lessons about distributed systems

1. Timelines are uncoordinated by default.
2. You cannot rely on the duration of actions.
3. Bad timing, however rare, can happen in production.
4. The timeline diagram reveals problems in the system.

### Positive lessons learned about timelines
1. Cutting a timeline makes it easy to reason about the pieces in isolation
2. Working with timeline diagrams helps you understand how th esystem works through time
3. Timeline diagrams are flexible

### Cutting the timeline:
- Making the robots wait for each other ch17

## Conclusion
- Got a high-level view of some of the functional ideas.
- We watched as Toni got a lot of mileage from applying functional thinking to her pizza restaurant software. She organized her actions and calculations according to stratified design to minimize the cost of maintenance. We will learn to do this in chapters 3 through 9. Toni was also able to scale the kitchen to multiple robots and avoid some nasty timing bugs. We will learn to draw and manipulate timeline diagrams in chapters 15 through 17.

## Summary
- **Actions, calculations, and data** are the first and most important distinction functional programmers make. We need to learn to see them in all code we read. We’ll start to apply this distinction in chapter 3.
- Functional programmers apply stratified design to make their code easier to maintain. The layers help organize code by ***rate of change***. We see the exact process of stratified design in chapters 8 and 9.
- **Timeline diagrams** can help you visualize how actions will run over time. They can help you see where actions will interfere with each other. We’ll learn the process of drawing timeline diagrams in chapter 15.
- We learned to cut timelines to coordinate their actions. Coordinating them helps us guarantee that they perform their actions in the proper order. We’ll see exactly how to cut timelines in chapter 17 in a very similar scenario to the pizza kitchen.