Chapter 1: Welcome to Grokking Simplicity

Introduction

This chapter introduction previews the topics and perspective the chapter will cover.

1.1 What is functional programming?

This section defines side effects and pure functions, then explains why a common definition of functional programming does not fully describe its practical use.

• Side Effects and Their Consequences: Explain what counts as a side effect and why an unnecessary side effect can be a problem when calling a function.
  Why it matters: This distinction helps you notice when calling a function may do more than produce a result.
• Pure Function Properties: Describe what makes a function pure and why functional programmers emphasize pure functions.
  Why it matters: These properties explain the appeal of pure functions without implying that every function must be pure.
• Definition Versus Practical FP: Distinguish the common definition of functional programming from what working functional programmers actually do.
  Why it matters: It keeps a useful emphasis on purity from becoming an unrealistic rule against practical software behavior.

Key terms: side effects, return value, global state, pure functions, arguments, mathematical functions, functional programming, impure functions

1.2 The problems with the definition for practical use

The section restates an academic definition of functional programming and introduces, without explaining, its practical shortcomings for working software engineers.

1.3 Problem 1: FP needs side effects

The section explains why functional programming cannot avoid all side effects and defines side effects and pure functions.

• Side effects in practical software: Explain why software sometimes needs side effects even though the definition of functional programming says to avoid them.
  Why it matters: This distinction keeps the definition of functional programming from sounding incompatible with useful software.
• Side effects and pure functions: Describe what counts as a side effect and how the section defines a pure function.
  Why it matters: These definitions make the section’s claim about necessary side effects precise.

Key terms: FP, side effects, pure functions, return value, arguments

1.4 Problem 2: FP is good at side effects

The section corrects the idea that functional programming uses only pure functions by explaining its practical approach to side effects.

• Functional programming and side effects: Explain why functional programmers use impure functions despite the definition’s emphasis on pure functions.
  Why it matters: It keeps the definition of functional programming from giving a misleading picture of how it is practiced.

Key terms: side effects, pure functions, impure functions, functional techniques

1.5 Problem 3: FP is practical

The section challenges the impression that functional programming is too mathematical to be useful in real-world software.

• Functional Programming in Practice: Explain why the definition of functional programming can give a misleading impression of its practical use.
  Why it matters: The definition alone can obscure FP’s use in real software.

Key terms: FP, functional programming, definition

1.6 The definition of FP confuses managers

A brief email-service scenario shows why a definition of functional programming centered on avoiding side effects can mislead a manager.

• Side effect definition conflict: Explain why the manager might think functional programming is unsuitable for Jenna’s email-sending service, despite her reason for wanting to use it.
  Why it matters: The apparent contradiction shows how that definition can obscure Jenna’s practical reason for using FP.

Key terms: functional programming, side effects

1.7 We treat functional programming as a set of skills and concepts

The section frames functional programming as practical, transferable skills and concepts rather than a single definition or a collection of language-specific techniques.

• Practical and transferable FP skills: Explain why the book treats functional programming as a set of useful skills and concepts rather than relying on a typical definition. Describe how its most important ideas can apply across programming languages and coding styles.
  Why it matters: You can use the book’s ideas without switching to a functional programming language.

Key terms: functional programming, skills and concepts, object-oriented and procedural code

1.8 Distinguishing actions, calculations, and data

Introduces the three-way classification of code and explains why actions require care about when and how often they run.

• Actions calculations and data: Explain that functional programmers classify code as actions, calculations, or data, and identify actions by their dependence on when or how many times they run.
  Why it matters: This distinction helps you spot code whose execution needs special care.

Key terms: actions, calculations, data

1.9 Functional programmers distinguish code that matters when you call it

This section separates actions, whose effects depend on when or how often they run, from code such as a sum that does not.

• Call-sensitive actions and stable sums: Distinguish actions from a sum by explaining why the timing or number of calls matters for actions but not for the sum.
  Why it matters: The distinction tells you which code needs extra care because its behavior can depend on timing or repetition.

Key terms: actions, sum

1.10 Functional programmers distinguish inert data from code that does work

This section distinguishes inert data from executable calculations and explains why functional programmers generally prefer data when it fits the task.

• Data and calculation distinction: Distinguish data from calculations: neither depends on when or how often it is used, but calculations execute while data does not.
  Why it matters: This distinction helps you recognize different kinds of code when you read a program.
• Preference among three categories: Explain why functional programmers generally prefer data to calculations and calculations to actions without treating any category as forbidden.
  Why it matters: The preference is a guide for choosing the right tool, not a rule against actions or calculations.

Key terms: data, calculations, inert, transparent, opaque, actions, tradeoffs

1.11 Functional programmers see actions, calculations, and data

The section introduces a project-management notification scenario to set up a later illustration of actions, calculations, and data.

1.12 Step 1: The user marks a task as completed.

1.13 Step 2: The client sends a message to the server.

1.14 Step 3: The server receives the message.

1.15 Step 4: The server makes a change to its database.

1.16 Step 5: The server makes a decision of who to notify.**

1.17 Step 6: The server sends an email notification.**

The section distinguishes deciding to send an email from actually sending it.

• Email decision and action: Explain why sending an email is an action and distinguish it from the calculation that decides whether to send it.
  Why it matters: This distinction helps you identify which part of the notification process makes a decision and which part has an effect.

Key terms: action, calculation

1.18 The three categories of code in FP

1.19 Actions

Defines actions as things whose effects depend on when or how many times they run.

• Timing and frequency of actions: Explain that something is an action if its effect depends on when it runs, how many times it runs, or both, using the email example.
  Why it matters: This gives you a way to recognize actions in code.

Key terms: actions

1.20 2. Calculations

Defines calculations by their predictable outputs and lack of outside effects, and explains why they are easy to test and safe to call.

• Calculation behavior and benefits: Explain that a calculation computes an output from an input, always returns the same output for the same input, and does not affect anything outside itself. Describe why this makes it easy to test and safe to call at any time or more than once.
  Why it matters: These properties let you recognize code you can test and call without worrying about timing or repeated calls.

Key terms: calculations, input, output

1.21 3. Data

This section defines data as recorded facts that are meaningful without being executed and can serve different purposes.

• Meaning and uses of data: Explain what the section means by data and why the same data can be useful in different ways.
  Why it matters: Recognizing data as meaningful records helps you distinguish it from code that does work.

Key terms: data, recorded facts, executable code

1.23 FP works great for distributed systems, and most software written today is distributed

The section explains why distributed software makes functional programming valuable: moving code into data and calculations reduces dependence on unpredictable timing and repetition, while isolating the actions that remain.

• Distributed software uncertainty: Explain why functional programming has become more relevant as software increasingly communicates across networks, and describe the uncertainty that network messages introduce.
  Why it matters: Network uncertainty explains why it helps to reduce code’s dependence on when or how often something happens.
• Calculations and isolated actions: Explain why moving code into data and calculations helps with distributed-system uncertainty, while actions still require attention.
  Why it matters: Separating calculations and data from actions narrows the code that needs special care under network uncertainty.

Key terms: FP, distributed systems, messages, data, calculations, actions

1.25 This book is practical for software engineering

This section contrasts the book’s practical approach to functional programming with a more academic focus.

• Practical functional programming focus: Explain how this book’s approach to functional programming differs from the academic emphasis the section describes.
  Why it matters: This distinction sets the expectation that the book favors usable engineering practices without dismissing theory.

Key terms: FP, pragmatic experience, theoretical ideas

1.26 This book uses real-world scenarios

The section says the book uses job-like scenarios to illustrate functional thinking rather than textbook algorithms.

1.27 This book focuses on software design

The section explains why functional programming needs software design principles as programs grow, from individual lines of code to entire applications.

• Design across software scales: Explain why small programs may not need architecture but larger, long-lived systems do, and describe the range of scale at which the book applies functional design principles.
  Why it matters: It connects functional design to the practical challenge of keeping growing systems maintainable.

Key terms: architecture, design principles, functional design principles, maintainable

1.28 This book conveys the richness of FP

This section presents functional programming as a long-standing body of principles and techniques that remains relevant despite changes in computing.

• Enduring functional programming ideas: Explain that functional programmers have developed principles and techniques since the 1950s, and that many have remained useful as computing has changed.
  Why it matters: It frames functional thinking as an established body of ideas rather than a recent trend.

Key terms: functional programmers, principles and techniques, functional thinking

1.29 This book is language agnostic

The section explains why the book uses JavaScript examples while teaching functional thinking that applies across languages.

• Language independent functional thinking: Explain why using JavaScript for examples does not make the book a guide to functional programming in JavaScript: readers should focus on the thinking, and JavaScript’s limitations can prompt them to stop and think.
  Why it matters: You can apply the ideas even if you write code in another language.

Key terms: language agnostic, functional thinking, JavaScript

1.30 What is functional thinking?

Defines functional thinking as the skills and ideas functional programmers use to solve software problems, then introduces the book’s two areas of focus.

• Functional thinking as practical skills: Explain what the section means by functional thinking: the skills and ideas functional programmers use to solve problems with software.
  Why it matters: This definition frames functional programming as something you can apply when solving software problems.

Key terms: functional thinking, skills and ideas

1.31 Part 1: Distinguishing actions, calculations, and data

The section frames functional thinking as separating code into actions, calculations, and data, a distinction related to how easy code is to understand, test, and reuse.

• Three categories of code: Explain that functional programmers separate code into actions, calculations, and data, and that these categories correspond to differences in how difficult code is to understand, test, and reuse.
  Why it matters: This distinction gives you a way to think about code in terms of understandability, testability, and reuse.

Key terms: actions, calculations, data

1.32 Part 2: Using first-class abstractions

The section introduces passing procedures to other procedures as a practical way to reuse more code.

• Reuse through passed procedures: Explain how passing a procedure to another procedure can let programmers reuse more than naming a common procedure alone.
  Why it matters: This is the section’s central reason for introducing first-class abstractions.

Key terms: procedures, reuse, passing in procedures

1.33 Ground rules for ideas and skills in this book

The section explains that functional programming is too broad to cover in full and introduces ground rules for selecting practical topics for working programmers.

1.34 The skills can’t be based on language features

Functional thinking can help programmers regardless of whether their language has features designed for functional programming.

• Language-independent functional thinking: Explain why a programmer can use functional thinking without a language that provides special functional-programming features.
  Why it matters: You can apply the book’s approach in the language you already use.

Key terms: functional thinking, language-feature agnostic, type systems

1.35 2. The skills must have immediate practical benefit

This section sets immediate practical benefit as a requirement for the functional programming skills taught in the book.

• Immediate practical benefit: Explain why a functional programming skill can be useful right away even if it does not change your code, using the section’s example of identifying actions.
  Why it matters: A useful programming skill can improve how you diagnose a problem before you edit anything.

Key terms: immediate practical benefit, actions

1.36 3. The skills must apply regardless of your current code situation

This section explains why functional thinking is practical across existing codebases, programming languages, and everyday software work.

• Pragmatic use in existing code: Explain how the book’s skills apply whether you are starting a project or working in a large existing codebase.
  Why it matters: You can apply these ideas without replacing your current system.
• Language independence and JavaScript: Explain why the book can be useful to programmers using object-oriented languages and why it uses JavaScript despite its imperfections for FP.
  Why it matters: You can practice the principles in a language you already use.
• Professional functional thinking: Distinguish the book’s practical focus from the academic emphasis on FP, and explain what the term “functional thinking” signals.
  Why it matters: The book frames FP as a way to solve ordinary programming problems, not just an academic ideal.

Key terms: functional rewrite, pragmatic choices, functional thinking, JavaScript, object-oriented (OO) language, functional programming, standard definition, side effects

1.37 Conclusion

The conclusion identifies the distinction between actions, calculations, and data as the starting point for practical functional programming across languages and problems.

• Functional programming starting point: Explain that the practical approach to functional programming in this book starts by distinguishing actions, calculations, and data.
  Why it matters: This distinction gives you a starting point for the practical techniques that follow.
• Practical reach of FP: Describe the conclusion's claim that the book's practical approach to functional programming can apply in any language and to any problem.
  Why it matters: You need not switch languages or work on a special kind of problem to consider these ideas.

Key terms: functional programming, actions, calculations, data, practical side of FP, any language, any problem

1.38 Summary

1.39 Up next…

This section previews examples of functional thinking in the next chapter.