Published on February 4, 2014
ﬁrst, let’s look at something maybe completely unexpected…
(functional) reactive programming as the only true way to overcome ever-changing data
what is non-reactive programming?
a = 1! b = a + 1! // a == 1, b == 2 a = a + 1! // a == 2, b == 2
what is reactive programming?
a = 1! b = a + 1! // a == 1, b == 2 a = a + 1! // a == 2, b == 3
a = 1! b = a + 1! c = b + 1! // a == 1, b == 2, c == 3 a = a + 1! // a == 2, b == 3, c == 4
and so on. you get the point
what is functional reactive programming?
! f(g(h(i(j(a)))))! ! with a changing over time
how can this be modelled?
time, signal, event, ﬂow, transport, logic are separated
values change over time. Logic doesn’t explicitly take time into account
every value change signals/triggers re-computation of the subgraph of the logic relying on the value
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.
ﬂow is a dynamic graph of logic, with routing rules based on value dependencies
transport is an infrastructural detail. Transports implement ﬂows in a speciﬁc environment, be it a single machine or a distributed system
logic deﬁnes what happens when a value changes, be it normal or exceptional behaviour
2 example foundations for (F)RP
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..
there is no value re-assignment in Erlang. Values changing over time can be “encapsulated” in the process (actor) loop
signals can be modelled in Erlang as messages sent to actor groups with every holding actor’s loop run
events can be modelled as messages sent to relevant actors or whole groups. Some events are already provided by the runtime
ﬂ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
transport is what the runtime already offers out-of-the-box: message delivery to local actors or remote ones, with location transparency
logic can be implemented as pattern-matched functions, called as actors’ callbacks on arriving messages
Erlang doesn’t implement (F)RP abstractions as ﬁrst-class citizens, but it offers more general abstractions to model these
little example from Elm web page. ! (hope it still works, ‘cause sometimes live demos just don’t work..)
values changing over time represent UI elements, time ticks, mouse position and other values that can (interactively) change
signals and events are combined, simplifying programming interface
ﬂow is combination of signals, through the nature of programming for the web-browser conﬁgurable and changeable
signal transportation is done trough “lifting” of signals through functions, out-of-the-box available HTTP communication with a “server”
logic are reusable, minimal, theoretically sequentially combinable, regular functions
Elm implements FRP pragmatically, focused on webbrowser applications and UIbased interactions
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 +++
thought experiment: modelling immediate, continuous analytics on never ending streams of data
values changing over time appear as payloads on streams from different channels
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
events are recurrent time ticks, conﬁguration and ﬂow modiﬁcations etc.
ﬂow is a topology of components, connected through streams
transport is inner-process, inter-process and distributed communication through embedded or external messaging middleware
logic are reusable, theoretically sequentially combinable components that implement minimal pieces such as statistics, ﬁlters, aggregates, parts of continuous queries etc.
what problem domains can be addressed by (F)RP?
interaction streaming robotics continuous analytics M2M communication ++ theoretically every problem where complex, hierarchical/staged logic needs to be reapplied when some values constantly change
what are implications of (F)RP on architecture?
reaction paradigm switch declarative ﬂow control different approach to testing harder to debug overﬂow protection high componentisation
Presentación que realice en el Evento Nacional de Gobierno Abierto, realizado los ...
In this presentation we will describe our experience developing with a highly dyna...
Presentation to the LITA Forum 7th November 2014 Albuquerque, NM
Un recorrido por los cambios que nos generará el wearabletech en el futuro
Um paralelo entre as novidades & mercado em Wearable Computing e Tecnologias Assis...
Functional reactive programming is a programming paradigm for reactive programming using the building blocks of functional programming. Functional reactive ...
Reactive programming can be functional, ... minimal contracts and expectations between components. @pavlobaron # ... Reactive programming solves ...
Bodil is a compulsive conference speaker in ... flows, functional and reactive programming as well as ... functional programming and F# courses ...
... (@pavlobaron) Slides of my controversial talk at DOAG and JUG in Germany 5 months ago. Technology. 100% Big Data, 0% Hadoop, 0% Java (@pavlobaron) ...
Check out the schedule for Build Stuff'15 Lithuania ...