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

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 +++

41. thought experiment:
modelling immediate,
continuous analytics on never
ending streams of data

42. values changing over time
appear as payloads on streams
from different channels

43. 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

44. events are recurrent time
ticks, configuration and
flow modifications etc.

45. flow is a topology of
components, connected
through streams

46. transport is inner-process, inter-process
and distributed communication through
embedded or external messaging
middleware

47. logic are reusable, theoretically
sequentially combinable components
that implement minimal pieces such
as statistics, filters, aggregates,
parts of continuous queries etc.

48. what problem domains
can be addressed by
(F)RP?

49. interaction
streaming
robotics
continuous analytics
M2M communication
++
theoretically every problem where complex,
hierarchical/staged logic needs to be
reapplied when some values constantly change

50. what are implications
of (F)RP on architecture?

51. reaction
paradigm switch
declarative flow control
different approach to testing
harder to debug
overflow protection
high componentisation

52. thank you