Understanding the principles of Rx, React, Flow through Programming Paradigms

Presented at Droidcon NYC 2022

This talk introduces the concept of programming paradigms, explores the use of declarative programming, explains the concepts behind reactive and functional reactive programming, and then discusses how to use declarative-ness to improve our programming abstractions.

Transcript

1. Understanding the principles of Rx, React, Flow, and more through Programming Paradigms victor lai dblisse
2. what to expect 1. Table of Contents 2. Overview 3. What is a computer? 4. Programming paradigms 5. Strong abstractions
3. what to expect • My goal is to give you a different lens in which to view programming
4. what to expect • My goal is to give you a different lens in which to view programming • Also, to get you excited about programming paradigms
5. what to expect • My goal is to give you a different lens in which to view programming • Also, to get you excited about programming paradigms • Not academically rigorous, except where noted
6. overview fun main() { val x = calc() } fun func(): Int { val a = 1 val b = 2 return a + b }
7. overview fun main() { val x = calc() } fun func(): Int { val a = 1 val b = 2 return a + b } Functions? Imperative?
8. overview fun main() { val x = calc() } fun func(): Int { val a = 1 val b = 2 return a + b } Functions? Imperative? How can we have imperative and functional code at the same time?
9. overview • How do we draw the lines between even imperative and functional programming?
10. overview • How do we draw the lines between even imperative and functional programming? • How we even vocalize the differences in style in the same block of code?
11. • How do we draw the lines between even imperative and functional programming? • How we even vocalize the differences in style in the same block of code? • What is Reactive Programming? What is Functional Reactive Programming? overview
12. • How do we draw the lines between even imperative and functional programming? • How we even vocalize the differences in style in the same block of code? • What is Reactive Programming? What is Functional Reactive Programming? • Is there a difference? Does it even matter? overview
13. what is a computer, even? • Let’s build a computer from first principles
14. what is a computer? • What is Silicon?
15. what is a computer? •
16. what is a computer? •
17. what is a computer? •
18. what is a computer? • What is a transistor?
19. what is a computer? • Building a transistor out of silicon
20. what is a computer? • Building a transistor out of silicon
21. what is a computer? • Building a transistor out of silicon
22. what is a computer? • How do you build a logic gate from transistors?
23. what is a computer? • Building a transistor out of silicon
24. what is a computer? • How do you build a logic gate from transistors?
25. what is a computer? • How do you build a logic gate from transistors?
26. what is a computer? • How do you build a logic gate from transistors?
27. what is a computer? • Memory, latches 4-bit adder
28. what is a computer? • Memory, latches
29. what is a computer? • Memory, latches
30. what is a computer? • Memory, latches
31. what is a computer? • Memory, latches Clocks help deal with propagation delay.
32. what is a computer? • Memory, latches Clocks help deal with propagation delay.
33. what is a computer? • Memory, latches PC - Program Counter MAR - Memory Address Register RAM - Random Access Memory IR - Instruction Register CU - Control Unit ACC - Accumulator ALU - Arithmetic Logic Unit B - B register
34. what is a computer? • Memory, latches 1. PC is 0000 2. IR loads instruction at address 0000 3. CU executes instruction 4. PC increments
35. what is a computer? • Clocks and synchronized circuits
36. what is a computer?
37. programming paradigms • Why learn about computers? • Silicon • Transistors • Logic gates • Synchronous circuits • Instruction set • Programming language
38. programming paradigms • Layers of abstraction • Silicon • Transistors • Logic gates • Synchronous circuits • Instruction set • Programming language
39. programming paradigms • Layers of abstraction • Transistors • Refine: smaller transistors • Increase: logic gates
40. programming paradigms • Layers of abstraction • Programming languages • Refine: abstractions, paradigms • Increase: ??, no code?, spreadsheets
41. programming paradigms • Silicon • Transistors • Logic gates • Synchronous circuits • Instruction set • Programming language • Programming abstractions, paradigms
42. programming paradigms • Why else did we learn about computers?
43. programming paradigms • Why else did we learn about computers? • Computers are imperative
44. programming paradigms • Why learn about computers? • Computers are imperative • Every computer is an abstraction on top of an instruction set for a synchronous circuit
45. programming paradigms • Computers are imperative
46. programming paradigms • Computers are imperative • Imperative is the baseline • “C is bare-metal”
47. programming paradigms • Computers are imperative • Imperative is the baseline • Declarative is everything else
48. programming paradigms • Computers are imperative • Imperative is the baseline • Declarative is everything else • Re-think what it means to be declarative
49. programming paradigms • Re-think what it means to be declarative • Declarative means to declare the computer’s (imperative) behavior • But fundamentally still backed by imperative abstractions • More declarative hides implementation details, aids fuller understanding
50. programming paradigms fun main() { val x = calc() } fun func(): Int { val a = 1 val b = 2 return a + b } Functional? Imperative?
51. programming paradigms fun main() { val x = calc() } fun func(): Int { val a = 1 val b = 2 return a + b } Imperative details
52. programming paradigms fun main() { val x = calc() } fun func(): Int { val a = 1 val b = 2 return a + b } Declarative functions
53. programming paradigms fun main() { val x = calc() } fun func(): Int { val a = 1 val b = 2 return a + b } Declarative functions Imperative details
54. programming paradigms fun main() { val x = calc() } fun func(): Int { val a = 1 val b = 2 return a + b } Declarative functions Imperative details Different declarative-ness depending on how we view the abstraction
55. programming paradigms fun main() { val x = calc() } fun func(): Int { val a = 1 val b = 2 return a + b } Declarative functions Imperative details Think interface versus implementation detail
56. programming paradigms Declarative cells
57. programming paradigms • Declarative is a gradient • More declarative depending on what level of abstraction we’re looking at the code with
58. programming paradigms • Challenge: is Object-Oriented Programming imperative?
59. programming paradigms • Object-Oriented Programming is imperative?
60. programming paradigms • Object-Oriented Programming is imperative? • But OOP “declares” that objects have functionality
61. programming paradigms • Object-Oriented Programming is imperative? • But OOP “declares” that objects have functionality • Functionality between objects still needs to be wired together, imperatively
62. programming paradigms • Object-Oriented Programming is imperative? • But OOP “declares” that objects have functionality • Functionality between objects still needs to be wired together, imperatively • Functionality of the object can be whatever, as long as the declared contract is fulfilled
63. programming paradigms • We invent rules to improve the declarative- ness of OOP, e.g. SOLID principles • Single Responsibility • Open Closed • Liskov Substitution • Interface Separation • Dependency Inversion
64. programming paradigms • We invent rules to improve the declarative- ness of OOP, e.g. SOLID principles • Single Responsibility • The less an object has to do, the better/ safer/easier its behavior can be declared, and reused
65. programming paradigms • We invent rules to improve the declarative- ness of OOP, e.g. SOLID principles • Open Closed • If you add new behavior to an object, you may change the existing behavior that has been declared for the object; that behavior should be built-in, instead
66. programming paradigms • We invent rules to improve the declarative- ness of OOP, e.g. SOLID principles • Liskov Substitution • If using a subclass breaks the program, then the declared behavior of the super class is incorrect
67. programming paradigms • We invent rules to improve the declarative- ness of OOP, e.g. SOLID principles • Interface Separation • Unnecessary methods on bulky interfaces means there are unnecessary declared dependencies between objects
68. programming paradigms • We invent rules to improve the declarative- ness of OOP, e.g. SOLID principles • Dependency Inversion • Decoupling implementation details makes the declared behavior more consistent, easier to manage, easier to validate
69. programming paradigms • Takeaways • Declarative-ness is a gradient • How you view declarative-ness is tied to the kind of abstraction you construct • More declarative code is more valuable; it is simpler to express, easier to understand
70. programming paradigms • Paradigms more formally
71. programming paradigms fun main() { val x = calc() println(x) } fun func(): Int { val a = 1 val b = 2 return a + b (de fi ne (main) (let ((x sum)) (display x))) (de fi ne (sum) (+ 1 2))
72. programming paradigms fun main() { val x = calc() println(x) } fun func(): Int { val a = 1 val b = 2 return a + b (de fi ne (main) (let ((x sum)) (display x))) (de fi ne (sum) (+ 1 2)) Record feature A way to reference data
73. programming paradigms fun main() { val x = calc() println(x) } fun func(): Int { val a = 1 val b = 2 return a + b (de fi ne (main) (let ((x sum)) (display x))) (de fi ne (sum) (+ 1 2)) Closure feature A way to scope “work"
74. programming paradigms fun main() { var x = calc() println(x) } fun func(): Int { val a = 1 val b = 2 return a + b (de fi ne (main) (let ((x sum)) (display x))) (de fi ne (sum) (+ 1 2)) Named state feature State over time, variables.
75. programming paradigms
76. programming paradigms
77. programming paradigms • Concurrency paradigms
78. programming paradigms • Concurrency paradigms • It’d be better if we could declare that our code was concurrent, rather than implement the concurrency ourselves
79. programming paradigms • Concurrency paradigms • It’d be better if we could declare that our code was concurrent, rather than implement the concurrency ourselves • Our tools by default are pretty imperative though, we pretend we’re a CPU and manually manage threads
80. programming paradigms var listeners = emptySet<Listener>() fun add(l: Listener) { listeners = listeners + l } fun ping() { listeners.each { it.ping() } }
81. programming paradigms ConcurrentModificationException var listeners = emptySet<Listener>() fun add(l: Listener) { listeners = listeners + l } fun ping() { listeners.each { it.ping() } }
82. programming paradigms var listeners = emptySet<Listener>() fun add(l: Listener) = synchronized(this) { listeners = listeners + l } fun ping() = synchronized(this) { listeners.each { it.ping() } }
83. programming paradigms • Shared-state concurrent programming • Concurrency like threads, shared access to resource, transaction locking • Ex: Java Executors • Impossible to have confidence of the order of execution by the scheduler, so enforce order with single-threaded operation
84. programming paradigms • Message-passing concurrent programming • Multiple single-threaded components guard resources, send/respond to events to/from other components • Ex: Swift Actors • Single-thread is more deterministic, but less concurrent
85. programming paradigms var listeners = emptySet<Listener>() while (true) { val m = messages.poll() when (m) { is Add -> listeners += m.listener is Ping -> listeners.each { it.ping() } } }
86. programming paradigms • Continuous synchronous programming • Outputs instantly follow inputs • Very theoretical, like a math equation for time t
87. programming paradigms
88. programming paradigms • Continuous synchronous programming • Outputs instantly follow inputs • Very theoretical, like a math equation for time t • Also known as functional reactive programming
89. programming paradigms • Discrete synchronous programming • Synchronous programming as in synchronous circuits, outputs follow inputs after a discrete clock “tick”
90. programming paradigms
91. programming paradigms • Discrete synchronous programming • Synchronous programming as in synchronous circuits, outputs follow inputs after a discrete clock “tick” • Also known as reactive programming formally • Ex: RxJava
92. programming paradigms • RxJava • In an Rx stream, Source and Observers coordinate to ensure the same inputs always results in the same outputs • Imagine each input associated with a clock tick, and the input progressing through each operator on each tick
93. programming paradigms map delay itchMap .. .. ..
94. programming paradigms
95. programming paradigms
96. programming paradigms
97. programming paradigms
98. programming paradigms
99. programming paradigms
100. programming paradigms
101. programming paradigms
102. programming paradigms • RxJava declares the guarantees it provides when dealing with concurrent events
103. programming paradigms • RxJava declares the guarantees it provides when dealing with concurrent events • Within an Rx stream, we can trust that there is a deterministic order of operations
104. programming paradigms • Continuation programming • Resume execution at a later point in time • Ex: Kotlin coroutines, Exceptions, gotos
105. programming paradigms • Continuation programming • Resume execution at a later point in time • Ex: Kotlin coroutines, Exceptions, gotos • Embedding “threads” in the imperative model feels natural, as our brains operate in the imperative world
106. programming paradigms • Continuation programming • Resume execution at a later point in time • Ex: Kotlin coroutines, Exceptions, gotos • Embedding “threads” in the imperative model feels natural, as our brains operate in the imperative world • Async by default is very powerful
107. programming paradigms
108. programming paradigms • Takeaways • So you’re saying we already have all the tools, paradigms, patterns we need to write perfectly deterministic, declarative code?
109. programming paradigms • Takeaways • So you’re saying we already have all the tools, paradigms, patterns we need to write perfectly deterministic, declarative code? • What happens if we misuse these patterns?
110. programming paradigms val relay = PublishRelay.create<Int>() Observable.from(1, 2, 3) .switchMap { x -> relay.accept(x) Observable.just(x) } .subscribe { relay.accept(x) }
111. val relay = PublishRelay.create<Int>() Observable.from(1, 2, 3) .switchMap { x -> relay.accept(x) Observable.just(x) } .subscribe { relay.accept(x) } programming paradigms Single streams are deterministic, multiple streams are harder to reason
112. programming paradigms class Emitter { fun emitsSomePattern() = Observable.create { emitter -> val relay = PublishRelay.create<Int>() val subs = CompositeDisposable() emitter.setDisposable(subs) subs.add( relay.subscribe(emitter::onNext) ) subs.add( Observable.from(1, 2, 3) .switchMap { x -> relay.accept(x) Observable.just(x) } .subscribe { relay.accept(x) } ) } } Non-deterministic in the small, maybe deterministic in the large. Gradient!
113. programming paradigms If our entire application was a single Rx stream, then we could be more confident that its entire behavior could be deterministic. class Emitter { fun emitsSomePattern() = Observable.create { emitter -> val relay = PublishRelay.create<Int>() val subs = CompositeDisposable() emitter.setDisposable(subs) subs.add( relay.subscribe(emitter::onNext) ) subs.add( Observable.from(1, 2, 3) .switchMap { x -> relay.accept(x) Observable.just(x) } .subscribe { relay.accept(x) } ) } }
114. programming paradigms But it’s hard to write a complex app as a single stream… class Emitter { fun emitsSomePattern() = Observable.create { emitter -> val relay = PublishRelay.create<Int>() val subs = CompositeDisposable() emitter.setDisposable(subs) subs.add( relay.subscribe(emitter::onNext) ) subs.add( Observable.from(1, 2, 3) .switchMap { x -> relay.accept(x) Observable.just(x) } .subscribe { relay.accept(x) } ) } }
115. programming paradigms So how do we reconcile using a declarative, deterministic paradigm in a way that reduces its declarative-ness? class Emitter { fun emitsSomePattern() = Observable.create { emitter -> val relay = PublishRelay.create<Int>() val subs = CompositeDisposable() emitter.setDisposable(subs) subs.add( relay.subscribe(emitter::onNext) ) subs.add( Observable.from(1, 2, 3) .switchMap { x -> relay.accept(x) Observable.just(x) } .subscribe { relay.accept(x) } ) } }
116. programming paradigms • What does it mean to misuse a paradigm?
117. strong abstractions • What does it mean to misuse a paradigm? • Differentiate between the paradigm, and the language’s implementation of the paradigm
118. strong abstractions fun main() { var x = calc() println(x) } fun func(): Int { val a = 1 val b = 2 return a + b (de fi ne (main) (let ((x sum)) (display x))) (de fi ne (sum) (+ 1 2)) Functional programming
119. strong abstractions fun main() { var x = calc() println(x) } fun func(): Int { val a = 1 val b = 2 return a + b (de fi ne (main) (let ((x sum)) (display x))) (de fi ne (sum) (+ 1 2)) Scheme forbids* mutability
120. strong abstractions fun main() { var x = calc() println(x) } fun func(): Int { val a = 1 val b = 2 return a + b (de fi ne (main) (let ((x 0)) (set! x sum) (display x))) (de fi ne (sum) (+ 1 2)) Scheme discourages mutability in its language design
121. strong abstractions • Differentiate between the paradigm, and the language’s implementation of the paradigm • Some implementations of the paradigm are better than others • Harder to make mistakes • More declarative
122. fun execute(): Single<Int> { val x = getValue() return Single.just(x) } strong abstractions
123. fun execute(): Single<Int> { return Single.fromCallable { getValue() } } strong abstractions Rx has lots of rules to use safely, to maintain its declarative-ness
124. fun execute(): Single<Int> { return Single.fromCallable { getValue() } } strong abstractions When we get it right, we have a very powerful tool
125. fun execute(): Flow<Int> = { val x = getValue() return fl ow { emit(x) } } strong abstractions Problems not limited to Java
126. async fun execute(): Int { return getValue() } strong abstractions Different pattern prevents making that mistake altogether
127. async fun execute(): Int { return getValue() } strong abstractions Also think about how you cannot start a coroutine without a scope
128. strong abstractions • A strong paradigm abstraction makes it hard to make mistakes that break the rules of the paradigm abstraction
129. strong abstractions • A strong paradigm abstraction makes it hard to make mistakes that break the rules of the paradigm abstraction • Sometimes, we don’t even know what rules we’ve broken!
130. val relay = PublishRelay.create<Int>() Observable.from(1, 2, 3) .switchMap { x -> relay.accept(x) Observable.just(x) } .subscribe { relay.accept(x) } strong abstractions Why are we allowed to even break the rules?
131. val relay = PublishRelay.create<Int>() Observable.from(1, 2, 3) .switchMap { x -> relay.accept(x) Observable.just(x) } .subscribe { relay.accept(x) } strong abstractions Why are we allowed to even break the rules? Java is very flexible.
132. strong abstractions • SOLID for RxJava, Flow
133. strong abstractions • SOLID for RxJava, Flow • Dependency inversion • All events in a stream should be at the same level of abstraction
134. strong abstractions • SOLID for RxJava, Flow • Subscribe for side-effects • Interactions with non-stream behaviors should be limited to the subscribe handler • Avoid emitting into other streams from the middle of a stream • “Safe” side-effects, like logging, excluded
135. strong abstractions • SOLID for RxJava, Flow • One stream • Consolidating behavior into a single stream maintains the declarative-ness of the flow of events • Return Observables, not Disposables
136. strong abstractions • SOLID for RxJava, Flow • L… Safe bridges • Use Observable.create, Relays, to create safe bridges between the imperative and reactive world
137. fun events() = Observable.create { emitter -> val l = object : Listener { override fun onEvent() = emitter.onNext(OnEvent) } listeners.setListener(l) emitter.setCancellable { listeners.removeListener(l) } } strong abstractions
138. strong abstractions • Takeaways • Consider the declarative-ness of the code when using a new pattern • Learn the rules of the pattern, or create your own rules to maintain the advantages of the pattern
139. strong abstractions • What are the rules for other programming paradigms, like coroutines? • Ex: How bad is emitting into Flows from coroutines you’re also collecting?
140. strong abstractions • What are the rules for other programming paradigms, like coroutines? • Ex: How bad is emitting into Flows from coroutines you’re also collecting? • What are the rules for your own architectures, libraries? How easy is it to break those rules?
141. strong abstractions • What is the next programming paradigm?
142. strong abstractions • What is the next programming paradigm? • We invent new paradigms all the time building architectures, solving problems
143. strong abstractions • What is the next programming paradigm? • We invent new paradigms abstractions all the time building architectures, solving problems
144. strong abstractions • What is the next programming paradigm? • We invent new paradigms abstractions all the time building architectures, solving problems • A paradigm is just the name of an abstraction of how we think about our programs
145. strong abstractions • As we invent our own abstractions, we can think about how to make them stronger, more expressive, more declarative, more deterministic, to solve our needs
146. strong abstractions • As we invent our own abstractions, we can think about how to make them stronger, more expressive, more declarative, more deterministic, to solve our needs • As we use other abstractions, we should think about how to use them safely, to maintain their declarative-ness
147. further reading • Programming Paradigms for Dummies • Peter Van Roy • Build an 8-bit computer from scratch • Ben Eater • Conal Elliot’s blog (creator(?) of FRP) victor lai dblisse