Upcoming SlideShare
×

# (Functional) reactive programming (@pavlobaron)

1,773 views
1,583 views

Published on

Slides of my high-level talk on (functional) reactive programming from OOP 2014 in Munich.

Published in: Technology
12 Likes
Statistics
Notes
• Full Name
Comment goes here.

Are you sure you want to Yes No
• Be the first to comment

Views
Total views
1,773
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
0
0
Likes
12
Embeds 0
No embeds

No notes for slide

### (Functional) reactive programming (@pavlobaron)

1. 1. ﬁrst, let’s look at something maybe completely unexpected…
2. 2. (functional) reactive programming as the only true way to overcome ever-changing data
3. 3. pavlo.baron@codecentric.de @pavlobaron
4. 4. what is non-reactive programming?
5. 5. a = 1! b = a + 1! // a == 1, b == 2 a = a + 1! // a == 2, b == 2
6. 6. what is reactive programming?
7. 7. a = 1! b = a + 1! // a == 1, b == 2 a = a + 1! // a == 2, b == 3
8. 8. or even…
9. 9. a = 1! b = a + 1! c = b + 1! // a == 1, b == 2, c == 3 a = a + 1! // a == 2, b == 3, c == 4
10. 10. and so on. you get the point
11. 11. what is functional reactive programming?
12. 12. ! f(g(h(i(j(a)))))! ! with a changing over time
13. 13. how can this be modelled?
14. 14. time, signal, event, ﬂow, transport, logic are separated
15. 15. values change over time. Logic doesn’t explicitly take time into account
16. 16. every value change signals/triggers re-computation of the subgraph of the logic relying on the value
17. 17. events are recurrent or non-recurrent, not backing any speciﬁc value. They can be similar to signals, but can also lead to dynamic ﬂow modiﬁcation, conﬁguration propagation etc.
18. 18. ﬂow is a dynamic graph of logic, with routing rules based on value dependencies
19. 19. transport is an infrastructural detail. Transports implement ﬂows in a speciﬁc environment, be it a single machine or a distributed system
20. 20. logic deﬁnes what happens when a value changes, be it normal or exceptional behaviour
21. 21. 2 example foundations for (F)RP
22. 22. disclaimer ! no real code examples here, as they don’t contribute to the communication of concepts, but instead tend to end up in discussions about syntax and programming language theory. ! Also, real code on slides, you know..
23. 23. Erlang (erlang.org)
24. 24. there is no value re-assignment in Erlang. Values changing over time can be “encapsulated” in the process (actor) loop
25. 25. signals can be modelled in Erlang as messages sent to actor groups with every holding actor’s loop run
26. 26. events can be modelled as messages sent to relevant actors or whole groups. Some events are already provided by the runtime
27. 27. ﬂow can be modelled as hierarchy of actors and their groups, with the ability to dynamically change it, add new actors or even modify their code at runtime
28. 28. transport is what the runtime already offers out-of-the-box: message delivery to local actors or remote ones, with location transparency
29. 29. logic can be implemented as pattern-matched functions, called as actors’ callbacks on arriving messages
30. 30. Erlang doesn’t implement (F)RP abstractions as ﬁrst-class citizens, but it offers more general abstractions to model these
31. 31. Elm (elm-lang.org)
32. 32. little example from Elm web page. ! (hope it still works, ‘cause sometimes live demos just don’t work..)
33. 33. values changing over time represent UI elements, time ticks, mouse position and other values that can (interactively) change
34. 34. signals and events are combined, simplifying programming interface
35. 35. ﬂow is combination of signals, through the nature of programming for the web-browser conﬁgurable and changeable
36. 36. signal transportation is done trough “lifting” of signals through functions, out-of-the-box available HTTP communication with a “server”
37. 37. logic are reusable, minimal, theoretically sequentially combinable, regular functions
38. 38. Elm implements FRP pragmatically, focused on webbrowser applications and UIbased interactions
39. 39. more example foundations exist, implementing the concepts partially or fully, adopting them as far as possible for a particular platform. ! Rx*, Reactor, Akka, Bacon.js +++
40. 40. thought experiment: modelling immediate, continuous analytics on never ending streams of data
41. 41. values changing over time appear as payloads on streams from different channels
42. 42. signals are notiﬁcations sent to a component’s downstream whenever it has computed a value based on its upstream. Signal is an indication of new / modiﬁed value availability
43. 43. events are recurrent time ticks, conﬁguration and ﬂow modiﬁcations etc.
44. 44. ﬂow is a topology of components, connected through streams
45. 45. transport is inner-process, inter-process and distributed communication through embedded or external messaging middleware
46. 46. logic are reusable, theoretically sequentially combinable components that implement minimal pieces such as statistics, ﬁlters, aggregates, parts of continuous queries etc.
47. 47. what problem domains can be addressed by (F)RP?
48. 48. interaction streaming robotics continuous analytics M2M communication ++ theoretically every problem where complex, hierarchical/staged logic needs to be reapplied when some values constantly change
49. 49. what are implications of (F)RP on architecture?
50. 50. reaction paradigm switch declarative ﬂow control different approach to testing harder to debug overﬂow protection high componentisation
51. 51. thank you