Grokking Simplicity: Taming complex software with functional thinking

foreword
preface
acknowledgments
about this book
about the author
Welcome to Grokking Simplicity
What is functional programming?
The problems with the definition for practical use
The definition of FP confuses managers
We treat functional programming as a set of skills and concepts
Distinguishing actions, calculations, and data
Functional programmers distinguish code that matters when you call it
Functional programmers distinguishinert data from code that does work
Functional programmers seeactions, calculations, and data
The three categories of code in FP
How does distinguishingactions, calculations, and data help us?
Why is this book different from other FP books?
What is functional thinking?
Ground rules for ideas and skills in this book
Conclusion
Summary
Up next . . .
Functional thinking in action
Welcome to Toni’s Pizza
Part 1: Distinguishing actions, calculations, and data
Organizing code by “rate of change”
Part 2: First-class abstractions
Timelines visualize distributed systems
Multiple timelines can execute in different orderings
Hard-won lessons about distributed systems
Cutting the timeline:Making the robots wait for each other
Positive lessons learned about timelines
Conclusion
Summary
Up next . . .
Distinguishing actions, calculations, and data
Actions, calculations, and data
Actions, calculations, and data apply to any situation
Lessons from our shopping process
Deep dive: Data
Applying functional thinking to new code
Drawing the coupon email process
Implementing the coupon email process
Applying functional thinking to existing code
Actions spread through code
Actions can take many forms
Deep dive: Actions
Conclusion
Summary
Up next . . .
Extracting calculations from actions
Welcome to MegaMart.com!
Calculating free shipping
Calculating tax
We need to make it more testable
We need to make it more reusable
Distinguishing actions, calculations, and data
Functions have inputs and outputs
Testing and reuse relate to inputs and outputs
Extracting a calculation from an action
Extracting another calculation from an action
Let’s see all of our code in one place
Conclusion
Summary
Up next . . .
Improving the design of actions
Aligning design with business requirements
Aligning the function with business requirements
Principle:Minimize implicit inputs and outputs
Reducing implicit inputs and outputs
Giving the code a once-over
Categorizing our calculations
Principle:Design is about pulling things apart
Improving the design by pulling add_item() apart
Extracting a copy-on-write pattern
Using add_item()
Categorizing our calculations
Smaller functions and more calculations
Conclusion
Summary
Up next . . .
Staying immutablein a mutable language
Can immutability be applied everywhere?
Categorizing operations into reads, writes, or both
The three steps of the copy-on-write discipline
Converting a write to a read with copy-on-write
Complete diff from mutating to copy-on-write
These copy-on-write operations are generalizable
JavaScript arrays at a glance
What to do if an operation is a read and a write
Splitting a function that does a read and write
Returning two values from one function
Reads to immutable data structures are calculations
Applications have state that changes over time
Immutable data structures are fast enough
Copy-on-write operations on objects
JavaScript objects at a glance
Converting nested writes to reads
What gets copied?
Visualizing shallow copies and structural sharing
Conclusion
Summary
Up next . . .
Staying immutable with untrusted code
Immutability with legacy code
Our copy-on-write code has to interact with untrusted code
Defensive copying defends the immutable original
Implementing defensive copies
The rules of defensive copying
Wrapping untrusted code
Defensive copying you may be familiar with
Copy-on-write and defensive copying compared
Deep copies are more expensive than shallow copies
Implementing deep copy in JavaScript is difficult
A dialogue between copy-on-write and defensive copying
Conclusion
Summary
Up next . . .
Stratified design:Part 1
What is software design?
What is stratified design?
Developing our design sense
Patterns of stratified design
Pattern 1: Straightforward implementations
Three different zoom levels
Extracting the for loop
Pattern 1 Review: Straightforward implementation
Conclusion
Summary
Up next . . .
Stratified design: Part 2
Patterns of stratified design
Pattern 2: Abstraction barrier
Abstraction barriers hide implementations
Ignoring details is symmetrical
Swapping the shopping cart’s data structure
Re-implementing the shopping cart as an object
The abstraction barrier lets us ignore details
When to use (and when not to use!) abstraction barriers
Pattern 2 Review: Abstraction barrier
Our code is more straightforward
Pattern 3: Minimal interface
Pattern 3 Review: Minimal interface
Pattern 4: Comfortable layers
Patterns of stratified design
What does the graph show us about our code?
Code at the top of the graph is easier to change
Testing code at the bottom is more important
Code at the bottom is more reusable
Summary: What the graph shows us about our code
Conclusion
Summary
Up next . . .
First-class functions: Part 1
Marketing still needs to coordinate with dev
Code smell: Implicit argument in function name
Refactoring: Express implicit argument
Recognize what is and what isn’t first-class
Will field names as strings lead to more bugs?
Will first-class fields make the API hard to change?
We will use a lot of objects and arrays
First-class functions can replace any syntax
For loop example: Eating and cleaning up
Refactoring: Replace body with callback
What is this syntax?
Why are we wrapping the code in a function?
Conclusion
Summary
Up next . . .
First-class functions: Part 2
One code smell and two refactorings
Refactoring copy-on-write
Refactoring copy-on-write for arrays
Returning functions from functions
Conclusion
Summary
Up next . . .
Functional iteration
One code smell and two refactorings
MegaMart is creating a communications team
Deriving map() from examples
Functional tool: map()
Three ways to pass a function
Example: Email addresses of all customers
Deriving filter() from examples
Functional tool: filter()
Example: Customers with zero purchases
Deriving reduce() from examples
Functional tool: reduce()
Example: Concatenating strings
Things you can do with reduce()
Three functional tools compared
Conclusion
Summary
Up next . . .
Chaining functional tools
The customer communications team continues
Clarifying chains, method 1: Name the steps
Clarifying chains, method 2: Naming the callbacks
Clarifying chains: Two methods compared
Example: Emails of customers who have made one purchase
Refactoring existing for loops to functional tools
Tip 1: Make data
Tip 2: Operate on whole array at once
Tip 3: Take many small steps
Tip 3: Take many small steps
Comparing functional to imperative code
Summary of chaining tips
Debugging tips for chaining
Many other functional tools
reduce() for building values
Getting creative with data representation
Line up those dots
Conclusion
Summary
Up next . . .
Functional tools for nested data
Higher-order functions for values in objects
Making the field name explicit
Deriving update()
Using update() to modify values
Refactoring: Replace get, modify, set with update()
Functional tool: update()
Visualizing values in objects
Visualizing nested updates
Applying update() to nested data
Deriving updateOption()
Deriving update2()
Visualizing update2() on nested objects
Writing incrementSizeByName() four ways
Deriving update3()
Deriving nestedUpdate()
The anatomy of safe recursion
Visualizing nestedUpdate()
The superpower of recursion
Design considerations with deep nesting
Abstraction barriers on deeply nested data
A summary of our use of higher-order functions
Conclusion
Summary
Up next . . .
Isolating timelines
There’s a bug!
Now we can try to click twice fast
The timeline diagram shows what happens over time
The two fundamentals of timeline diagrams
Two tricky details about the order of actions
Drawing the add-to-cart timeline: Step 1
Asynchronous calls require new timelines
Different languages, different threading models
Building the timeline step-by-step
Drawing the add-to-cart timeline: Step 2
Timeline diagrams capture the two kinds of sequential code
Timeline diagrams capture the uncertain ordering of parallel code
Principles of working with timelines
JavaScript’s single-thread
JavaScript’s asynchronous queue
AJAX and the event queue
A complete asynchronous example
Simplifying the timeline
Reading our finished timeline
Simplifying the add-to-cart timeline diagram: Step 3
Review: Drawing the timeline (steps 1–3)
Summary: Drawing timeline diagrams
Timeline diagrams side-by-side can reveal problems
Two slow clicks get the right result
Two fast clicks can get the wrong result
Timelines that share resources can cause problems
Converting a global variable to a local one
Converting a global variable to an argument
Making our code more reusable
Principle: In an asynchronous context, we use a final callback instead of a return value as our explicit output
Conclusion
Summary
Up next . . .
Sharing resources between timelines
Principles of working with timelines
The shopping cart still has a bug
We need to guarantee the order of the DOM updates
Building a queue in JavaScript
Principle:Use real-world sharing as inspiration
Making the queue reusable
Analyzing the timeline
Principle:Analyze the timeline diagram to know if there will be problems
Making the queue skip
Conclusion
Summary
Up next . . .
Coordinating timelines
Principles of working with timelines
There’s a bug!
How the code was changed
Identify actions: Step 1
Draw each action: Step 2
Simplify the diagram: Step 3
Possible ordering analysis
Why this timeline is faster
Waiting for both parallel callbacks
A concurrency primitive for cutting timelines
Using Cut() in our code
Uncertain ordering analysis
Parallel execution analysis
Multiple-click analysis
A primitive to call something just once
Implicit versus explicit model of time
Summary: Manipulating timelines
Conclusion
Summary
Up next . . .
Reactive and onion architectures
Two separate architectural patterns
Coupling of causes and effects of changes
What is reactive architecture?
Tradeoffs of the reactive architecture
Cells are first-class state
We can make ValueCells reactive
We can update shipping icons when the cell changes
FormulaCells calculate derived values
Mutable state in functional programming
How reactive architecture reconfigures systems
Decouples effects from their causes
Decoupling manages a center of cause and effect
Treat series of steps as pipelines
Flexibility in your timeline
Two separate architectural patterns
What is the onion architecture?
Review: Actions, calculations, and data
Review: Stratified design
Traditional layered architecture
A functional architecture
Facilitating change and reuse
Examine the terms used to place the rule in a layer
Analyze readability and awkwardness
Conclusion
Summary
Up next . . .
The functional journey ahead
A plan for the chapter
We have learned the skills of professionals
Big takeaways
The ups and downs of skill acquisition
Parallel tracks to mastery
Sandbox: Start a side project
Sandbox: Practice exercises
Production: Eliminate a bug today
Production: Incrementally improve the design
Popular functional languages
Functional languages with the most jobs
Functional languages by platform
Functional languages by learning opportunity
Get mathy
Further reading
Conclusion
Summary
Up next . . .
index