(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
0 Comments
12 Likes
Statistics
Notes
  • Be the first to comment

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

No notes for slide

(Functional) reactive programming (@pavlobaron)

  1. 1. first, 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, flow, 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 specific value. They can be similar to signals, but can also lead to dynamic flow modification, configuration propagation etc.
  18. 18. flow is a dynamic graph of logic, with routing rules based on value dependencies
  19. 19. transport is an infrastructural detail. Transports implement flows in a specific environment, be it a single machine or a distributed system
  20. 20. logic defines 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. flow 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 first-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. flow is combination of signals, through the nature of programming for the web-browser configurable 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 notifications sent to a component’s downstream whenever it has computed a value based on its upstream. Signal is an indication of new / modified value availability
  43. 43. events are recurrent time ticks, configuration and flow modifications etc.
  44. 44. flow 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, filters, 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 flow control different approach to testing harder to debug overflow protection high componentisation
  51. 51. thank you

×