Translator's Preface xvii
Beta Reader Review xix
Recommendation xxi
Preface xxvi
Acknowledgments xxviii
About this book xxx

CHAPTER 1 Welcome to Functional Coding: A Simple Guide to Learning

What is functional programming? 2
Problems with Functional Programming Definitions from a Practical Perspective 3
Functional Programming Definitions Confuse Managers 4
5. Viewing Functional Programming as a Technique and Concept, Not an Academic Knowledge
Distinguishing Actions, Calculations, and Data 6
Functional programmers distinguish between code that must be called with caution 7
Functional programmers distinguish between code that runs and code that doesn't 8
Functional programmers separate actions, computations, and data. 9
In functional programming, code is divided into three categories: 10
What are the benefits of separating actions, calculations, and data? 11
12 Differences Between This and Other Functional Programming Books
What is functional thinking? 13
14 Basic Rules for Reading This Book
Conclusion 16

CHAPTER 2 Functional Thinking in Real Life 17

Welcome to Tony's Pizza 18
Part I: Actions and Computation, Data 19
Split code by changeability 20
Part II: First-Class Abstraction 21
Visualizing Distributed Systems as a Timeline 22
Each timeline runs in a different order 23
24 Things I Learned About Distributed Systems Through Hard Experience
Timeline Cutting: Making Robots Wait for Each Other 25
26 Things I Learned About Timelines Through Good Experience
Conclusion 27

PART I Actions, Calculations, and Data

CHAPTER 3 Understanding the Difference Between Actions, Calculations, and Data 31

Actions and Calculations, Data 32
Actions, calculations, and data can be applied anywhere 33
36 Things I Learned While Shopping
Applying Functional Thinking to New Code 39
Sketching the process of sending coupons 42
Implementing the Coupon Sending Process 47
Applying Functional Thinking to Existing Code 54
Actions spread throughout the code 56
Action comes in many forms 57
Conclusion 59

CHAPTER 4 Taking Calculations Out of Actions 61

Welcome to MegaMart.com 62
Calculate Free Shipping 63
Calculating Taxes 64
Making Testing Easy 65
Making it easy to reuse 66
Separating Actions, Calculations, and Data 67
Functions have inputs and outputs 68
Testing and reusability are related to input/output 69
Taking calculations out of action 70
Taking another calculation out of action 73
Let's look at the full code 85
Conclusion 86

CHAPTER 5 CREATING BETTER ACTIONS 87

Aligning business requirements with design 88
Aligning business requirements and functions 89
Principle: The fewer implicit inputs and outputs, the better 91
Reducing Implicit Input and Output 92
Revisiting the Code 95
Classifying Calculations 97
Principle: Design is untangling code 98
Separating add_item() to Create a Better Design 99
Extracting the Copy-On-Write Pattern 100
Using add_item() 101
Classifying Calculations 102
Small functions and many calculations 106
Conclusion 107

CHAPTER 6 Maintaining Immutability in Languages ​​with Mutable Data Structures 109

Can all actions be made invariant? 110
Classifying actions as reading, writing, or both 111
The Copy-On-Write Principle: Three Steps 112
Converting Writing to Reading with Copy-On-Write 113
View differences between the original and copy-on-write versions 117
The copy-on-write operation we created earlier is common 118
A Look at JavaScript Arrays 119
How do I read while writing? 122
Separating functions that are read while writing 123
Create a function that returns two values ​​124
Reading immutable data structures is computational 131
The application has a state that changes over time 132
Immutable data structures are fast enough 133
Copy-on-write for objects 134
A quick look at JavaScript objects 135
Converting nested writes to reads 140
What kind of copy would it be? 141
A Pictorial Exploration of Shallow Copying and Structural Sharing 142
Conclusion 145

CHAPTER 7 Maintaining Invariance While Writing Untrusted Code 147

Legacy Code and Immutability 148
The copy-on-write code we create must interact with untrusted code. 149
Defensive copying prevents the original from being altered 150
Implementing Defensive Copying 151
Defensive Copy Rule 152
Wrapping Untrusted Code 153
Defensive copying may be familiar to you 156
Let's compare copy-on-write and defensive copying 158
Deep copies are more expensive than shallow copies 159
Implementing deep copies in JavaScript is difficult 160
A Dialogue Between Copy-on-Write and Defensive Copying 162
Conclusion 165

CHAPTER 8 HIERARCHICAL DESIGN I 167

What is Software Design? 168
What is hierarchical design? 169
Developing Design Sense 170
Hierarchical Design Pattern 171
Pattern 1: Direct Implementation 172
3-step zoom level 186
Removing loops 189
Direct Implementation Pattern Review 198
Conclusion 199

CHAPTER 9 HIERARCHICAL DESIGN II 201

Hierarchical Design Pattern 202
Pattern 2: Abstract Wall 203
Hiding the implementation behind an abstraction wall 204
Hiding details is symmetrical 205
Changing the Shopping Cart Data Structure 206
Re-creating the shopping cart as an object 208
With a wall of abstraction, you don't have to worry about specifics. 209
When is it a good idea to use an abstract wall? 210
Pattern 2 Review: Abstract Wall 211
The previously modified code is closer to a direct implementation 212
Pattern 3: Small Interface 213
Pattern 3 Review: Small Interface 219
Pattern 4: Convenient Layer 220
Hierarchical Design Pattern 221
What information about the code can be gleaned from the graph? 222
The code at the top of the graph is the easiest to fix 223
The code below is important to test 225
The code below is better for reuse 228
Summary: What the Graph Tells You About Your Code 229
Conclusion 230

PART II First-Class Abstract

CHAPTER 10: First-Class Functions I 233

The marketing team still needs to consult with the development team 235
Code Smells: Implicit Arguments in Function Names 236
Refactoring: Exposing Implicit Arguments 238
Distinguishing between first-class and non-first-class 240
Won't using field names as strings cause bugs? 241
Does using first-class fields make API changes more difficult?
You will be using too many objects and arrays 247
Any grammar can be converted into a first-class function 250
Loop Example: Eat and Clean Up 253
Refactoring: Replacing a Function Body with a Callback 259
What grammar is this? 262
Why wrap the body in a function and pass it? 263
Conclusion 265

CHAPTER 11 First-Class Functions II 267

One code smell and two refactorings 268
Copy-on-Write Refactoring 269
Copy-on-Write Refactoring for Arrays 270
Functions that return functions 279
Conclusion 288

CHAPTER 12 Functional Iteration 289

One code smell and two refactorings 290
MegaMart has decided to create a communications team. 291
Deriving the map() function through examples 294
Functional Tools: map() 295
Three Ways to Pass Functions 297
Example: All customers' email addresses 298
Deriving the filter() function through examples 301
Functional Tools: filter() 302
Example: Customer 303 who did not purchase anything
Deriving reduce() with examples 306
Functional Tools: reduce() 307
Example: Concatenating Strings 308
313 Things You Can Do with reduce()
Comparing Three Functional Tools 315
Conclusion 316

CHAPTER 13: Functional Tool Chaining 317

The Customer Communications Team is still working 318
Making the Chain Clear 1: Naming the Steps 324
Making Chains Clearer 2: Naming Callbacks 325
Making the Chain Clear 3: Comparing the Two Methods 326
Example: Email list of customers who have only made a purchase once 327
Refactoring Loops with Functional Tools 332
Tip 1: Creating Data 333
Tip 2: Manipulating an Entire Array at Once 334
Tip 3: Break it down into smaller steps 335
Comparing Procedural and Functional Code 337
Chaining Tip Summary 338
Tips for Chaining Debugging 340
Various functional tools 341
reduce() to create values ​​345
Get Creative with Data 347
Sorting by method operator 353
Conclusion 354

CHAPTER 14 Using Functional Tools with Nested Data 355

Higher-Order Functions for Manipulating Objects 356
Make field names explicit 357
Deriving update() 358
Using update() to change values ​​359
Refactoring: Replace Get, Change, and Set with update() 361
Functional Tools: update() 362
Visualizing values ​​in objects 363
Visualizing Nested Updates 368
Using update() with nested data 369
Deriving updateOption() 370
Deriving update2() 371
Visualizing update2() for nested objects 372
Four Ways to Create incrementSizeByName() 374
Deriving update3() 375
Deriving nestedUpdate() 377
Safe Recursion Usage 382
Visualizing nestedUpdate() 383
Why Recursive Functions Are Suitable 384
386 Things to Consider When Designing Deeply Nested Structures
Using Abstraction Walls for Deeply Nested Data 387
Higher-order functions learned previously 388
Conclusion 389

CHAPTER 15: Isolating the Timeline 391

There's a bug! 392
Let's double click quickly 393
A timeline diagram shows what happens over time 395
Two Timeline Diagram Basic Rules 396
Two facts about the action sequence that you might miss if you look closely 400
Drawing an add-to-cart timeline: Steps 1-401
Asynchronous calls draw to a new timeline 402
Different languages, different thread models 403
Creating a Timeline Step by Step 404
Drawing an add-to-cart timeline: Step 2 406
You can see from the timeline diagram that there are two types of code that are executed sequentially 407
A timeline diagram shows that concurrently executing code has an unpredictable order 408
Principle 409 of a Good Timeline
Single-Threaded JavaScript 410
Asynchronous Queues in JavaScript 411
AJAX and Event Queues 412
Complete Asynchronous Example 413
Simplifying the Timeline 414
Reading the Completed Timeline 420
Simplifying Your Add-to-Cart Timeline: Step 3 422
Review: Drawing a Timeline (Steps 1-3) 424
Summary: Drawing a Timeline Diagram 426
If you look at the timelines side by side, you can see the problem 427
Double click slowly and there is no problem 428
Double clicking quickly gives incorrect results 429
Timelines that share resources can be problematic 430
Converting global variables to local variables 431
Converting global variables to arguments 432
Making Code More Reusable 435
Principle: Callbacks can be used instead of return values ​​for explicit output in asynchronous calls 436
Conclusion 440

CHAPTER 16 Sharing Resources Between Timelines 441

Principles of a Good Timeline 442
There is still a bug in the cart 443
We must ensure the order in which the DOM is updated 445
Creating a Queue in JavaScript 447
Principle: Inspiring Reality in How to Share 455
Making Queues Reusable 456
Analyzing the Timeline Created So Far 461
Rule: If you think there's a problem, look at the timeline diagram. 464
Make the queue skip 465
Conclusion 469

CHAPTER 17: Tune Your Timeline 471

Principles of a Good Timeline 472
There's a bug! 473
How did the code change? 475
Check the action: Step 1 476
Drawing All Actions: Step 2 477
Simplifying the Diagram: Step 3 481
Analyzing the Executable Sequence 483
Why is the timeline faster now? 484
Wait for all parallel callbacks 486
Concurrency primitives for dividing timelines 487
Applying Cut() to Code 489
Analyzing Uncertain Orders 491
Parallel Execution Analysis 492
Analysis 493 when clicking multiple times
Basic 500, called only once
Implicit vs. Explicit Time Models 502
Summary: Using the Timeline 507
Conclusion 508

CHAPTER 18 Reactive Architecture and Onion Architecture 509

The two architectural patterns are independent 510
Strongly linked cause and effect for change 511
What is reactive architecture? 512
Tradeoffs in Responsive Architecture 513
Cell is in first class condition 514
You can make ValueCell responsive 515
You can update the shipping icon when the cell changes 516
FormulaCell calculates derived values ​​517
Functional Programming and Mutable State 518
How Reactive Architecture Changed Systems 519
Separate the combination of cause and effect 520
The separation of union governs the center of cause and effect 521
Process multiple steps in a pipeline 522
The timeline becomes more flexible 523
Another architectural pattern 526
What is Onion Architecture? 527
Revisit: Actions and Calculations, Data 528
Revisit: Hierarchical Design 529
Traditional hierarchical architecture 530
Functional Architecture 531
It should be easy to change and reuse 532
Domain rules use domain terms 535
Readability should be considered 536
Conclusion 539

CHAPTER 19: Before Your Functional Programming Journey 541

Final Chapter Plan 542
I learned the skills of an expert 543
544 Things to Remember
Changes in Skills and Passions Over Time 545
Becoming a Master with Two Tracks 546
Sandbox: Start a Side Project 547
Sandbox: Training with Practice Problems 548
Product: Get rid of bugs today 549
Product: Improve Your Design One Step at a Time 549
550 Popular Functional Programming Languages
The functional language with the most jobs (552)
552 functional languages ​​available on various platforms
553 Functional Languages, Divided by What You Can Learn
Gaining Mathematical Knowledge 554
Further Reading 555
Conclusion 556

Search 557

How do functional developers think and write code?

Functional programming is a new way of programming that is different from procedural programming and object-oriented programming.
So learning functional programming means learning a new way of thinking.
So how do functional developers think and create software?
This book begins by covering side effects, the most fundamental aspect of functional programming.
First, we'll learn how to distinguish between actions (functions with side effects) and computations (computations without side effects). After distinguishing between the two, we'll discuss how to reduce actions with side effects and what techniques exist for turning actions into computations.
Next, we will learn the concept of first-class functions and explain how to reduce loops using higher-order functions.
Learning this will allow you to reuse functional units of code and make testing easier.
This process is explained step by step so that you can easily understand and follow how to apply what you have learned in theory.

The example code used in this book is written in JavaScript.
JavaScript isn't a perfect functional language, but it lacks the features of functional languages, making it a good language for demonstrating functional thinking.
It explains functional concepts in more depth by creating insufficient functional functions yourself.
This book tells the story by creating realistic cases.
It is structured to be fun and engaging, as if you were part of a company's development team.
By joining the development team, you can observe firsthand how functional developers think about creating software.
Even if you don't use a functional language or aren't interested in functional programming, learning functional thinking will help you develop problem-solving skills through a new way of thinking.
I recommend this book to readers who want to learn functional programming, as well as to all developers who want to make their programming a little more concise and clean.

Target audience

■ Professionals with 2 to 5 years of software development experience
■ Developers who are creating simple systems but have difficulty handling large systems