-\subsection{\texorpdfstring{\Glsxtrlong{FRP}}{Functional reactive programming}}\label{sec:related_frp}
-The \gls{TOP} paradigm is often compared to \gls{FRP} and while they appear to be similar---they both process events---, in fact they are very different.
-\Gls{FRP} was introduced by \citet{elliott_functional_1997}.
-The paradigm strives to make modelling systems safer, more efficient, composable.
-The core concepts are behaviours and events.
-A behaviour is a value that varies over time.
-Events are happenings in the real world and can trigger behaviours.
-Events and behaviours may be combined using combinators.
-\Gls{TOP} allows for more complex collaboration patterns than \gls{FRP} \citep{wang_maintaining_2018}, and in consequence is unable to provide the strong guarantees on memory usage available in a restricted variant of \gls{FRP} such as arrowized \gls{FRP} \citep{nilsson_functional_2002}.
-
-The way \gls{FRP}, and for that matter \gls{TOP}, systems are programmed stays close to the design when the domain matches suits the paradigm.
-The \gls{IOT} domain seems to suit this style of programming very well in just the device layer\footnote{While a bit out of scope, it deserves mention that for \gls{SN}, \gls{FRP} and stream based approaches are popular as well \citep{sugihara_programming_2008}.} but also for entire \gls{IOT} systems.
-
-For example, Potato is an \gls{FRP} language for building entire \gls{IOT} systems using powerful devices such as the Raspberry Pi leveraging the Erlang \gls{VM} \citep{troyer_building_2018}.
-It requires client devices to be able to run the Erlang \gls{VM} which makes it unsuitable for low memory environments.
-
-The emfrp language compiles a \gls{FRP} specification for a microcontroller to \gls{C} code \citep{sawada_emfrp:_2016}.
-The \gls{IO} part, the bodies of some functions, still need to be implemented.
-These \gls{IO} functions can then be used as signals and combined as in any \gls{FRP} language.
-Due to the compilation to \gls{C} it is possible to run emfrp programs on tiny computers.
-However, the tasks are not interpreted and there is no communication with a server.
-
-Other examples are mfrp \citep{sawada_emfrp:_2016}, CFRP \citep{suzuki_cfrp_2017}, XFRP \citep{10.1145/3281366.3281370}, Juniper \citep{helbling_juniper:_2016}, Hailstorm \citep{sarkar_hailstorm_2020}, Haski \citep{valliappan_towards_2020}, arduino-copilot~\cite{hess_arduino-copilot_2020}.
-
-\subsection{\texorpdfstring{\Glsxtrlong{TOP}}{Task-oriented programming}}\label{sec:related_top}
-\Gls{TOP} as a paradigm with has been proven to be effective for implementing distributed, multi-user applications in many domains.
-Examples are conference management \citep{plasmeijer_conference_2006}, coastal protection \citep{lijnse_capturing_2011}, incident coordination \citep{lijnse_incidone:_2012}, crisis management \citep{jansen_towards_2010} and telemedicine \citep{van_der_heijden_managing_2011}.
-In general, \gls{TOP} results in a higher maintainability, a high separation of concerns and more effective handling of interruptions of workflow.
-\Gls{IOT} applications contain a distributed and multi-user component, but the software on the device is mostly follows multiple loosely dependent workflows.
-The only other \gls{TOP} language for embedded systems is $\mu$Tasks \citep{piers_task-oriented_2016}.
-It is a non-distributed \gls{TOP} \gls{EDSL} hosted in \gls{HASKELL} designed for embedded systems such as payment terminals.
-They showed that applications tend to be able to cope well with interruptions and be more maintainable.
-However, the hardware requirements for running the standard \gls{HASKELL} system are high.
-
-\subsection{Multi tasking}\label{sec:related_multi}