book

Grokking Functional Programming

Name: Grokking Functional Programming
Author: Michal Plachta
ISBN: 9781617291838

by Michal Plachta

January 2023

Beginner to intermediate

520 pages

16h 22m

English

Manning Publications

Read now

Unlock full access

inside front cover
Grokking Functional Programming
Copyright
Dedication
contents
Front matter
prefaceacknowledgmentsabout this bookabout 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 functionWhen the code lies ...Imperative vs. declarativeCoffee break: Imperative vs. declarativeCoffee break explained: Imperative vs. declarativeHow useful is learning functional programming?Leaping into ScalaPracticing functions in ScalaGetting your tools readyGetting to know the REPLWriting your first functions!How to use this bookSummary
2 Pure functions
Why do we need pure functions?Coding imperativelyBreaking the codePassing copies of the dataBreaking the code . . . againRecalculating instead of storingFocusing on the logic by passing the stateWhere did the state go?The difference between impure and pure functionsCoffee break: Refactoring to a pure functionCoffee break explained: Refactoring to a pure functionIn pure functions we trustPure functions in programming languagesDifficulty of staying pure ...Pure functions and clean codeCoffee break: Pure or impure?Coffee break explained: Pure or impure?Using Scala to write pure functionsPracticing pure functions in ScalaTesting pure functionsCoffee break: Testing pure functionsCoffee break explained: Testing pure functionsSummary
3 Immutable values
The fuel for the engineAnother case for immutabilityCan you trust this function?Mutability is dangerousFunctions that lie ... againFighting mutability by working with copiesCoffee break: Getting burned by mutabilityCoffee break explained: Getting burned by mutabilityIntroducing shared mutable stateState’s impact on programming abilitiesDealing with the moving partsDealing with the moving parts using FPImmutable values in ScalaBuilding our intuition about immutabilityCoffee break: The immutable String APICoffee break explained: The immutable String APIHold on ... Isn’t this bad?Purely functional approach to shared mutable statePracticing immutable slicing and appendingSummary

4 Functions as values
Implementing requirements as functionsImpure functions and mutable values strike backUsing Java Streams to sort the listFunction signatures should tell the whole storyChanging requirementsWe just pass the code around!Using Java’s Function valuesUsing the Function syntax to deal with code duplicationPassing user-defined functions as argumentsCoffee break: Functions as parametersCoffee break explained: Functions as parametersProblems with reading functional JavaPassing functions in ScalaDeep dive into sortBySignatures with function parameters in ScalaPassing functions as arguments in ScalaPracticing function passingEmbracing declarative programmingPassing functions to custom-made functionsSmall functions and their responsibilitiesPassing functions inlineCoffee break: Passing functions in ScalaCoffee break explained: Passing functions in ScalaWhat else can we achieve just by passing functions?Applying a function to each element of a listApplying a function to each element of a list using mapGetting to know mapPracticing mapLearn once, use everywhereReturning parts of the list based on a conditionReturning parts of the list using filterGetting to know filterPracticing filterOur journey so far ...Don’t repeat yourself?Is my API easy to use?Adding a new parameter is not enoughFunctions can return functionsUsing functions that can return functionsFunctions are valuesCoffee break: Returning functionsCoffee break explained: Returning functionsDesigning functional APIsIterative design of functional APIsReturning functions from returned functions *How to return functions from returned functions *Using the flexible API built with returned functionsUsing multiple parameter lists in functionsWe have been currying!Practicing curryingProgramming by passing function valuesReducing many values into a single valueReducing many values into a single one using foldLeftGetting to know foldLeftfoldLeft must-knowsPracticing foldLeftModeling immutable dataUsing product types with higher-order functionsMore concise syntax for inline functionsSummary
Part 2. Functional programs
5 Sequential programs
Writing pipeline-based algorithmsComposing larger programs from smaller piecesThe imperative approachflatten and flatMapPractical use case of using more flatMapsflatMap and changing the size of the listCoffee break: Dealing with lists of listsCoffee break explained: Dealing with lists of listsChained flatMaps and mapsNested flatMapsValues that depend on other valuesPracticing nested flatMapsA better syntax for nested flatMapsFor comprehensions to the rescue!Coffee break: flatMaps vs. for comprehensionsCoffee break explained: flatMaps vs. for comprehensionsGetting to know for comprehensionsIt’s not the for you are looking for!Inside a for comprehensionMore sophisticated for comprehensionsChecking all combinations using a for comprehensionFiltering techniquesCoffee break: Filtering techniquesCoffee break explained: Filtering techniquesLooking for a greater abstractionComparing map, foldLeft, and flatMapUsing for comprehensions with SetsUsing for comprehensions with many typesPracticing for comprehensionsDefining for comprehensions ... againUsing for comprehensions with noncollection typesAvoiding nulls: Option typeParsing as a pipelineCoffee break: Parsing with OptionCoffee break explained: Parsing with OptionSummary
6 Error handling
Handling lots of different errors, gracefullyIs it even possible to handle them all?Sort the list of TV shows by their running timeImplementing the sorting requirementDealing with data coming from the outside worldFunctional design: Building from small blocksParsing Strings into immutable objectsParsing a List is just parsing one elementParsing a String into a TvShowWhat about potential errors?Is returning null a good idea?How do we handle potential errors more gracefully?Implementing a function that returns an OptionOption forces us to handle possible errorsBuilding from small blocksFunctional design is building from small blocksWriting a small, safe function that returns an OptionFunctions, values, and expressionsPracticing safe functions that return OptionsHow do errors propagate?Values represent errorsOption, for comprehensions, and checked exceptions ...What about checked exceptions?Conditional recoveryConditional recovery using the imperative styleConditional recovery using the functional styleChecked exceptions don’t compose—Options do!How does orElse work?Practicing functional error handlingFunctions compose, even in the presence of errorsCompiler reminds us that errors need to be coveredCompilation errors are good for us!Transforming a List of Options into a flat ListLet the compiler be our guide ...... but let’s not trust the compiler too much!Coffee break: Error-handling strategiesCoffee break explained: Error-handling strategiesTwo different error-handling strategiesAll-or-nothing error-handling strategyFolding a List of Options into an Option of a ListWe now know how to handle multiple possible errors!How to know what failedWe need to convey error details in the return valueConveying error details using EitherRefactoring to EitherReturning an Either instead of an OptionPracticing safe functions that return EitherWhat we learned about Option works with EitherCoffee break: Error handling using EitherCoffee break explained: Error handling using EitherWorking with Option/EitherSummary
7 Requirements as types
Modeling data to minimize programmers’ mistakesWell-modeled data can’t lieDesigning using what we know so far (which is primitive types)Using data modeled as primitive typesCoffee break: The pain of primitive typesCoffee break explained: The pain of primitive typesProblems with the primitive type approach to modelingUsing primitive types makes our jobs harder!Newtypes protect against misplaced parametersUsing newtypes in data modelsPracticing newtypesMaking sure only valid data combinations are possibleModeling possibility of absence in your dataChanges in the model force changes in the logicUsing data modeled as Options in your logicHigher-order functions for the win!There is probably a higher-order function for that!Coffee break: forall/exists/containsCoffee break explained: forall/exists/containsCoupling a concept inside a single product typeModeling finite possibilitiesUsing sum typesEven better modeling with sum typesUsing the sum type + product type comboProduct types + sum types = algebraic data types (ADTs)Using ADT-based models in behaviors (functions)Destructuring ADTs using pattern matchingDuplication and DRYPracticing pattern matchingNewtypes, ADTs, and pattern matching in the wildWhat about inheritance?Coffee break: Functional data designCoffee break explained: Functional data designModeling behaviorsModeling behaviors as dataImplementing functions with ADT-based parametersCoffee break: Design and maintainabilityCoffee break explained: Design and maintainabilitySummary
8 IO as values
Talking to the outside worldIntegrating with an external APIProperties of a side-effectful IO actionImperative solution to side-effecting IO codeProblems with the imperative approach to IOCan we really do better using FP?Doing IO vs. using IO’s resultHandling IO imperativelyComputations as IO valuesIO valuesIO values in the wildPushing the impurity outUsing values fetched from two IO actionsCombining two IO values into a single IO valuePracticing creating and combining IO valuesDisentangling concerns by working with values onlyThe IO type is viralCoffee break: Working with valuesCoffee break explained: Working with valuesToward functional IOWhat about IO failures?Running a program described by IO may fail!Remember orElse?Lazy and eager evaluationImplementing recovery strategies using IO.orElseImplementing fallbacks using orElse and purePracticing failure recovery in IO valuesWhere should we handle potential failures?Toward functional IO with failure handlingPure functions don’t lie, even in the unsafe world!Functional architectureUsing IO to store dataCoffee break: Using IO to store dataCoffee break explained: Using IO to store dataTreating everything as valuesTreating retries as valuesTreating an unknown number of API calls as valuesPracticing functional signature intuitionsSummary
9 Streams as values
To infinity and beyondDealing with an unknown number of valuesDealing with external impure API calls (again)The functional approach to the designImmutable mapsPracticing immutable mapsHow many IO calls should we make?The bottom-up designAdvanced list operationsIntroducing tuplesZipping and droppingPattern matching on tuplesCoffee break: Working with maps and tuplesCoffee break explained: Working with maps and tuplesFunctional jigsaw puzzleFollowing types in a bottom-up designPrototyping and dead endsRecursive functionsInfinity and lazinessRecursive function structureDealing with an absence in the future (using recursion)Usefulness of infinite recursive callsCoffee break: Recursion and infinityCoffee break explained: Recursion and infinityCreating different IO programs using recursionUsing recursion to make an arbitrary number of callsProblems with the recursive versionIntroducing data streamsStreams in imperative languagesValues on demandStream processing, producers, and consumersStreams and IOThe functional StreamStreams in FP are valuesStreams are recursive valuesPrimitive operations and combinatorsStreams of IO-based valuesInfinite streams of IO-based valuesExecuting for side effectsPracticing stream operationsUsing streams to our advantageInfinite stream of API callsHandling IO failures in streamsSeparated concernsSliding windowsWaiting between IO callsZipping streamsBenefits of using the stream-based approachSummary
10 Concurrent programs
Threads, threads everywhereDeclarative concurrencySequential vs. concurrentCoffee break: Sequential thinkingCoffee break explained: Sequential thinkingThe need for batchingBatching implementationThe concurrent worldThe concurrent stateImperative concurrencyAtomic referencesIntroducing RefUpdating Ref valuesUsing Ref valuesMaking it all concurrentparSequence in actionPracticing concurrent IOsModeling concurrencyCoding using Refs and fibersIOs that run infinitelyCoffee break: Concurrent thinkingCoffee break explained: Concurrent thinkingThe need for asynchronicityPreparing for asynchronous accessDesigning functional asynchronous programsManaging fibers manuallyCoding functional asynchronous programsSummary
Part 3. Applied functional programming
11 Designing functional programs
Make it work, make it right, make it fastModeling using immutable valuesBusiness domain modeling and FPData access modelingA bag of functionsBusiness logic as a pure functionSeparating the real data access concernIntegrating with APIs using imperative libraries and IOFollowing the designImplementing input actions as IO valuesSeparating the library IO from other concernsCurrying and inversion of controlFunctions as valuesConnecting the dotsWe made it workMaking it rightResource leaksHandling resourcesUsing a Resource valueWe made it rightCoffee break: Make it fastCoffee break explained: Make it fastSummary
12 Testing functional programs
Do you have tests for that?Tests are just functionsChoosing functions to testTesting by providing examplesPracticing testing by exampleGenerating good examplesGenerating propertiesProperty-based testingTesting by providing propertiesDelegating the work by passing functionsUnderstanding failures of property-based testsWrong test or a bug?Custom generatorsUsing custom generatorsTesting more complicated scenarios in a readable wayFinding and fixing bugs in the implementationCoffee break: Property-based testsCoffee break explained: Property-based testsProperties and examplesRequirements coverageTesting side-effectful requirementsIdentifying the right test for the jobData usage testsPracticing stubbing external services using IOTesting and designService integration testsLocal servers as Resources in integration testsWriting isolated integration testsIntegration with a service is a single responsibilityCoffee break: Writing integration testsCoffee break explained: Writing integration testsIntegration tests take more timeProperty-based integration testsChoosing the right testing approachTest-driven developmentWriting a test for a feature that doesn’t existRed-green-refactorMaking tests greenAdding more red testsThe last TDD iterationSummaryThe last dance
Appendix A. Scala cheat sheet
Appendix B. Functional gems
index
inside back cover

Content preview from Grokking Functional Programming

2 Pure functions

In this chapter you will learn

why we need pure functions
how to pass copies of the data
how to recalculate instead of storing
how to pass the state
how to test pure functions

“Sometimes, the elegant implementation is just a function. Not a method. Not a class. Not a framework. Just a function.”

—John Carmack

Why do we need pure functions?

In the last chapter we learned about functions that don’t lie. Their signatures tell the whole story about their body. We concluded that these are the functions we can trust: the fewer surprises there are when we code, the fewer bugs there will be in the applications we create. In this chapter we will learn about the most trustworthy of all the functions that don’t lie: a pure function.

Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.

Read now

Unlock full access

More than 5,000 organizations count on O’Reilly

O’Reilly covers everything we've got, with content to help us build a world-class technology community, upgrade the capabilities and competencies of our teams, and improve overall team performance as well as their engagement.

Julian F.

Head of Cybersecurity

I wanted to learn C and C++, but it didn't click for me until I picked up an O'Reilly book. When I went on the O’Reilly platform, I was astonished to find all the books there, plus live events and sandboxes so you could play around with the technology.

Addison B.

Field Engineer

I’ve been on the O’Reilly platform for more than eight years. I use a couple of learning platforms, but I'm on O'Reilly more than anybody else. When you're there, you start learning. I'm never disappointed.

Amir M.

Data Platform Tech Lead

I'm always learning. So when I got on to O'Reilly, I was like a kid in a candy store. There are playlists. There are answers. There's on-demand training. It's worth its weight in gold, in terms of what it allows me to do.

Mark W.

Embedded Software Engineer

Functional Programming in Scala, Second Edition

Publisher Resources

ISBN: 9781617291838Publisher Support Publisher Website Errata Page

Cloud Computing

Data Engineering

Data Science

AI & ML

Programming Languages

Software Architecture

IT/Ops

Security

Design

Business

Soft Skills

Grokking Functional Programming

by Michal Plachta

2 Pure functions

Why do we need pure functions?

Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.