Functional Programming Inception

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?