\input{subfilepreamble}
+\setcounter{chapter}{9}
+
\begin{document}
\input{subfileprefix}
\chapter{Could tierless languages reduce IoT development grief?}%
\begin{enumerate*}
\item Tierless languages benefit from reduced interoperation, requiring far fewer languages, paradigms and source code files e.g.\ \gls{CWS} uses two languages, one paradigm and three source code files where \gls{PWS} uses seven languages, two paradigms and 35 source code files
(\cref{table_t4t:multi,table_t4t:languages,table_t4t:paradigms}).
- \item Tierless languages benefit from automatically synthesized, and hence correct, communication between components that may be distributed.
+ \item Tierless languages benefit from automatically synthesised, and hence correct, communication between components that may be distributed.
\item Tierless languages benefit from high-level programming abstractions like compositional and higher-order task combinators (\cref{sec_t4t:ProgrammingComparison}).
\end{enumerate*}
Potato goes beyond other \gls{FRP} languages to provide a tierless \gls{FRP} \gls{IOT} language for resource rich sensor nodes \citep{troyer_building_2018}. It does so using the Erlang programming language and sophisticated virtual machine.
-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}.
+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 arrowised \gls{FRP} \citep{nilsson_functional_2002}.
\subsubsection{Erlang\slash{}Elixir \IOT{} systems}
A number of production \gls{IOT} systems are engineered in Erlang or Elixir, and many are mostly tierless.
\Cref{lst_t4t:itaskTemp:measurementsSDS} defines a persistent \gls{SDS} to store a list of measurements, and for communication between tasks. The \gls{SDS} is analogous to the SQL DBMS in many tiered web applications.
TempHistory defines two tasks that interact with the \texttt{mea\-sure\-ments\-SDS}: \texttt{mea\-sure\-Task} adds measurements at each detected change in the temperature.
-It starts by defining a \cleaninline{dht} object as before, and then defines a recursive \cleaninline{task} function parameterized by the \cleaninline{old} temperature.
+It starts by defining a \cleaninline{dht} object as before, and then defines a recursive \cleaninline{task} function parameterised by the \cleaninline{old} temperature.
This function reads the temperature from the DHT sensor and uses the step combinator, \cleaninline{>>*}, to compose it with a list of actions.
The first of those actions that is applicable determines the continuation of this task. If no action is applicable, the task on the left-hand side is evaluated again.
The first action checks whether the new temperature is different from the \cleaninline{old} temperature (\cref{lst_t4t:itaskTemp:action1}). If so, it records the current time and adds the new measurements to the \cleaninline{measurementsSDS}.
The \cleaninline{latestTemp} is a \emph{lens} on the \cleaninline{tempSDS}.
A lens is a new \gls{SDS} that is automatically mapped to another \gls{SDS}.
Updating one of the \glspl{SDS} that are coupled in this way automatically updates the other.
-The function \cleaninline{mapReadWrite} is parameterized by the read and write functions, the option to handle asynchronous update conflicts (here \cleaninline{?None}) and the \gls{SDS} to be transformed (here \cleaninline{tempSDS}).
+The function \cleaninline{mapReadWrite} is parameterised by the read and write functions, the option to handle asynchronous update conflicts (here \cleaninline{?None}) and the \gls{SDS} to be transformed (here \cleaninline{tempSDS}).
The result of reading is the head of the list, if it exists.
The type for writing \cleaninline{latestTemp} is a tuple with a new \cleaninline{DateTime} and temperature as \cleaninline{Real}.
The \cleaninline{mainTask} is a simple \gls{ITASK} task that starts the \cleaninline{devTask} \gls{MTASK} task on the device identified by \cleaninline{deviceInfo} (\cref{lst_t4t:mtasktemp:withdevice}). At runtime the \gls{MTASK} slice is compiled to byte code, shipped to the indicated device, and launched. Thereafter, \cleaninline{mainTask} reads temperature values from the \cleaninline{latestTemp} \gls{SDS} that is shared with the \gls{MTASK} device, and displays them on a web page (\cref{fig_t4t:cwtsweb}). The \gls{SDS}---shared with the device using \cleaninline{lowerSds}---automatically communicates new temperature values from the microcontroller to the server.
-While this simple application makes limited use of the \gls{MTASK} \gls{EDSL}, it illustrates some powerful \gls{MTASK} program abstractions like basic tasks, task combinators, named recursive and parameterized tasks, and \glspl{SDS}.
+While this simple application makes limited use of the \gls{MTASK} \gls{EDSL}, it illustrates some powerful \gls{MTASK} program abstractions like basic tasks, task combinators, named recursive and parameterised tasks, and \glspl{SDS}.
Function composition (\cref{lst_t4t:mtasktemp:o}) and currying (\cref{lst_t4t:mtasktemp:setSds}) are inherited from the \gls{CLEAN} host language.
As \gls{MTASK} tasks are dynamically compiled, it is also possible to select and customise tasks as required at runtime.
For example, the interval used in the \cleaninline{rpeatevery} task (\cref{lst_t4t:mtasktemp:rpeatevery}) could be a parameter to the \cleaninline{devTask} function.
-\newcommand{\srcmark}[1]{\marginpar[\footnotesize\emph{#1}]{\footnotesize\emph{#1}}}
\begin{lstClean}[%
numbers=left,
caption={
%\subsubsection{Memory Consumption}%
\label{sec_t4t:MemPower}
-\paragraph{Memory} By design sensor nodes are devices with limited computational capacity, and memory is a key restriction. Even supersensors often have less than a \unit{\gibi\byte} of memory, and microcontrollers often have just tens of \unit{\kibi\byte{}s}.
+\paragraph{Memory} By design sensor nodes are devices with limited computational capacity, and memory is a key restriction. Even supersensors often have less than a \unit{\gibi\byte} of memory, and microcontrollers often have just tens of \unit{\kibi\byte}.
%In a tiered implementation the memory residency of the sensor node code can be minimised by carefully crafting it in a language that minimises memory residency. However, ...
As the tierless languages synthesize the code to be executed on the sensor nodes, we need to confirm that the generated code is sufficiently memory efficient.
We show that a bare metal execution environment allows \gls{MTASK} to have better control of peripherals, timing and energy consumption.
The memory available on a microcontroller restricts the programming abstractions available in \gls{MTASK} to a fixed set of combinators, no user defined or recursive data types, strict evaluation, and makes it harder to add new abstractions.
Even with these restrictions \gls{MTASK} provide a higher level of abstraction than most bare metal languages, and can readily express many \gls{IOT} applications including the \gls{CWS} \gls{UOG} smart campus application (\cref{sec_t4t:ComparingTierless}).
-Our empirical results are consistent with the benefits of tierless languages listed in Section 2.1 of \citep{weisenburger2020survey}.
+Our empirical results are consistent with the benefits of tierless languages listed in \citet[\citesection{2.1}]{weisenburger2020survey}.
\subsection{Reflections}
repositories / phd-thesis.git / blobdiff