Grokking Functional Programming
There's no need to fear going functional! This friendly, lively, and engaging guide is perfect for any perplexed programmer. It lays out the principles of functional programming in a simple and concise way that will help you grok what FP is really all about. In Grokking Functional Programming y...
| Autor principal: | |
|---|---|
| Formato: | Libro electrónico |
| Idioma: | Inglés |
| Publicado: |
New York :
Manning Publications Co. LLC
2022.
|
| Materias: | |
| Ver en Biblioteca Universitat Ramon Llull: | https://discovery.url.edu/permalink/34CSUC_URL/1im36ta/alma991009714836506719 |
Tabla de Contenidos:
- Intro
- inside front cover
- Grokking Functional Programming
- Copyright
- Dedication
- contents
- Front matter
- preface
- acknowledgments
- about this book
- about the author
- Part 1. The functional toolkit
- 1 Learning functional programming
- Perhaps you picked up this book because ...
- What do you need to know before we start?
- What do functions look like?
- Meet the function
- When the code lies ...
- Imperative vs. declarative
- Coffee break: Imperative vs. declarative
- Coffee break explained: Imperative vs. declarative
- How useful is learning functional programming?
- Leaping into Scala
- Practicing functions in Scala
- Getting your tools ready
- Getting to know the REPL
- Writing your first functions!
- How to use this book
- Summary
- 2 Pure functions
- Why do we need pure functions?
- Coding imperatively
- Breaking the code
- Passing copies of the data
- Breaking the code . . . again
- Recalculating instead of storing
- Focusing on the logic by passing the state
- Where did the state go?
- The difference between impure and pure functions
- Coffee break: Refactoring to a pure function
- Coffee break explained: Refactoring to a pure function
- In pure functions we trust
- Pure functions in programming languages
- Difficulty of staying pure ...
- Pure functions and clean code
- Coffee break: Pure or impure?
- Coffee break explained: Pure or impure?
- Using Scala to write pure functions
- Practicing pure functions in Scala
- Testing pure functions
- Coffee break: Testing pure functions
- Coffee break explained: Testing pure functions
- Summary
- 3 Immutable values
- The fuel for the engine
- Another case for immutability
- Can you trust this function?
- Mutability is dangerous
- Functions that lie ... again
- Fighting mutability by working with copies.
- Coffee break: Getting burned by mutability
- Coffee break explained: Getting burned by mutability
- Introducing shared mutable state
- State's impact on programming abilities
- Dealing with the moving parts
- Dealing with the moving parts using FP
- Immutable values in Scala
- Building our intuition about immutability
- Coffee break: The immutable String API
- Coffee break explained: The immutable String API
- Hold on ... Isn't this bad?
- Purely functional approach to shared mutable state
- Practicing immutable slicing and appending
- Summary
- 4 Functions as values
- Implementing requirements as functions
- Impure functions and mutable values strike back
- Using Java Streams to sort the list
- Function signatures should tell the whole story
- Changing requirements
- We just pass the code around!
- Using Java's Function values
- Using the Function syntax to deal with code duplication
- Passing user-defined functions as arguments
- Coffee break: Functions as parameters
- Coffee break explained: Functions as parameters
- Problems with reading functional Java
- Passing functions in Scala
- Deep dive into sortBy
- Signatures with function parameters in Scala
- Passing functions as arguments in Scala
- Practicing function passing
- Embracing declarative programming
- Passing functions to custom-made functions
- Small functions and their responsibilities
- Passing functions inline
- Coffee break: Passing functions in Scala
- Coffee break explained: Passing functions in Scala
- What else can we achieve just by passing functions?
- Applying a function to each element of a list
- Applying a function to each element of a list using map
- Getting to know map
- Practicing map
- Learn once, use everywhere
- Returning parts of the list based on a condition
- Returning parts of the list using filter.
- Getting to know filter
- Practicing filter
- Our journey so far ...
- Don't repeat yourself?
- Is my API easy to use?
- Adding a new parameter is not enough
- Functions can return functions
- Using functions that can return functions
- Functions are values
- Coffee break: Returning functions
- Coffee break explained: Returning functions
- Designing functional APIs
- Iterative design of functional APIs
- Returning functions from returned functions *
- How to return functions from returned functions *
- Using the flexible API built with returned functions
- Using multiple parameter lists in functions
- We have been currying!
- Practicing currying
- Programming by passing function values
- Reducing many values into a single value
- Reducing many values into a single one using foldLeft
- Getting to know foldLeft
- foldLeft must-knows
- Practicing foldLeft
- Modeling immutable data
- Using product types with higher-order functions
- More concise syntax for inline functions
- Summary
- Part 2. Functional programs
- 5 Sequential programs
- Writing pipeline-based algorithms
- Composing larger programs from smaller pieces
- The imperative approach
- flatten and flatMap
- Practical use case of using more flatMaps
- flatMap and changing the size of the list
- Coffee break: Dealing with lists of lists
- Coffee break explained: Dealing with lists of lists
- Chained flatMaps and maps
- Nested flatMaps
- Values that depend on other values
- Practicing nested flatMaps
- A better syntax for nested flatMaps
- For comprehensions to the rescue!
- Coffee break: flatMaps vs. for comprehensions
- Coffee break explained: flatMaps vs. for comprehensions
- Getting to know for comprehensions
- It's not the for you are looking for!
- Inside a for comprehension
- More sophisticated for comprehensions.
- Checking all combinations using a for comprehension
- Filtering techniques
- Coffee break: Filtering techniques
- Coffee break explained: Filtering techniques
- Looking for a greater abstraction
- Comparing map, foldLeft, and flatMap
- Using for comprehensions with Sets
- Using for comprehensions with many types
- Practicing for comprehensions
- Defining for comprehensions ... again
- Using for comprehensions with noncollection types
- Avoiding nulls: Option type
- Parsing as a pipeline
- Coffee break: Parsing with Option
- Coffee break explained: Parsing with Option
- Summary
- 6 Error handling
- Handling lots of different errors, gracefully
- Is it even possible to handle them all?
- Sort the list of TV shows by their running time
- Implementing the sorting requirement
- Dealing with data coming from the outside world
- Functional design: Building from small blocks
- Parsing Strings into immutable objects
- Parsing a List is just parsing one element
- Parsing a String into a TvShow
- What about potential errors?
- Is returning null a good idea?
- How do we handle potential errors more gracefully?
- Implementing a function that returns an Option
- Option forces us to handle possible errors
- Building from small blocks
- Functional design is building from small blocks
- Writing a small, safe function that returns an Option
- Functions, values, and expressions
- Practicing safe functions that return Options
- How do errors propagate?
- Values represent errors
- Option, for comprehensions, and checked exceptions ...
- What about checked exceptions?
- Conditional recovery
- Conditional recovery using the imperative style
- Conditional recovery using the functional style
- Checked exceptions don't compose-Options do!
- How does orElse work?
- Practicing functional error handling.
- Functions compose, even in the presence of errors
- Compiler reminds us that errors need to be covered
- Compilation errors are good for us!
- Transforming a List of Options into a flat List
- Let the compiler be our guide ...
- ... but let's not trust the compiler too much!
- Coffee break: Error-handling strategies
- Coffee break explained: Error-handling strategies
- Two different error-handling strategies
- All-or-nothing error-handling strategy
- Folding a List of Options into an Option of a List
- We now know how to handle multiple possible errors!
- How to know what failed
- We need to convey error details in the return value
- Conveying error details using Either
- Refactoring to Either
- Returning an Either instead of an Option
- Practicing safe functions that return Either
- What we learned about Option works with Either
- Coffee break: Error handling using Either
- Coffee break explained: Error handling using Either
- Working with Option/Either
- Summary
- 7 Requirements as types
- Modeling data to minimize programmers' mistakes
- Well-modeled data can't lie
- Designing using what we know so far (which is primitive types)
- Using data modeled as primitive types
- Coffee break: The pain of primitive types
- Coffee break explained: The pain of primitive types
- Problems with the primitive type approach to modeling
- Using primitive types makes our jobs harder!
- Newtypes protect against misplaced parameters
- Using newtypes in data models
- Practicing newtypes
- Making sure only valid data combinations are possible
- Modeling possibility of absence in your data
- Changes in the model force changes in the logic
- Using data modeled as Options in your logic
- Higher-order functions for the win!
- There is probably a higher-order function for that!
- Coffee break: forall/exists/contains.
- Coffee break explained: forall/exists/contains.
