Tweet
Tweet

Slide 1

Slide 1 text

FUNCTIONAL PROGRAMMING INCEPTION Alexandru Nedelcu Software Developer @ eloquentix.com
 @alexelcu / alexn.org

Slide 2

Slide 2 text

FUNCTIONAL PROGRAMMING INCEPTION WHAT IS FUNCTIONAL PROGRAMMING?

Slide 3

Slide 3 text

FUNCTIONAL PROGRAMMING INCEPTION WHAT IS FUNCTIONAL PROGRAMMING? A: Programming with Mathematical Functions

Slide 4

Slide 4 text

FUNCTIONAL PROGRAMMING INCEPTION PROPERTIES OF FP ▸FP <=> Programming with Values ▸Referential Transparency ▸Composability, Reason

Slide 5

Slide 5 text

ITERATOR CASE STUDY ON THE WORLD MOST FAMOUS OOP ABSTRACTION

Slide 6

Slide 6 text

ITERATOR HOW DID ITERATOR HAPPEN?

Slide 7

Slide 7 text

ITERATOR HOW DID ITERATOR HAPPEN?

Slide 8

Slide 8 text

ITERATOR HOW DID ITERATOR HAPPEN?

Slide 9

Slide 9 text

ITERATOR HOW DID ITERATOR HAPPEN?

Slide 10

Slide 10 text

ITERATOR HOW DID ITERATOR HAPPEN?

Slide 11

Slide 11 text

ITERATOR PROBLEMS ?

Slide 12

Slide 12 text

ITERATOR PROBLEMS ? ▸Synchronous Only ▸blocks threads for async stuff ▸no way around it, it’s in the signature

Slide 13

Slide 13 text

ITERATOR PROBLEMS ? ▸ Synchronous Only ▸No Backed-in Resource Managed

Slide 14

Slide 14 text

ITERATOR PROBLEMS ? ▸ Synchronous Only ▸ No Backed-in Resource Managed ▸Minefield for Stack Overflows

Slide 15

Slide 15 text

FP DESIGN HOW TO

Slide 16

Slide 16 text

ARCHITECTURE IS FROZEN MUSIC Johann Wolfgang Von Goethe FP DESIGN

Slide 17

Slide 17 text

DATA STRUCTURES ARE FROZEN ALGORITHMS Jon Bentley FP DESIGN

Slide 18

Slide 18 text

FP DESIGN KEY INSIGHTS 1. Freeze Algorithms into Data-Structures
 (Immutable)

Slide 19

Slide 19 text

FP DESIGN KEY INSIGHTS 1. Freeze Algorithms into Data-Structures 2. Think State Machines
 (most of the time)

Slide 20

Slide 20 text

FP DESIGN KEY INSIGHTS 1. Freeze Algorithms into Data-Structures 2. Think State Machines 3. Be Lazy 
 (Strict Values => Functions ;-))

Slide 21

Slide 21 text

FP DESIGN KEY INSIGHTS 1. Freeze Algorithms into Data-Structures 2. Think State Machines 3. Be Lazy 4. Evaluate Effects w/ Stack-safe Monads 
 (e.g. IO, Task, Free)

Slide 22

Slide 22 text

Finite State Machine Cat

Slide 23

Slide 23 text

FP DESIGN EXAMPLE: LINKED LISTS

Slide 24

Slide 24 text

FP DESIGN EXAMPLE: LINKED LISTS

Slide 25

Slide 25 text

FP DESIGN EXAMPLE: LINKED LISTS

Slide 26

Slide 26 text

ITERANT A PURELY FUNCTIONAL ITERATOR

Slide 27

Slide 27 text

ITERANT LAZY EVALUATION λ-calculus: using anonymous functions because of privacy concerns

Slide 28

Slide 28 text

ITERANT LAZY EVALUATION λ-calculus: using anonymous functions because of privacy concerns

Slide 29

Slide 29 text

ITERANT USAGE

Slide 30

Slide 30 text

ITERANT RESOURCE MANAGEMENT

Slide 31

Slide 31 text

ITERANT USAGE Not pure yet, not referentially transparent

Slide 32

Slide 32 text

ITERANT DEFERRING

Slide 33

Slide 33 text

ITERANT USAGE

Slide 34

Slide 34 text

ITERANT USAGE

Slide 35

Slide 35 text

ITERANT USAGE

Slide 36

Slide 36 text

No content

Slide 37

Slide 37 text

ASYNCHRONY CONCURRENCY, NON-DETERMINISM

Slide 38

Slide 38 text

ASYNCHRONY QUICK INTRO

Slide 39

Slide 39 text

ASYNCHRONY QUICK INTRO

Slide 40

Slide 40 text

ASYNCHRONY QUICK INTRO

Slide 41

Slide 41 text

ASYNCHRONY CAN WE DO THIS ?

Slide 42

Slide 42 text

ASYNCHRONY EVALUATION IN SCALA Eager Lazy A () => A

Slide 43

Slide 43 text

ASYNCHRONY EVALUATION IN SCALA Eager Lazy Synchronous A () => A Asynchronous (A => Unit) => Unit () => (A => Unit) => Unit

Slide 44

Slide 44 text

ASYNCHRONY EVALUATION IN SCALA Eager Lazy Synchronous A () => A Function0[A] Asynchronous (A => Unit) => Unit () => (A => Unit) => Unit Future[A] Task[A]

Slide 45

Slide 45 text

“A FUTURE REPRESENTS A VALUE, DETACHED FROM TIME” Viktor Klang MONIX TASK

Slide 46

Slide 46 text

ASYNCHRONY GOING LAZY (AGAIN)

Slide 47

Slide 47 text

ASYNCHRONY

Slide 48

Slide 48 text

ASYNCHRONY MONIX TASK ▸ High-performance ▸ Lazy, possibly asynchronous behaviour ▸ Allows for cancelling of a running computation ▸ https://monix.io/docs/2x/eval/task.html

Slide 49

Slide 49 text

ASYNCHRONY GOING LAZY (AGAIN)

Slide 50

Slide 50 text

HIGHER-KINDED
 POLYMORPHISM Bring Your Own Booze

Slide 51

Slide 51 text

HIGHER-KINDED POLYMORPHISM CAN WE DO THIS ?

Slide 52

Slide 52 text

HIGHER-KINDED POLYMORPHISM CAN WE DO THIS ?

Slide 53

Slide 53 text

HIGHER-KINDED POLYMORPHISM GENERICS OF A HIGHER KIND

Slide 54

Slide 54 text

HIGHER-KINDED POLYMORPHISM GENERICS OF A HIGHER KIND

Slide 55

Slide 55 text

HIGHER-KINDED POLYMORPHISM GENERICS OF A HIGHER KIND

Slide 56

Slide 56 text

No content

Slide 57

Slide 57 text

HIGHER-KINDED POLYMORPHISM OOP VS PARAMETRIC POLYMORPHISM ▸…

Slide 58

Slide 58 text

HIGHER-KINDED POLYMORPHISM OOP VS PARAMETRIC POLYMORPHISM ▸OOP is about Information Hiding
 (in types too) ▸OOP handles Heterogeneity

Slide 59

Slide 59 text

HIGHER-KINDED POLYMORPHISM OOP VS PARAMETRIC POLYMORPHISM ▸ OOP is about Information Hiding
 (in types too) ▸ OOP handles Heterogeneity ▸Parametric Polymorphism is compile-time ▸Fundamentally changes behaviour based on plugged-in types

Slide 60

Slide 60 text

HIGHER-KINDED POLYMORPHISM OOP VS PARAMETRIC POLYMORPHISM ▸ArrayIterator vs ListIterator ▸Iterant[Task] vs Iterant[Eval]

Slide 61

Slide 61 text

HIGHER-KINDED POLYMORPHISM OOP VS PARAMETRIC POLYMORPHISM ▸ ArrayIterator vs ListIterator ▸ Iterant[Task, _] vs Iterant[Eval, _] ▸One is hiding implementation details ▸The other is about composition

Slide 62

Slide 62 text

HIGHER-KINDED POLYMORPHISM PROBLEMS ▸Pushes compiler to its limits

Slide 63

Slide 63 text

HIGHER-KINDED POLYMORPHISM PROBLEMS ▸ Pushes compiler to its limits ▸Unfamiliarity for users

Slide 64

Slide 64 text

HIGHER-KINDED POLYMORPHISM PROBLEMS ▸ Pushes compiler to its limits ▸ Unfamiliarity for users ▸Not all needed type-classes are available, design can be frustrating
 https://github.com/typelevel/cats/pull/1552
 (39 comments and counting)


Slide 65

Slide 65 text

HIGHER-KINDED POLYMORPHISM UPSIDE

Slide 66

Slide 66 text

HIGHER-KINDED POLYMORPHISM LAWS

Slide 67

Slide 67 text

HIGHER-KINDED POLYMORPHISM LAWS ▸ Typelevel Cats ▸ Typelevel Discipline ▸ ScalaCheck

Slide 68

Slide 68 text

FUNCTIONAL PROGRAMMING PERFORMANCE PROBLEMS ▸Linked Lists are everywhere in FP ▸Linked Lists are terrible ▸Async or Lazy Boundaries are terrible

Slide 69

Slide 69 text

FUNCTIONAL PROGRAMMING PERFORMANCE SOLUTIONS ▸Linked Lists are everywhere in FP ▸Linked Lists are terrible ▸Async or Lazy Boundaries are terrible ▸Find Ways to work with Arrays and ▸… to avoid lazy/async boundaries

Slide 70

Slide 70 text

FUNCTIONAL PROGRAMMING PERFORMANCE SOLUTIONS Efficient 
 head/tail 
 decomposition 
 needed ;-)

Slide 71

Slide 71 text

FUNCTIONAL PROGRAMMING OTHER PROBLEMS ▸Recursion is terrible ▸Space leaks are hard to fix

Slide 72

Slide 72 text

FUNCTIONAL PROGRAMMING OTHER PROBLEMS ▸Recursion is terrible ▸Space leaks are hard to fix ▸Solvable with pain and YourKit

Slide 73

Slide 73 text

TAKEAWAYS

Slide 74

Slide 74 text

FUNCTIONAL PROGRAMMING INCEPTION TAKEAWAYS ▸ Freeze Algorithms into Immutable Data-Structures ▸ Describe State Machines ▸ Be lazy, suspend side-effects with Task/Free/IO ▸ Be lawful, use ScalaCheck/QuickCheck ▸ Performance matters (for libraries)

Slide 75

Slide 75 text

FUNCTIONAL PROGRAMMING INCEPTION TAKEAWAYS ▸ Libraries: 
 Monix, Cats, ScalaCheck ▸ Generic Iterant implementation:
 https://github.com/monix/monix/pull/280 ▸ Simplified Task-based implementation:
 https://github.com/monix/monix/pull/331

Slide 76

Slide 76 text

QUESTIONS?