This is the summarization of reading a grokking functional programming book.
Functional Programming Effects (Translator's Preface)
- Using immutable data structures prevented bugs due to mutable state.
- Separating functions with side effects made the code more testable.
Thoughts on Side Effects (Translator's Preface)
- Managing side effects means eliminating unnecessary ones and properly maintaining necessary ones.
Immutable data structures avoid side effects like reading and writing global variables. However, side effects like I/O still remain. Non-Haskell developers often misunderstand that pure functional languages like Haskell have no side effects, as they represent them through pure functions. But this is just a delay of side effects, which inevitably occur. Software without side effects is meaningless.
Programming Style Evolution (Foreword)
- Structural Programming Flow Control StructuresSimplifies flow control into patterns. Divides sequentially executed statements into nestable blocks.
- Object-Oriented Programming Data Access StructuresAll variables are encapsulated or contained within some structure. Limited access to variables in certain parts of the code makes it manageable and readable. Ensures a consistent set of properties for groups of variables. Inheritance is possible due to encapsulation.
- Functional Programming Side Effect ManagementManages side effects to ensure they are not scattered everywhere.Distinguishes between computations and actions.Processes collections like arrays, lists, and databases at once rather than item by item. For 'at once' processing, collections must not have side effects influencing the outside. Most effective when items are independent, relying on the distinction between computation and action.
Side Effects (p.2)
- Anything a function does besides returning a value.(Ex. Sending an email, modifying global state)
Pure Functions (p.2)
- Functions that depend only on their arguments and have no side effects.Depend only on arguments: Always return the same result for the same arguments.
Actions, Computations, and Data (p.10)
Functional programmers prefer computations over actions and data over computations.
- Actions (Side Effects)Depend on the timing or frequency of calls, or both. Safely changing state over time. Ensuring order. Guaranteeing actions are performed exactly once.
- Computations (Pure Functions)Creating output from input. Making decisions or plans. Same input → Computation → Same output. Do not affect the outside world. Replaceable with computation results in code, hence referentially transparent. Consistent results allow multiple safe calls. Easy to test and safe to call any number of times.Accuracy through static analysis. Mathematical knowledge is applicable in software. Testing strategies.
- DataRecorded facts about events. Less complex than executable code, hence distinguishable.Efficient access methods.Storage technologies.Principles for discovering significant insights from data.
Why Computations are Preferred Over Actions (p.53)
- Easier to test.
- Simpler for mechanical analysis.
- Better for combination.
Functional Thinking (p.13)
- Techniques and thoughts used by functional programmers to solve software problems.Distinguishing between actions, computations, and data.First-class abstractions.
Layered Design (p.20)
Frequently ChangingBusiness RulesWhat Needs to Be Done↕️Domain RulesData ListsInfrequently ChangingTechnology StackJavaScript Objects, Numbers
- Each layer is built upon a more stable layer beneath. The code in each layer can be written on a more stable foundation. ⇒ This structure allows easy software modification. Top-layer code changes easily due to minimal dependencies. Lower-layer code is harder to change but changes less frequently.
- Layered design typically involves business rules, domain rules, and technology stack layers. Code made with layered design is easy to test, reuse, and maintain.
Considerations When Applying Functional Thinking (p.32)
- When thinking about the problem: Parts needing special attention (actions).Parts that should be handled as data.Parts requiring decision-making (computations).
- When coding: Try to extract computations from actions. Consider separating data from computations. Explore if actions can become computations and if computations can become data.
Actions Spread Throughout the Code (p.55)
Once actions are used, they tend to spread throughout the code, so they must be used cautiously.
- Extract actions.
- If a function calls an action, the entire function becomes an action. ⇒ A small piece of code can turn the whole program into an action.
Functions Have Inputs and Outputs (p.68)
- InputExternal information needed for the function to compute. Information enters the function through inputs.
- OutputInformation or actions leaving the function. Information or effects exit the function as outputs.
- Reason for Calling a function to obtain a result. Inputs are necessary to get a result.
Inputs and Outputs Can Be Explicit or Implicit (p.68)
- Explicit Input: Arguments.
- Explicit Output: Return value.
- Implicit Input (Side Effect): Anything influencing the result during the function call - Inputs other than arguments.Reading a global variable.Reading a DOM element.
- Implicit Output (Side Effect): Anything affected as a result of the function call - Outputs other than the return value.Changing a DOM element.Modifying a global variable.
A Function with Implicit Inputs and Outputs Becomes an Action (p.68)
- Removing implicit inputs and outputs from a function turns it into a computation. Implicit inputs → Function arguments.Implicit outputs → Return values.
Steps to Extract Computation (p.78)
- Find and Extract Computation Code (Subroutine Extraction)Extract code to create a new function and refactor. Add necessary arguments to the
