Functional Programming Inception

Designing functionality that exhibits the properties of functional programming is hard because it requires a mentality change, coping with immutability and consideration for recursion, performance and polymorphism. This talk is a lesson in FP design that makes use of Scala’s hybrid OOP+FP nature.

We are going to start from Scala’s (and Java’s) ubiquitous Iterator/Iterable types which expose the famous iterator pattern, analyzing its strengths and weaknesses. And then we are going to work our way up to a fully featured FP replacement that has referential transparency and that fixes everything that’s wrong with Iterator, while being more generic.

This lesson in design involves talking about immutability, imperative programming, asynchrony and problems encountered when going FP, like performance considerations, recursion and memory leaks. We are also going to talk about ADTs, higher kinded polymorphism and type-classes versus OOP subtyping. Interestingly the example presented will use both OOP subtyping and type-classes and thus we can make a clear comparison about what to use and when - a problem that the Scala developer has in his daily work.

A working knowledge of the Scala programming language is required. Knowledge about Scala’s Future or the Task data type in Monix or from Scalaz is recommended, but not required.

BIO: Alexandru Nedelcu, @alexandru on GitHub/Gitter and @alexelcu on Twitter, is the lead developer of the Monix library.

Transcript

1. FUNCTIONAL PROGRAMMING INCEPTION Alexandru Nedelcu Software Developer @ eloquentix.com
 @alexelcu / alexn.org
2. FUNCTIONAL PROGRAMMING INCEPTION WHAT IS FUNCTIONAL PROGRAMMING?
3. FUNCTIONAL PROGRAMMING INCEPTION WHAT IS FUNCTIONAL PROGRAMMING? A: Programming with Mathematical Functions
4. FUNCTIONAL PROGRAMMING INCEPTION PROPERTIES OF FP ▸FP <=> Programming with Values ▸Referential Transparency ▸Composability, Reason
5. ITERATOR CASE STUDY ON THE WORLD MOST FAMOUS OOP ABSTRACTION
6. ITERATOR HOW DID ITERATOR HAPPEN?
7. ITERATOR HOW DID ITERATOR HAPPEN?
8. ITERATOR HOW DID ITERATOR HAPPEN?
9. ITERATOR HOW DID ITERATOR HAPPEN?
10. ITERATOR HOW DID ITERATOR HAPPEN?
11. ITERATOR PROBLEMS ?
12. ITERATOR PROBLEMS ? ▸Synchronous Only ▸blocks threads for async stuff ▸no way around it, it’s in the signature
13. ITERATOR PROBLEMS ? ▸ Synchronous Only ▸No Backed-in Resource Managed
14. ITERATOR PROBLEMS ? ▸ Synchronous Only ▸ No Backed-in Resource Managed ▸Minefield for Stack Overflows
15. FP DESIGN HOW TO
16. ARCHITECTURE IS FROZEN MUSIC Johann Wolfgang Von Goethe FP DESIGN
17. DATA STRUCTURES ARE FROZEN ALGORITHMS Jon Bentley FP DESIGN
18. FP DESIGN KEY INSIGHTS 1. Freeze Algorithms into Data-Structures
 (Immutable)
19. FP DESIGN KEY INSIGHTS 1. Freeze Algorithms into Data-Structures 2. Think State Machines
 (most of the time)
20. FP DESIGN KEY INSIGHTS 1. Freeze Algorithms into Data-Structures 2. Think State Machines 3. Be Lazy 
 (Strict Values => Functions ;-))
21. 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)
22. Finite State Machine Cat
23. FP DESIGN EXAMPLE: LINKED LISTS
24. FP DESIGN EXAMPLE: LINKED LISTS
25. FP DESIGN EXAMPLE: LINKED LISTS
26. ITERANT A PURELY FUNCTIONAL ITERATOR
27. ITERANT LAZY EVALUATION λ-calculus: using anonymous functions because of privacy concerns
28. ITERANT LAZY EVALUATION λ-calculus: using anonymous functions because of privacy concerns
29. ITERANT USAGE
30. ITERANT RESOURCE MANAGEMENT
31. ITERANT USAGE Not pure yet, not referentially transparent
32. ITERANT DEFERRING
33. ITERANT USAGE
34. ITERANT USAGE
35. ITERANT USAGE
37. ASYNCHRONY CONCURRENCY, NON-DETERMINISM
38. ASYNCHRONY QUICK INTRO
39. ASYNCHRONY QUICK INTRO
40. ASYNCHRONY QUICK INTRO
41. ASYNCHRONY CAN WE DO THIS ?
42. ASYNCHRONY EVALUATION IN SCALA Eager Lazy A () => A
43. ASYNCHRONY EVALUATION IN SCALA Eager Lazy Synchronous A () => A Asynchronous (A => Unit) => Unit () => (A => Unit) => Unit
44. ASYNCHRONY EVALUATION IN SCALA Eager Lazy Synchronous A () => A Function0[A] Asynchronous (A => Unit) => Unit () => (A => Unit) => Unit Future[A] Task[A]
45. “A FUTURE REPRESENTS A VALUE, DETACHED FROM TIME” Viktor Klang MONIX TASK
46. ASYNCHRONY GOING LAZY (AGAIN)
47. ASYNCHRONY
48. ASYNCHRONY MONIX TASK ▸ High-performance ▸ Lazy, possibly asynchronous behaviour ▸ Allows for cancelling of a running computation ▸ https://monix.io/docs/2x/eval/task.html
49. ASYNCHRONY GOING LAZY (AGAIN)
50. HIGHER-KINDED
 POLYMORPHISM Bring Your Own Booze
51. HIGHER-KINDED POLYMORPHISM CAN WE DO THIS ?
52. HIGHER-KINDED POLYMORPHISM CAN WE DO THIS ?
53. HIGHER-KINDED POLYMORPHISM GENERICS OF A HIGHER KIND
54. HIGHER-KINDED POLYMORPHISM GENERICS OF A HIGHER KIND
55. HIGHER-KINDED POLYMORPHISM GENERICS OF A HIGHER KIND
57. HIGHER-KINDED POLYMORPHISM OOP VS PARAMETRIC POLYMORPHISM ▸…
58. HIGHER-KINDED POLYMORPHISM OOP VS PARAMETRIC POLYMORPHISM ▸OOP is about Information Hiding
 (in types too) ▸OOP handles Heterogeneity
59. 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
60. HIGHER-KINDED POLYMORPHISM OOP VS PARAMETRIC POLYMORPHISM ▸ArrayIterator vs ListIterator ▸Iterant[Task] vs Iterant[Eval]
61. 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
62. HIGHER-KINDED POLYMORPHISM PROBLEMS ▸Pushes compiler to its limits
63. HIGHER-KINDED POLYMORPHISM PROBLEMS ▸ Pushes compiler to its limits ▸Unfamiliarity for users
64. 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)

65. HIGHER-KINDED POLYMORPHISM UPSIDE
66. HIGHER-KINDED POLYMORPHISM LAWS
67. HIGHER-KINDED POLYMORPHISM LAWS ▸ Typelevel Cats ▸ Typelevel Discipline ▸ ScalaCheck
68. FUNCTIONAL PROGRAMMING PERFORMANCE PROBLEMS ▸Linked Lists are everywhere in FP ▸Linked Lists are terrible ▸Async or Lazy Boundaries are terrible
69. 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
70. FUNCTIONAL PROGRAMMING PERFORMANCE SOLUTIONS Efficient 
 head/tail 
 decomposition 
 needed ;-)
71. FUNCTIONAL PROGRAMMING OTHER PROBLEMS ▸Recursion is terrible ▸Space leaks are hard to fix
72. FUNCTIONAL PROGRAMMING OTHER PROBLEMS ▸Recursion is terrible ▸Space leaks are hard to fix ▸Solvable with pain and YourKit
73. TAKEAWAYS
74. 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)
75. 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
76. QUESTIONS?