Chapter 3: Distinguishing actions, calculations, and data
This chapter introduction previews applying the actions, calculations, and data categories to problems and code.
After this chapter you will be able to
- Three categories of code. Distinguish actions, calculations, and data using the section’s definitions and examples.
- Applying categories during development. Explain how the three categories guide thinking about a problem, coding a solution, and reading existing code.
- Hidden parts of shopping. Explain how familiar shopping steps contain more than actions: checking the fridge produces inventory data, and deciding what to buy can use a calculation based on desired and current inventory.
- Shopping process decomposition. Describe how to break a complex shopping action into smaller actions, calculations, and data, and how arrows in the resulting diagram show data moving into and out of actions and calculations.
- Composition of ACD categories. Distinguish what can be found inside actions, calculations, and data when breaking a process into smaller pieces.
- Data as interpreted records. Describe data as facts about events and explain how its structure and interpretation give it meaning.
- Data benefits and tradeoff. Explain what makes inert data useful compared with actions and calculations, and identify the cost of that inertness.
- Coupon email category distinctions. Distinguish actions, calculations, and data in the proposed email process: sending emails and reading databases are actions, deciding which email someone gets is a calculation, and records, counts, rankings, and email content are data.
- Email planning before sending. Explain how the process separates generating a list of emails from sending them, and why that separation helps testing.
- Smaller email planning calculations. Trace how the email-planning calculation can be broken into smaller calculations that produce one planned email per subscriber.
- Coupon planning calculations. Trace the calculations that decide a subscriber’s coupon rank, select coupons of a rank, plan one email, and plan emails for a list of subscribers.
- Calculation and action distinction. Distinguish the campaign’s calculations from its sending action, including why both may be implemented as JavaScript functions.
- Benefits and limits of calculations. Explain why the section prefers calculations where possible and identify the limitation it contrasts with data.
- Actionhood through calling functions. Trace why sendPayout() is an action and why figurePayout(), affiliatePayout(), and main() are actions too.
- Action propagation through function calls. Explain how calling an action makes the calling function an action, and how that classification can spread through further callers. Describe why functional programmers are careful about where they use actions.
- Recognizing actions across code forms. Explain how to recognize an action by asking whether its result depends on when or how many times it runs, regardless of whether it appears as a function call, method call, constructor, expression, or statement. Describe how actions can spread through code that uses them.
- Containing necessary actions. Justify why functional programmers cannot eliminate actions, and describe the approaches given here for making them easier to manage: use calculations when an action is unnecessary, keep necessary actions small, and restrict them to interactions with the outside world.
- Planning and execution categories. Explain how a calculation can make a plan or decision, data can represent that plan or decision, and an action can execute it.
What it builds on
- 1. Actions (chapter 2) · Introduces actions as a category of code.
- Calculations (chapter 2) · Introduces calculations as a category of code.
- 3. Data (chapter 2) · Introduces data as a category of code.
Section by section
Introduction
This chapter introduction previews applying the actions, calculations, and data categories to problems and code.
3.1 Actions, calculations, and data
This section defines actions, calculations, and data, then shows how the distinction guides problem solving, coding, and code review.
- Three categories of code: Distinguish actions, calculations, and data using the section’s definitions and examples.
Why it matters: These categories help you notice which parts of a program need different treatment. - Applying categories during development: Explain how the three categories guide thinking about a problem, coding a solution, and reading existing code.
Why it matters: The distinction is useful before code exists as well as when writing or improving it. - Referential transparency of calculations: Explain referential transparency using the section’s `2 + 3` example.
Why it matters: This gives a concrete way to understand how calculations differ from time-dependent actions.
Key terms: actions, calculations, data, side-effects, pure functions, hidden actions, refactor, referentially transparent
3.2 Actions, calculations, and data apply to any situation
Uses grocery shopping to show how an apparently action-only process contains actions, calculations, and data that can be separated into a clearer model.
- Hidden parts of shopping: Explain how familiar shopping steps contain more than actions: checking the fridge produces inventory data, and deciding what to buy can use a calculation based on desired and current inventory.
Why it matters: Spotting the data and calculations inside an everyday process makes it easier to distinguish the three categories in code. - Shopping process decomposition: Describe how to break a complex shopping action into smaller actions, calculations, and data, and how arrows in the resulting diagram show data moving into and out of actions and calculations.
Why it matters: Breaking apart a broad action reveals useful distinctions that a simple sequence of steps hides.
Key terms: actions, calculations, data, current inventory, desired inventory, shopping list, inputted, outputted
3.3 Lessons from our shopping process
The section draws lessons from a shopping example about finding actions, calculations, and data, then explains how data gets its meaning and why it is useful.
- Composition of ACD categories: Distinguish what can be found inside actions, calculations, and data when breaking a process into smaller pieces.
Why it matters: These distinctions help you look inside a seemingly simple step without treating every part of it as the same kind of thing. - Calculations in everyday decisions: Explain how calculations can be present in a process even when no explicit calculation or written list is visible.
Why it matters: It helps you notice reasoning that a description of the visible actions leaves out. - Data as interpreted records: Describe data as facts about events and explain how its structure and interpretation give it meaning.
Why it matters: Choosing a useful representation requires thinking about both where information came from and how it will be interpreted. - Data benefits and tradeoff: Explain what makes inert data useful compared with actions and calculations, and identify the cost of that inertness.
Why it matters: It explains why functional programmers seek out data while still caring how it will be read.
Key terms: actions, calculations, data, ACD perspective, decisions, planning, facts about events, structure, interpretation, inert
3.4 Applying functional thinking to new code
The section uses CouponDog’s referral-email plan to practice identifying actions, calculations, and data in new code.
- Coupon email category distinctions: Distinguish actions, calculations, and data in the proposed email process: sending emails and reading databases are actions, deciding which email someone gets is a calculation, and records, counts, rankings, and email content are data.
Why it matters: Classifying each part of a new feature helps you see which work is time-dependent and which is computation or data. - Referral coupon eligibility rule: Describe the marketing rule the email process must serve: people who recommend CouponDog to 10 friends get better coupons, with “best” coupons reserved for frequent referrers, “good” coupons for everyone else, and no “bad” coupons sent.
Why it matters: The referral rule gives the email decision a concrete purpose.
Key terms: actions, calculations, data, recommendation count, best, good, bad
3.5 Drawing the coupon email process
The section diagrams a coupon-email process by separating database reads and email sending from the calculations that plan which emails to send.
- Database reads and records: Distinguish fetching subscribers and coupons from the records those queries return, and explain why each belongs to its ACD category.
Why it matters: This distinction identifies the changing inputs to the email plan without treating the records themselves as actions. - Email planning before sending: Explain how the process separates generating a list of emails from sending them, and why that separation helps testing.
Why it matters: Separating decisions from delivery makes the decisions easier to test. - Smaller email planning calculations: Trace how the email-planning calculation can be broken into smaller calculations that produce one planned email per subscriber.
Why it matters: Breaking the plan into smaller calculations makes each decision easier to implement.
Key terms: action, data, subscribers, coupons, calculation, list of emails, plan, good coupons, best coupons, subscriber
3.6 Implementing the coupon email process
The section implements a coupon email campaign by representing subscribers, coupons, and unsent emails as data, planning emails with calculations, and sending them with an action.
- Coupon campaign data: Describe how the section represents subscribers, coupons, coupon ranks, and unsent emails as data.
Why it matters: These representations let the campaign make decisions about emails without sending them yet. - Coupon planning calculations: Trace the calculations that decide a subscriber’s coupon rank, select coupons of a rank, plan one email, and plan emails for a list of subscribers.
Why it matters: Separating the planning steps makes it possible to produce the campaign’s emails without performing the sending action. - Calculation and action distinction: Distinguish the campaign’s calculations from its sending action, including why both may be implemented as JavaScript functions.
Why it matters: A function’s syntax alone cannot tell you whether running it merely computes a value or performs an action. - Batching within the action: Explain how the campaign could handle subscribers in smaller groups without changing its planning calculations.
Why it matters: The same email-planning logic can serve a memory-conscious implementation without being rewritten. - Benefits and limits of calculations: Explain why the section prefers calculations where possible and identify the limitation it contrasts with data.
Why it matters: This explains both the value of moving work into calculations and why representing something as data can still be useful.
Key terms: data, coupon rank, JavaScript object, JavaScript array, calculation, selectCouponsByRank(), emailsForSubscribers(), action, function, inputs
3.7 Applying functional thinking to existing code
This section shows how to identify an action in existing code and trace its dependence on time through the functions that call it.
- Actionhood through calling functions: Trace why sendPayout() is an action and why figurePayout(), affiliatePayout(), and main() are actions too.
Why it matters: A single action can make much more of an existing program time-dependent than it first appears.
Key terms: action, depends on when it is run, figurePayout(), sendPayout()
3.8 Actions spread through code
This section explains why an action in one function can make its callers actions too, and why functional programmers use actions carefully.
- Action propagation through function calls: Explain how calling an action makes the calling function an action, and how that classification can spread through further callers. Describe why functional programmers are careful about where they use actions.
Why it matters: It explains why the placement of even one action matters beyond the function that contains it.
Key terms: actions, functional thinking
3.9 Actions can take many forms
This section shows how to recognize actions in many forms of JavaScript code and why functional programmers try to contain them without eliminating them.
- Recognizing actions across code forms: Explain how to recognize an action by asking whether its result depends on when or how many times it runs, regardless of whether it appears as a function call, method call, constructor, expression, or statement. Describe how actions can spread through code that uses them.
Why it matters: The timing-and-repetition test helps you spot actions even when the language does not distinguish them from calculations. - Containing necessary actions: Justify why functional programmers cannot eliminate actions, and describe the approaches given here for making them easier to manage: use calculations when an action is unnecessary, keep necessary actions small, and restrict them to interactions with the outside world.
Why it matters: Keeping unavoidable effects at the edges leaves more of a program as calculations and data.
Key terms: actions, calculations, ordering, repetition, data, planning stage, execution stage
3.10 Conclusion
The conclusion connects calculations, data, and actions through planning and execution.
- Planning and execution categories: Explain how a calculation can make a plan or decision, data can represent that plan or decision, and an action can execute it.
Why it matters: This distinction helps separate deciding what to do from doing it.
Key terms: actions, calculations, data, plan, decision
3.11 Summary
3.12 Up next…
The section previews the next chapter’s move from identifying actions and calculations to transforming actions into calculations.
Where this is used later
- Extracting a calculation from an action (chapter 4) · Supports recognizing the benefit of extracting a calculation from an action.
- We need to make it more testable (chapter 4) · The testability discussion develops the benefit of calculations as outputs.
- MegaMart is creating a communications team (chapter 12) · Introduced the coupon email process revisited here.
- We need to make it more reusable (chapter 4) · the motivation for making code more reusable
- Distinguishing actions, calculations, and data (chapter 4) · Actions can spread through code.
- Smaller functions and more calculations (chapter 5) · Actions can spread through code.
- A functional architecture (chapter 18) · The functional architecture develops the distinction between outside interactions and an interior of calculations and data.
Concepts explained in this chapter
- actionAn action is a computation whose observable result depends on when or how it is performed and may involve effects beyond producing a value.
- dataAn inert representation of information that requires interpretation to acquire meaning and can be stored or transmitted.
- mathematical calculationA calculation is a category of code that deterministically computes a result from its inputs without directly interacting with the outside world.
- ACD perspectiveA functional-programming perspective that classifies computations as actions, calculations, or data.
- arrayAn indexed JavaScript collection that stores an ordered sequence of values and can change size.
- copy-on-writeA data-management technique that creates a copy before modifying data so the original remains unchanged.
- defensive copyA technique that copies data intended to be retained so subsequent modifications cannot alter the retained version.
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.