• Save
(Functional) reactive programming (@pavlobaron)
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

(Functional) reactive programming (@pavlobaron)

on

  • 965 views

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

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

Statistics

Views

Total Views
965
Views on SlideShare
951
Embed Views
14

Actions

Likes
4
Downloads
0
Comments
0

1 Embed 14

https://twitter.com 14

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

(Functional) reactive programming (@pavlobaron) Presentation Transcript

  • 1. first, let’s look at something maybe completely unexpected…
  • 2. (functional) reactive programming as the only true way to overcome ever-changing data
  • 3. pavlo.baron@codecentric.de @pavlobaron
  • 4. what is non-reactive programming?
  • 5. a = 1! b = a + 1! // a == 1, b == 2 a = a + 1! // a == 2, b == 2
  • 6. what is reactive programming?
  • 7. a = 1! b = a + 1! // a == 1, b == 2 a = a + 1! // a == 2, b == 3
  • 8. or even…
  • 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. and so on. you get the point
  • 11. what is functional reactive programming?
  • 12. ! f(g(h(i(j(a)))))! ! with a changing over time
  • 13. how can this be modelled?
  • 14. time, signal, event, flow, transport, logic are separated
  • 15. values change over time. Logic doesn’t explicitly take time into account
  • 16. every value change signals/triggers re-computation of the subgraph of the logic relying on the value
  • 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. flow is a dynamic graph of logic, with routing rules based on value dependencies
  • 19. transport is an infrastructural detail. Transports implement flows in a specific environment, be it a single machine or a distributed system
  • 20. logic defines what happens when a value changes, be it normal or exceptional behaviour
  • 21. 2 example foundations for (F)RP
  • 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. Erlang (erlang.org)
  • 24. there is no value re-assignment in Erlang. Values changing over time can be “encapsulated” in the process (actor) loop
  • 25. signals can be modelled in Erlang as messages sent to actor groups with every holding actor’s loop run
  • 26. events can be modelled as messages sent to relevant actors or whole groups. Some events are already provided by the runtime
  • 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. transport is what the runtime already offers out-of-the-box: message delivery to local actors or remote ones, with location transparency
  • 29. logic can be implemented as pattern-matched functions, called as actors’ callbacks on arriving messages
  • 30. Erlang doesn’t implement (F)RP abstractions as first-class citizens, but it offers more general abstractions to model these
  • 31. Elm (elm-lang.org)
  • 32. little example from Elm web page. ! (hope it still works, ‘cause sometimes live demos just don’t work..)
  • 33. values changing over time represent UI elements, time ticks, mouse position and other values that can (interactively) change
  • 34. signals and events are combined, simplifying programming interface
  • 35. flow is combination of signals, through the nature of programming for the web-browser configurable and changeable
  • 36. signal transportation is done trough “lifting” of signals through functions, out-of-the-box available HTTP communication with a “server”
  • 37. logic are reusable, minimal, theoretically sequentially combinable, regular functions
  • 38. Elm implements FRP pragmatically, focused on webbrowser applications and UIbased interactions
  • 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. thought experiment: modelling immediate, continuous analytics on never ending streams of data
  • 41. values changing over time appear as payloads on streams from different channels
  • 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. events are recurrent time ticks, configuration and flow modifications etc.
  • 44. flow is a topology of components, connected through streams
  • 45. transport is inner-process, inter-process and distributed communication through embedded or external messaging middleware
  • 46. logic are reusable, theoretically sequentially combinable components that implement minimal pieces such as statistics, filters, aggregates, parts of continuous queries etc.
  • 47. what problem domains can be addressed by (F)RP?
  • 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. what are implications of (F)RP on architecture?
  • 50. reaction paradigm switch declarative flow control different approach to testing harder to debug overflow protection high componentisation
  • 51. thank you