Chapter 2: Functional thinking in action
This chapter introduction previews a broad tour of functional thinking through real-world examples, stratified design, and timelines.
After this chapter you will be able to
- Resource use and code categories. Distinguish actions from calculations in Toni’s kitchen by whether the code uses ingredients or other resources.
- Multi-robot distributed kitchen. Explain why Toni’s kitchen is a distributed system: multiple robots work together to cook the pizzas.
- Three categories of code. Explain that functional thinking distinguishes actions, calculations, and data, and that this distinction identifies which code needs more attention.
- Pizza shop actions. Explain why tasks such as rolling out dough, delivering pizza, and ordering ingredients are actions, and why Toni must be careful about when and how often they happen.
- Calculations as safe planning. Explain that calculations make decisions or plans without affecting the world when they run, so Toni can use them without worrying about changing her kitchen.
- Immutable business data. Explain what Toni represents as immutable data and why data is useful in her pizza business.
- Layers by change frequency. Describe how Toni’s software is arranged from least changeable to most changeable, and relate her examples to the tech stack, domain rules, and business rules.
- Stable foundations for change. Explain why building each layer on the layers beneath it can make software changes easier.
- Action timing in the kitchen. Explain that a timeline diagram shows how one robot’s pizza-making actions execute over time, and that their order matters because actions depend on when they run.
- Parallel robot timelines. Explain why Toni’s three-robot kitchen is a distributed system and what a timeline diagram helps her see. Describe how different orderings of the robots’ actions can produce bad pizzas.
- Uncoordinated timeline orderings. Explain why the robots cannot rely on their preparation timelines finishing in a particular order, and how this can cause the sauce robot to use an ingredient before it is ready.
- Uncoordinated timelines and actions. Explain why Toni must coordinate the kitchen’s timelines when moving from a sequential program to a distributed system.
- Unreliable action durations. Explain why Toni cannot use typical action durations or successful tests as a guarantee that the kitchen will work correctly.
- Coordinating parallel timelines. Explain that cutting a timeline lets multiple timelines work independently and then wait for each other to finish, so it does not matter which finishes first.
- Cut timelines and ordering. Explain how cutting the robots’ timelines separates parallel preparation from sequential assembly, making each piece easier to reason about while keeping actions in the right order.
- Stratified restaurant software design. Explain that Toni organized actions and calculations according to stratified design to reduce maintenance costs.
- Multiple robot timing problems. Describe the outcome Toni achieved when scaling her kitchen to multiple robots: she avoided timing bugs.
What it builds on
- The three categories of code in FP (chapter 1) · Introduces the categories of code in functional programming.
- Distinguishing actions, calculations, and data (chapter 1) · The earlier introduction to distinguishing actions, calculations, and data.
- Actions (chapter 1) · Introduces actions as a category of code.
Section by section
Introduction
This chapter introduction previews a broad tour of functional thinking through real-world examples, stratified design, and timelines.
2.1 Welcome to Toni’s Pizza
Introduces Toni’s robot-run pizza restaurant as the setting for a forthcoming tour of functional thinking in its systems.
2.2 Part 1: Distinguishing actions, calculations, and data
Toni distinguishes code that uses kitchen resources from code that does not.
- Resource use and code categories: Distinguish actions from calculations in Toni’s kitchen by whether the code uses ingredients or other resources.
Why it matters: This distinction gives Toni a way to classify kitchen code.
Key terms: actions, calculations, ingredients, resources
2.3 Part 2: Using first-class abstractions
The section identifies Toni’s multi-robot kitchen as a distributed system and briefly defines first-class functions before previewing how Toni will coordinate the robots.
- Multi-robot distributed kitchen: Explain why Toni’s kitchen is a distributed system: multiple robots work together to cook the pizzas.
Why it matters: This explains why coordinating the robots matters in Toni’s kitchen. - Functions as function arguments: State what the section means by first-class functions: functions that take other functions as arguments.
Why it matters: This gives you the meaning of the term used in the preview, without requiring the coordination technique yet.
Key terms: distributed system, robots, first-class functions, functions as arguments
2.4 Part 1: Distinguishing actions, calculations, and data
Toni’s growing pizza business illustrates why functional thinking begins by distinguishing actions, calculations, and data.
- Three categories of code: Explain that functional thinking distinguishes actions, calculations, and data, and that this distinction identifies which code needs more attention.
Why it matters: The distinction helps you recognize where to focus attention in your code.
Key terms: functional thinking, actions, calculations, data
2.5 1. Actions
Defines actions in Toni’s pizza shop by their dependence on when or how often they happen and by their use of resources.
- Pizza shop actions: Explain why tasks such as rolling out dough, delivering pizza, and ordering ingredients are actions, and why Toni must be careful about when and how often they happen.
Why it matters: This helps you recognize which parts of the pizza-making process require care about timing and repetition.
Key terms: actions, ingredients, resources
2.6 Calculations
This section presents calculations as decisions or planning that can run without affecting the world.
- Calculations as safe planning: Explain that calculations make decisions or plans without affecting the world when they run, so Toni can use them without worrying about changing her kitchen.
Why it matters: This distinction lets you recognize planning work that is safe to run without changing the kitchen.
Key terms: calculations, decisions, planning
2.7 3. Data
The section shows how Toni uses immutable data in her pizza business and why data is flexible.
- Immutable business data: Explain what Toni represents as immutable data and why data is useful in her pizza business.
Why it matters: Seeing orders, receipts, and recipes as data helps make the actions–calculations–data distinction concrete.
Key terms: immutable data, data
2.9 A first glimpse of stratified design
Introduces stratified design as layers of code arranged by how often they change, with more changeable code built on more stable code.
- Layers by change frequency: Describe how Toni’s software is arranged from least changeable to most changeable, and relate her examples to the tech stack, domain rules, and business rules.
Why it matters: This gives you a way to place code according to how likely it is to change. - Stable foundations for change: Explain why building each layer on the layers beneath it can make software changes easier.
Why it matters: The direction of dependencies helps keep routine business changes from disturbing code that many other parts rely on.
Key terms: stratified design, business rules, domain rules, tech stack, layers, stable foundation
2.11 As applied to a robotic kitchen
Toni’s one-robot kitchen introduces a timeline diagram for seeing when pizza-making actions execute and why their order matters.
- Action timing in the kitchen: Explain that a timeline diagram shows how one robot’s pizza-making actions execute over time, and that their order matters because actions depend on when they run.
Why it matters: Seeing actions over time makes it easier to notice why their order matters.
Key terms: timeline diagram, actions
2.12 Timelines visualize distributed systems
Toni’s three-robot kitchen introduces timeline diagrams as a way to visualize parallel work and the problems caused by uncertain action ordering.
- Parallel robot timelines: Explain why Toni’s three-robot kitchen is a distributed system and what a timeline diagram helps her see. Describe how different orderings of the robots’ actions can produce bad pizzas.
Why it matters: Timelines make it easier to spot ordering problems when several workers act in parallel.
Key terms: distributed system, actions, timeline diagram, parallel
2.13 Multiple timelines can execute in different orderings
The section shows that uncoordinated robot timelines can run in different orders, causing pizza assembly to begin before the ingredients are ready.
- Uncoordinated timeline orderings: Explain why the robots cannot rely on their preparation timelines finishing in a particular order, and how this can cause the sauce robot to use an ingredient before it is ready.
Why it matters: A plausible preparation order can still produce a bad pizza if a robot starts using an ingredient too soon.
Key terms: timeline diagram, coordination, uncoordinated timelines
2.15 Toni does a postmortem
Toni’s postmortem shows why uncoordinated timelines can produce unreliable results and how a timeline diagram can expose the risk.
- Uncoordinated timelines and actions: Explain why Toni must coordinate the kitchen’s timelines when moving from a sequential program to a distributed system.
Why it matters: Independent work does not automatically happen in the order the kitchen needs. - Unreliable action durations: Explain why Toni cannot use typical action durations or successful tests as a guarantee that the kitchen will work correctly.
Why it matters: A system must still work when tasks finish in an unexpected order. - Timeline diagrams as diagnostics: Describe how a timeline diagram could have helped Toni identify a problem before it occurred.
Why it matters: A diagram can make a possible timing failure visible before the kitchen encounters it.
Key terms: actions, timelines, coordinate, duration of actions, order, production, timeline diagram
2.16 Cutting the timeline: Making the robots wait for each other
Introduces cutting a timeline as a way to coordinate parallel work so completion order does not matter.
- Coordinating parallel timelines: Explain that cutting a timeline lets multiple timelines work independently and then wait for each other to finish, so it does not matter which finishes first.
Why it matters: It gives the robots a way to coordinate without requiring one to finish before the other.
Key terms: cutting the timeline, timelines, parallel
2.18 Retrospective on coordinating robots
The section reflects on how cutting timelines coordinated Toni’s robots and how timeline diagrams helped her reason about their behavior.
- Cut timelines and ordering: Explain how cutting the robots’ timelines separates parallel preparation from sequential assembly, making each piece easier to reason about while keeping actions in the right order.
Why it matters: The cut makes a parallel workflow easier to understand while preserving the order needed for assembly. - Timeline diagrams for coordination: Describe how Toni used timeline diagrams to visualize how the system runs through time and to model the coordination she wanted before working out how to code it.
Why it matters: A diagram gives Toni a way to check the intended coordination before translating it into code.
Key terms: cutting a timeline, preparation, assembly, timeline diagrams, parallel and distributed systems, coordination
2.19 Conclusion
The conclusion recaps how functional thinking helped Toni organize her restaurant software and coordinate multiple kitchen robots.
- Stratified restaurant software design: Explain that Toni organized actions and calculations according to stratified design to reduce maintenance costs.
Why it matters: This connects functional thinking to a practical software-maintenance benefit. - Multiple robot timing problems: Describe the outcome Toni achieved when scaling her kitchen to multiple robots: she avoided timing bugs.
Why it matters: The example shows why timing matters when several robots work in one kitchen.
Key terms: actions, calculations, stratified design, multiple robots, timing bugs
2.20 Summary
2.21 Up next…
The section transitions from a practical example of functional thinking to the upcoming examination of actions, calculations, and data.
Where this is used later
- First-class functions can replace any syntax (chapter 10) · The later discussion develops the use of first-class functions.
- Actions, calculations, and data (chapter 3) · Introduces actions as a category of code.
- Lessons from our shopping process (chapter 3) · Introduces data as one of the three categories.
- What is stratified design? (chapter 8) · Develops the initial definition of stratified design.
- Code at the top of the graph is easier to change (chapter 9) · Examines why code at the top of a stratified-design graph is easier to change.
- (chapter intro) (chapter 15) · Introduces timelines as a way to visualize distributed systems.
- Timeline diagrams side-by-side can reveal problems (chapter 15) · Timeline diagrams are used to reveal problems by placing timelines side by side.
- A concurrency primitive for cutting timelines (chapter 17) · Develops the concurrency primitive for cutting timelines.
Concepts explained in this chapter
- stratified designAn architectural pattern that organizes software into layers ordered from relatively stable foundations to more frequently changing elements.
- actionAn action is a computation whose observable result depends on when or how it is performed and may involve effects beyond producing a value.
- mathematical calculationA calculation is a category of code that deterministically computes a result from its inputs without directly interacting with the outside world.
- functional, stateless philosophyA programming paradigm that emphasizes composing computations as evaluations of functions while minimizing mutable state and side effects.
- dataAn inert representation of information that requires interpretation to acquire meaning and can be stored or transmitted.
- cutting timelineA coordination technique that draws a boundary across timelines so actions before it precede actions after it.
- distributed systemA software system whose components communicate over a network and may experience delayed, reordered, duplicated, or lost messages.
- immutable collectionData or state whose represented values cannot be modified after creation.
- validation ruleA rule that specifies behavior or constraints within the problem domain modeled by software.
These guides are generated from the text of Manning books by Manning's knowledge graph and link to the sections they draw on. The full books are available on liveBook and at manning.com.