Upgrade to Pro — share decks privately, control downloads, hide ads and more …

FP Design: A Tale Of Monix

FP Design: A Tale Of Monix

Slides for the talk I've had at the NEScala Unconference

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.

82b99892431723a7758b76871f2a9bd1?s=128

Alexandru Nedelcu

March 25, 2017
Tweet

Transcript

  1. FP DESIGN A TALE OF MONIX

  2. Alexandru Nedelcu Developer @ eloquentix.com
 @alexelcu / alexn.org

  3. ITERATOR CASE STUDY ON THE WORLD MOST FAMOUS OOP ABSTRACTION

    Part 1
  4. ITERATOR HOW DID ITERATOR HAPPEN?

  5. ITERATOR HOW DID ITERATOR HAPPEN?

  6. ITERATOR HOW DID ITERATOR HAPPEN?

  7. ITERATOR HOW DID ITERATOR HAPPEN?

  8. ITERATOR PROBLEMS ?

  9. ITERATOR PROBLEMS ? ▸Synchronous Only ▸blocks threads for async stuff

    ▸no way around it, it’s in the signature
  10. ITERATOR PROBLEMS ? ▸ Synchronous Only ▸No Backed-in Resource Managed

  11. ITERATOR PROBLEMS ? ▸ Synchronous Only ▸ No Backed-in Resource

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

    Managed ▸ Minefield for Stack Overflows ▸Not Pure ▸Has Ops Not Referentially Transparent
  13. FP DESIGN HOW TO Part 2

  14. ARCHITECTURE IS FROZEN MUSIC Johann Wolfgang Von Goethe FP DESIGN

  15. DATA STRUCTURES ARE FROZEN ALGORITHMS Jon Bentley FP DESIGN

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

  17. FP DESIGN KEY INSIGHTS 1. Freeze Algorithms into Data-Structures 2.

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

    Think State Machines 3. Be Lazy 
 (Strict Values => Functions ;-))
  19. 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)
  20. Finite State Machine Cat

  21. FP DESIGN EXAMPLE: LINKED LISTS

  22. FP DESIGN EXAMPLE: LINKED LISTS

  23. FP DESIGN EXAMPLE: LINKED LISTS

  24. ITERANT A PURELY FUNCTIONAL ITERATOR Part 3

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

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

    concerns
  27. ITERANT USAGE

  28. ITERANT RESOURCE MANAGEMENT

  29. ITERANT USAGE Not pure yet, not referentially transparent!

  30. ITERANT DEFERRING

  31. ITERANT FILTER

  32. ITERANT FILTER

  33. ITERANT FILTER

  34. None
  35. ASYNCHRONY CONCURRENCY, NON-DETERMINISM Part 4

  36. ASYNCHRONY QUICK INTRO

  37. ASYNCHRONY QUICK INTRO

  38. ASYNCHRONY QUICK INTRO

  39. ASYNCHRONY CAN WE DO THIS ?

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

  41. ASYNCHRONY EVALUATION IN SCALA Eager Lazy Synchronous A () =>

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

    A Function0[A] Asynchronous (A => Unit) => Unit () => (A => Unit) => Unit Future[A] Task[A]
  43. “A FUTURE REPRESENTS A VALUE, DETACHED FROM TIME” Viktor Klang

    MONIX TASK
  44. ASYNCHRONY GOING LAZY (AGAIN)

  45. FP DESIGN WHAT IS MONIX? ▸ Scala / Scala.js library

    ▸ For composing asynchronous programs ▸ Exposes Observable & Task ▸ Reactive Streams compliant ▸ Typelevel Member ▸ See: monix.io
  46. ASYNCHRONY MONIX TASK ▸ High-performance ▸ Lazy, possibly asynchronous behaviour

    ▸ Allows for cancelling of a running computation ▸ https://monix.io/docs/2x/eval/task.html
  47. ASYNCHRONY GOING LAZY (AGAIN)

  48. HIGHER-KINDED
 POLYMORPHISM Bring Your Own Booze Part 5

  49. HIGHER-KINDED POLYMORPHISM CAN WE DO THIS ?

  50. HIGHER-KINDED POLYMORPHISM CAN WE DO THIS ?

  51. HIGHER-KINDED POLYMORPHISM GENERICS OF A HIGHER KIND

  52. HIGHER-KINDED POLYMORPHISM GENERICS OF A HIGHER KIND

  53. HIGHER-KINDED POLYMORPHISM GENERICS OF A HIGHER KIND

  54. HIGHER-KINDED POLYMORPHISM GENERICS OF A HIGHER KIND

  55. None
  56. HIGHER-KINDED POLYMORPHISM OOP VS PARAMETRIC POLYMORPHISM ▸…

  57. HIGHER-KINDED POLYMORPHISM OOP VS PARAMETRIC POLYMORPHISM ▸OOP is about Information

    Hiding
 (in types too) ▸OOP handles Heterogeneity
  58. 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
  59. HIGHER-KINDED POLYMORPHISM OOP VS PARAMETRIC POLYMORPHISM ▸ArrayIterator vs ListIterator ▸Iterant[Task]

    vs Iterant[Eval]
  60. 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
  61. HIGHER-KINDED POLYMORPHISM PROBLEMS ▸Pushes compiler to its limits

  62. HIGHER-KINDED POLYMORPHISM PROBLEMS ▸ Pushes compiler to its limits ▸Unfamiliarity

    for users
  63. 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)

  64. HIGHER-KINDED POLYMORPHISM UPSIDE

  65. HIGHER-KINDED POLYMORPHISM LAWS

  66. HIGHER-KINDED POLYMORPHISM LAWS ▸ Typelevel Cats ▸ Typelevel Discipline ▸

    ScalaCheck
  67. FUNCTIONAL PROGRAMMING PERFORMANCE PROBLEMS ▸Linked Lists are everywhere in FP

    ▸Linked Lists are terrible ▸Async or Lazy Boundaries are terrible
  68. 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
  69. FUNCTIONAL PROGRAMMING PERFORMANCE SOLUTIONS Efficient head/tail decomposition needed ;-)

  70. FUNCTIONAL PROGRAMMING WARNING: PRESERVE PURITY IN OPS

  71. FUNCTIONAL PROGRAMMING OTHER PROBLEMS ▸(General) Recursion is terrible ▸Space leaks

    are hard to fix
  72. FUNCTIONAL PROGRAMMING OTHER PROBLEMS ▸(General) Recursion is terrible ▸Space leaks

    are hard to fix ▸Solvable with pain and YourKit
  73. DEMO

  74. TAKEAWAYS

  75. FUNCTIONAL PROGRAMMING 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)
  76. FUNCTIONAL PROGRAMMING TAKEAWAYS ▸Libraries: 
 Monix, Cats, ScalaCheck ▸Iterant:
 github.com/monix/monix/pull/280

  77. QUESTIONS?