Grokking Simplicity

Taming complex software with functional thinking

Eric Normand

• Publisher: Manning
• Year: 2021
• Print ISBN: 9781617296208
• eBook ISBN: 9781638350460
• Topic: Computer Science
• Subtopic: Programming
• Index: Computer Science

"The most insightful and intuitive guide to clean and simple software. I recommend this to all software developers." - Rob Pacheco, Vision Government Solutions Grokking Simplicity is a friendly, practical guide that will change the way you approach software design and development. Distributed across servers, difficult to test, and resistant to modification—modern software is complex. Grokking Simplicity is a friendly, practical guide that will change the way you approach software design and development. It introduces a unique approach to functional programming that explains why certain features of software are prone to complexity, and teaches you the functional techniques you can use to simplify these systems so that they're easier to test and debug. Purchase of the print book includes a free eBook in PDF, Kindle, and ePub formats from Manning Publications. About the technology
Developers rightly fear the unintended complexity that infects most code. This book shows you how to write software that keeps complexity close to its inherent minimum. As you write software you should distinguish between code that alters your system's state, and code that does not. Once you learn to make that distinction, you can refactor much of your state-altering "actions" into stateless "calculations." Your software will be simpler. About the book
The book also teaches you to solve the complex timing bugs that inevitably creep into asynchronous and multithreaded code. In ad­vanced sections of the book you learn how composable abstractions help avoid repeating code and open up new levels of expressivity. What's inside
Patterns for simpler code
Powerful time modeling approaches to simplify asynchronous code
How higher-order functions can make code reusable and composable About the reader
For intermediate and advanced developers building complex software. Exercises, illustrations, self-assessments, and hands-on examples lock in each new idea. About the author
Eric Normand is an expert software developer who has been an influential teacher of functional programming since 2007. Table of Contents
1 Welcome to Grokking Simplicity
2 Functional thinking in action
PART 1 - ACTIONS, CALCULATIONS, AND DATA
3 Distinguishing actions, calculations, and data
4 Extracting calculations from actions
5 Improving the design of actions
6 Staying immutable in a mutable language
7 Staying immutable with untrusted code
8 Stratified design, part 1
9 Stratified design, part 2
PART 2 - FIRST-CLASS ABSTRACTIONS
10 First-class functions, part 1
11 First-class functions, part 2
12 Functional iteration
13 Chaining functional tools
14 Functional tools for nested data
15 Isolating timelines
16 Sharing resources between timelines
17 Coordinating timelines
18 Reactive and onion architectures
19 The functional journey ahead

1 Welcome to Grokking Simplicity

In this chapter

• Learn the definition of functional thinking.
• Understand how this book is different from other books on functional programming.
• Discover the primary distinction that functional programmers make when they look at code.
• Decide whether this book is for you.

In this chapter, we will define functional thinking and how its major distinction helps working programmers build better software. We will also get an overview of the journey ahead through two major insights that functional programmers experience.

What is functional programming?

Programmers ask me all the time what functional programming (FP) is and what it’s good for. What FP is good for is difficult to explain because it is a general-purpose paradigm. It’s good for everything. We’ll see where it really shines in just a few pages.

Defining functional programming is difficult, too. Functional programming is a huge field. It’s used in both the software industry and in academia. However, most of what has been written about it is from academia.

Grokking Simplicity takes a different approach from the typical book about functional programming. It is decidedly about the industrial uses of functional programming. Everything in this book needs to be practical for working software engineers.

You may come across definitions from other sources, and it’s important to understand how they relate to what we’re doing in this book. Here is a typical definition paraphrased from Wikipedia:

functional programming (FP), noun.

1. a programming paradigm characterized by the use of mathematical functions and the avoidance of side effects**
   ** we need to define the underlined terms
2. a programming style that uses only pure functions without side effects

Let’s pick apart the underlined terms.

Side effects are anything a function does other than returning a value, like sending an email or modifying global state. These can be problematic because the side effects happen every time your function is called. If you need the return value and not the side effects, you’ll cause things to happen unintentionally. It is very common for functional programmers to avoid unnecessary side effects.

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. We can consider these mathematical functions to distinguish them from the language feature called /functions/. 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. Working functional programmers will use side effects and impure functions.

Common side effects include

• Sending an email
• Reading a file
• Blinking a light
• Making a web request
• Applying the brakes in a car

these are why we run software in the first place!

The problems with the definition for practical use

The definition might work well for academia, but it has a number of problems for the working software engineer. Let’s look at the definition again:

functional programming (FP), noun.

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

There are three main problems with this definition for our purposes.

Problem 1: FP needs side effects

The definition says FP avoids side effects, but side effects are the very reason we run our software. What good is email software that doesn’t send emails? The definition implies that we completely avoid them, when in reality, we use side effects when we have to.

Vocab time

Side effects are any behavior of a function besides the return value.

Pure functions depend only on their arguments and don’t have any side effects.

Problem 2: FP is good at side effects

Functional programmers know side effects are necessary yet problematic, so we have a lot of tools for working with them. 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 makes FP seem like it’s mostly mathematical and impractical for real-world software. There are many important software systems written using functional programming.

The definition is especially confusing to people who are introduced to FP through the definition. Let’s see an example of a well-intentioned manager who reads the definition on Wikipedia.

The definition of FP confuses managers

Imagine a scenario where Jenna, the eager programmer, wants to use FP for an email-sending service. She knows FP will help architect the system to improve dependability. Her manager doesn’t know what FP is, so he has to look up the definition on Wikipedia.

The manager looks up “functional programming” on Wikipedia:

… the avoidance of side effects…

He Googles “side effect.” Common side effects include

• sending an email
• …

Later that day…

We treat functional programming as a set of skills and concepts

We’re not going to use the typical definition in this book. FP is many things to many people, and it is a huge field of study and practice.

I’ve talked with many working functional programmers about what they find most useful from FP. Grokking Simplicity is a distillation of the skills, thought processes, and perspectives of working functional programmers. Only the most practical and powerful ideas made it into this book.

In Grokking Simplicity, you won’t find the latest research or the most esoteric ideas. We’re only going to learn the skills and concepts you can apply today. While doing this research I’ve found that the most important concepts from FP apply even in object-oriented and procedural code, and across all programming languages. The real beauty of FP is that it deals with beneficial, universal coding practices.

Let’s take a crack at the skill any functional programmer would say is important: the distinction between actions, calculations, and data.

Distinguishing actions, calculations, and data

When functional programmers look at code, they immediately begin to classify code into three categories:

1. Actions
2. Calculations
3. Data

Here are some snippets of code from an existing codebase. You need to be more careful with the snippets with stars.

The starred functions need caution because they depend on when they are run or how many times they are run. For instance, you don’t want to send an important email twice, nor do you want to send it zero times.

The starred snippets are actions. Let’s separate those from the rest.

Functional programmers distinguish code that matters when you call it

Let’s draw a line and m...

Table of contents

• Grokking Simplicity
• Copyright
• contents
• front matter
• 1 Welcome to Grokking Simplicity
• 2 Functional thinking in action
• Part 1. Actions, calculations, and data
• 3 Distinguishing actions, calculations, and data
• 4 Extracting calculations from actions
• 5 Improving the design of actions
• 6 Staying immutable in a mutable language
• 7 Staying immutable with untrusted code
• 8 Stratified design: Part 1
• 9 Stratified design: Part 2
• Part 2. First-class abstractions
• 10 First-class functions: Part 1
• 11 First-class functions: Part 2
• 12 Functional iteration
• 13 Chaining functional tools
• 14 Functional tools for nested data
• 15 Isolating timelines
• 16 Sharing resources between timelines
• 17 Coordinating timelines
• 18 Reactive and onion architectures
• 19 The functional journey ahead
• index