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.

Alexandru Nedelcu

March 25, 2017
Tweet

More Decks by Alexandru Nedelcu

Other Decks in Programming

Transcript

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

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

    Managed ▸ Minefield for Stack Overflows ▸Not Pure ▸Has Ops Not Referentially Transparent
  3. FP DESIGN KEY INSIGHTS 1. Freeze Algorithms into Data-Structures 2.

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

    Think State Machines 3. Be Lazy 
 (Strict Values => Functions ;-))
  5. 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)
  6. ASYNCHRONY EVALUATION IN SCALA Eager Lazy Synchronous A () =>

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

    A Function0[A] Asynchronous (A => Unit) => Unit () => (A => Unit) => Unit Future[A] Task[A]
  8. FP DESIGN WHAT IS MONIX? ▸ Scala / Scala.js library

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

    ▸ Allows for cancelling of a running computation ▸ https://monix.io/docs/2x/eval/task.html
  10. 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
  11. 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
  12. 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)

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

    ▸Linked Lists are terrible ▸Async or Lazy Boundaries are terrible
  14. 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
  15. 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)