book

Grokking Functional Programming

by Michal Plachta

January 2023

Beginner to intermediate

520 pages

16h 22m

English

Manning Publications

Read now

Unlock full access

prefaceacknowledgmentsabout this bookabout the author
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
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
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

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
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
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
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
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
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
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
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
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

Overview

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 you will learn:

Designing with functions and types instead of objects
Programming with pure functions and immutable values
Writing concurrent programs using the functional style
Testing functional programs
Multiple learning approaches to help you grok each new concept

If you’ve ever found yourself rolling your eyes at functional programming, this is the book for you. Open up Grokking Functional Programming and you’ll find functional ideas mapped onto what you already know as an object-oriented programmer. The book focuses on practical aspects from page one. Hands-on examples apply functional principles to everyday programming tasks like concurrency, error handling, and improving readability. Plus, puzzles and exercises let you think and practice what you're learning. You’ll soon reach an amazing “aha” moment and start seeing code in a completely new way.

About the Technology
Finally, there’s an easy way to learn functional programming! This unique book starts with the familiar ideas of OOP and introduces FP step-by-step using relevant examples, engaging exercises, and lots of illustrations. You’ll be amazed at how quickly you’ll start seeing software tasks from this valuable new perspective.

About the Book
Grokking Functional Programming introduces functional programming to imperative developers. You’ll start with small, comfortable coding tasks that expose basic concepts like writing pure functions and working with immutable data. Along the way, you’ll learn how to write code that eliminates common bugs caused by complex distributed state. You’ll also explore the FP approach to IO, concurrency, and data streaming. By the time you finish, you’ll be writing clean functional code that’s easy to understand, test, and maintain.

What's Inside

Designing with functions and types instead of objects
Programming with pure functions and immutable values
Writing concurrent programs using the functional style
Testing functional programs

About the Reader
For developers who know an object-oriented language. Examples in Java and Scala.

About the Author
Michał Płachta is an experienced software developer who regularly speaks and writes about creating maintainable applications. He blogs at michalplachta.com.

Quotes
The go-to book for functional programming!
- Srihari Sridharan, Thoughtworks

The writing is imaginative and creative, so it’s a fun reading experience.
- Gianluigi Spagnuolo, Exein

Perfect! A new way of thinking about how we code.
- Gustavo Gomes, Troido

A fresh way to grasp the core of functional programming! Practical and totally focused.
- Ubaldo Pescatore, PagoPA

I finally understand why functional programming matters and how I can adopt it in my daily practices.
- Sander Rosel, JUUN Software