\input{subfilepreamble}
+\setcounter{chapter}{9}
+
\begin{document}
\input{subfileprefix}
-\chapter{Could Tierless Languages Reduce \texorpdfstring{\glsxtrshort{IOT}}{IoT} Development Grief?}%
+\chapter{Could tierless languages reduce IoT development grief?}%
\label{chp:smart_campus}
\begin{chapterabstract}
\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*}
\section{Background and related work}%
\label{sec_t4t:Background}
-\subsection{\texorpdfstring{\Glsxtrlong{UOG}}{University of Glasgow} smart campus}%
+\subsection{University of Glasgow smart campus}%
\label{sec_t4t:UoGSmartCampus}
% Jeremy
The \gls{UOG} is partway through a ten-year campus
A longitudinal study of sensor accuracy has also been
conducted \citep{harth_predictive_2018}.
-\subsection{\texorpdfstring{\Glsxtrlong{IOT}}{IoT} applications}%
+\subsection{\IOT{} applications}%
\label{sec_t4t:Stacks}
Web applications are necessarily complex distributed systems, with client browsers interacting with a remote webserver and data store. Typical \gls{IOT} applications
\begin{landscape}
\begin{figure}
- \includegraphics[width=.95\linewidth]{arch}
+ \includegraphics[width=.95\linewidth]{archg}
\caption{%
\Gls{PRS} and \gls{PWS} (left) together with \gls{CRS} and \gls{PRS} (right) mapped to the four-tier \gls{IOT} architecture.
Every box is the diagram denotes a source file or base.
\end{figure}
\end{landscape}
-\subsection{The benefits and challenges of developing tiered \texorpdfstring{\glsxtrshort{IOT}}{IoT} stacks}
+\subsection{The benefits and challenges of developing tiered \IOT{} stacks}
Using multiple tiers to
structure complex software is a common software engineering practice that provides significant architectural benefits for \gls{IOT} and other software. The tiered \gls{PYTHON} \gls{PRS} and \gls{PWS} stacks exhibit these benefits.
However, a tiered architecture poses significant challenges for developers of \gls{IOT} and other software. The tiered \gls{PYTHON} \gls{PRS} and \gls{PWS} stacks exhibit these challenges, and we analyse these in detail later in the paper.
\begin{description}[style=sameline]
- \item[Polyglot development] the developer must be fluent in all the languages and components in the stack, known as being a full-stack developer for webapps \citep{mazzei2018full}. That is, the developer must correctly use multiple languages that have different paradigms, i.e.\ manage significant \emph{semantic friction} \citep{ireland2009classification}. For example the \gls{PWS} developer must integrate components written in seven languages with two paradigms (\cref{sec_t4t:interoperation}).
+ \item[Polyglot development] the developer must be fluent in all the languages and components in the stack, known as being a full-stack developer for webapps \citep{mazzei2018full}. That is, the developer must correctly use multiple languages that have different paradigms, i.e.\ manage significant \emph{semantic friction} \citep{ireland_classification_2009}. For example the \gls{PWS} developer must integrate components written in seven languages with two paradigms (\cref{sec_t4t:interoperation}).
\item[Correct interoperation] the developer must adhere to the \gls{API} or communication protocols between components. \Cref{sec_t4t:codesize,sec_t4t:resourcerich} show that communication requires some 17\% of \gls{PRS} and \gls{PWS} code, so around 100 \gls{SLOC}. \Cref{sec_t4t:Communication} discusses the complexity of writing this distributed communication code.
\item[Maintaining type safety] is a key element of the semantic friction encountered in multi-language stacks, and crucial for correctness. The developer must maintain type safety across a range of very different languages and diverse type systems, with minimal tool support. We show an example where \gls{PRS} loses type safety over the network layer (\Cref{sec_t4t:typesafety}).
\item[Managing multiple failure modes] different components may have different failure modes, and these must be coordinated. \Cref{sec_t4t:NetworkManagement} outlines how \gls{PRS} and \gls{PWS} use heartbeats to manage failures.
An example tierless web framework that uses a \gls{DSL} is Haste \citep{10.1145/2775050.2633367}, that embeds the \gls{DSL} in \gls{HASKELL}. Haste programs are compiled multiple times: the server code is generated by the standard \gls{GHC} \gls{HASKELL} compiler \citep{hall1993glasgow}; Javascript for the client is generated by a custom \gls{GHC} compiler backend. The design leverages \gls{HASKELL}'s high-level programming abstractions and strong typing, and benefits from \gls{GHC}: a mature and sophisticated compiler.
-\subsection{Tierless \texorpdfstring{\glsxtrshort{IOT}}{IoT} languages}
+\subsection{Tierless \IOT{} languages}
The use of tierless languages in \gls{IOT} applications is both more recent and less common than for web applications.
Tierless \gls{IOT} programming may extend tierless web programming by adding network and perception layers.
The presentation layer of a tierless \gls{IOT} language, like tierless web languages, benefits from almost invariably executing in a standard browser. The perception layer faces greater challenges, often executing on one of a set of slow and resource-constrained microcontrollers. Hence, tierless \gls{IOT} languages typically compile the perception layer to either \ccpp{} (the lingua franca of microcontrollers), or to some intermediate representation to be interpreted.
-\subsubsection{\texorpdfstring{\Glsxtrlongpl{DSL}}{DSLs} for microcontrollers}
+\subsubsection{DSLs for microcontrollers}
Many \glspl{DSL} provide high-level programming for microcontrollers, for example providing strong typing and memory safety.
For example Copilot \citep{hess_arduino-copilot_2020}
and Ivory \citep{elliott_guilt_2015} are imperative \glspl{DSL} embedded in a functional language that compile to \ccpp{}. In contrast to \cimtask{} such \glspl{DSL} are not tierless \gls{IOT} languages as they have no automatic integration with the server, i.e.\ with the application and presentation layers.
-\subsubsection{\texorpdfstring{\Glsxtrlong{FRP}}{Functional reactive programming}}
+\subsubsection{Functional reactive programming}
\Gls{FRP} is a declarative paradigm often used for implementing the perception layer of an \gls{IOT} stack.
Examples include 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}, and Haski \citep{valliappan_towards_2020}.
None of these languages are tierless \gls{IOT} languages as they have no automatic integration with the server.
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 \texorpdfstring{\glsxtrshort{IOT}}{IoT} systems}
+\subsubsection{Erlang\slash{}Elixir \IOT{} systems}
A number of production \gls{IOT} systems are engineered in Erlang or Elixir, and many are mostly tierless.
That is the perception, network and application layers are sets of distributed Erlang processes, although the presentation layer typically uses some conventional web technology.
A resource-rich sensor node may support many Erlang processes on an Erlang VM, or low level code (typically \ccpp{}) on a resource-constrained microcontroller can emulate an Erlang process.
Only a small fraction of these systems are described in the academic literature, example exceptions are \citep{sivieri2012drop,shibanai_distributed_2018}, with many described only in grey literature or not at all.
-\subsection{Characteristics of tierless \texorpdfstring{\glsxtrshort{IOT}}{IoT} languages}%
+\subsection{Characteristics of tierless \IOT{} languages}%
\label{sec_t4t:characteristics}
This study compares a pair of tierless \gls{IOT} languages with conventional tiered \gls{PYTHON} \gls{IOT} software. \Citask{} and \cimtask{} represent a specific set of tierless language design decisions, however many alternative designs are available. Crucially the limitations of the tierless \gls{CLEAN} languages, e.g.\ that they currently provide limited security, should not be seen as limitations of tierless technologies in general. This section briefly outlines key design decisions for tierless \gls{IOT} languages, discusses alternative designs, and describes the \gls{CLEAN} designs. The \gls{CLEAN} designs are illustrated in the examples in the following section.
\Citask{} and \cimtask{} are typical in this respect: little effort has yet been expended on improving their security. Of course as tierless languages they benefit from static type safety and automatically generated communication and placement. Some preliminary work shows that, as the communication between layers is protocol agnostic, more secure alternatives can be used. One example is to run the \gls{ITASK} server behind a reverse proxy implementing TLS\slash{}SSL encryption \citep{wijkhuizen_security_2018}. A second is to add integrity checks or even encryption to the communication protocol for resource-rich sensor nodes \citep{de_boer_secure_2020}.
-\section{Task-oriented and \texorpdfstring{\glsxtrshort{IOT}}{IoT} programming in \texorpdfstring{\glsentrytext{CLEAN}}{Clean}}
+\section{Task-oriented and \IOT{} programming in Clean}
To make this paper self-contained we provide a concise overview of \gls{CLEAN}, \gls{TOP}, and \gls{IOT} programming in \gls{ITASK} and \gls{MTASK}. The minor innovations reported here are the interface to the \gls{IOT} sensors, and the \gls{CLEAN} port for the Raspberry Pi.
\Gls{CLEAN} is a statically typed \gls{FP} language similar to \gls{HASKELL}: both languages are pure and non-strict \citep{achten_clean_2007}.
A key difference is how state is handled: \gls{HASKELL} typically embeds stateful actions in the \haskellinline{IO} Monad \citep{peyton_jones_imperative_1993,wiki:IO}.
-In contrast, \gls{CLEAN} has a uniqueness type system to ensure the single-threaded use of stateful objects like files and windows \citep{barendsen_smetsers_1996}.
+In contrast, \gls{CLEAN} has a uniqueness type system to ensure the single-threaded use of stateful objects like files and windows \citep{barendsen_uniqueness_1996}.
Both \gls{CLEAN} and \gls{HASKELL} support fairly similar models of generic programming \citep{ComparingGenericProgramming}, enabling functions to work on many types. As we shall see generic programming is heavily used in task-oriented programming \citep{GenericProgrammingExtensionForClean,HinzeGenericFunctionalProgramming}, for example to construct web editors and communication protocols that work for any user-defined datatype.
-\subsection{\texorpdfstring{\Glsxtrlong{TOP}}{Task-oriented programming}}
+\subsection{Task-oriented programming}
\Gls{TOP} is a declarative programming paradigm for constructing interactive distributed systems \citep{plasmeijer_task-oriented_2012}.
Tasks are the basic blocks of \gls{TOP} and represent work that needs to be done in the broadest sense.
\Glspl{SDS} offer a general abstraction of data shared by different tasks, analogous to variables, persistent values, files, databases and peripherals like sensors. Combinators compose \glspl{SDS} into a larger \gls{SDS}, and
parametric lenses define a specific view on \pgls{SDS}.
-\subsection{The \texorpdfstring{\glsentrytext{ITASK}}{iTask} \texorpdfstring{\glsxtrlong{EDSL}}{eDSL}}%
+\subsection{The iTask eDSL}%
\label{sec_t4t:itasks}
The \gls{ITASK} \gls{EDSL} is designed for constructing multi-user distributed applications, including web \citep{TOP-ICFP07} or \gls{IOT} applications.
Here we present \gls{ITASK} by example, and the first is a complete program to repeatedly read the room temperature from a digital humidity and temperature (DHT) sensor attached to the machine and display it on a web page (\cref{lst_t4t:itaskTemp}).
\begin{lstClean}[%
numbers=left,
- caption={SimpleTempSensor: a \citask{} program to read a local room temperature sensor and display it on a web page},
+ caption={SimpleTempSensor: a \citask{} program to read a local room temperature sensor and display it on a web page.},
label={lst_t4t:itaskTemp}]
module simpleTempSensor
\begin{figure}[ht]
\centering
- \begin{subfigure}[t]{.2\textwidth}
+ \begin{subfigure}[c]{.2\textwidth}
\centering
\fbox{\includegraphics[width=.9\textwidth]{readTempTask}}
\caption{Web page.}
\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}.
\begin{lstClean}[%
numbers=left,
- caption={TempHistory: a tierless \citask{} webapplication that records and manipulates timed temperatures},
+ caption={TempHistory: a tierless \citask{} webapplication that records and manipulates timed temperatures.},
label={lst_t4t:TempHistory}]
module TempHistory
\centering
\begin{subfigure}[t]{.5\textwidth}
\centering
- \fbox{\includegraphics[width=.95\textwidth]{TempHistory1}}
+ \fbox{\includegraphics[width=.95\textwidth]{TempHistory1g}}
\caption{Web page sorted by time.}
\end{subfigure}%
\begin{subfigure}[t]{.5\textwidth}
\centering
- \fbox{\includegraphics[width=.95\textwidth]{TempHistory2}}
+ \fbox{\includegraphics[width=.95\textwidth]{TempHistory2g}}
\caption{Web page sorted by temperature.}
\end{subfigure}
\caption{Web pages generated by the \cleaninline{TempHistory} \citask{} tierless web application.
\Cref{fig_t4t:TempHistory} shows two screenshots of web pages generated by the \cleaninline{TempHistory} program. \Cref{fig_t4t:TempHistoryDiagram} is the deployment diagram showing the addition of the persistent \cleaninline{measurementsSDS} that stores the history of temperature measurements.
-\subsection{Engineering tierless \texorpdfstring{\glsxtrshort{IOT}}{IoT} systems with \texorpdfstring{\glsentrytext{ITASK}}{iTask}}%
+\subsection{Engineering tierless \IOT{} systems with iTask}%
\label{sec_t4t:itaskIOT}
A typical \gls{IOT} system goes beyond a web application by incorporating a distributed set of sensor nodes each with a collection of sensors or actuators. That is, they add the perception and network layers in \cref{fig_t4t:iot_arch}. If the sensor nodes have the computational resources to support an \gls{ITASK} server, as a Raspberry Pi does, then \gls{ITASK} can also be used to implement these layers, and integrate them with the application and presentation layers tierlessly.
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}.
\label{fig_t4t:cwtsweb}
\end{figure}
-\subsection{The \texorpdfstring{\glsentrytext{MTASK}}{mTask} \texorpdfstring{\glsxtrlong{EDSL}}{eDSL}}%
+\subsection{The mTask eDSL}%
\label{sec_t4t:mtasks}
In many \gls{IOT} systems the sensor nodes are resource constrained, e.g.\ inexpensive microcontrollers. These are far cheaper, and consume far less power, than a single-board computer like a Raspberry Pi. Microcontrollers also allow the programmer to easily control peripherals like sensors and actuators via the \gls{IO} pins of the processor.
The \gls{MTASK} \gls{OS} is stored in flash memory while the tasks are stored in \gls{RAM} to minimise wear on the flash memory. While sending byte code to a sensor node at runtime greatly increases the amount of communication, this can be mitigated as any tasks known at compile time can be preloaded on the microcontroller.
In contrast, compiled programs, like \ccpp{}, are stored in flash memory and there can only ever be a few thousand programs uploaded during the lifetime of the microcontroller before exhausting the flash memory.
-\subsection{Engineering tierless \texorpdfstring{\glsxtrshort{IOT}}{IoT} systems with \texorpdfstring{\glsentrytext{MTASK}}{mTask}}%
+\subsection{Engineering tierless \IOT{} systems with mTask}%
\label{sec_t4t:mtaskIOT}
A tierless \gls{CLEAN} \gls{IOT} system with microcontroller sensor nodes integrates a set of \gls{ITASK} tasks that specify the application and presentation layers with a set of \gls{MTASK}s that specify the perception and network layers.
The \gls{ITASK} \gls{SDS} \cleaninline{latestTemp} is first transformed to \pgls{SDS} that accepts only temperature values,
the \cleaninline{dateTimeStampedShare} adds the data via a lens.
The \cleaninline{mapRead} adjusts the read type.
-This new \gls{SDS} of type \cleaninline{Real} is lifted to the \gls{MTASK} program with \cleaninline{liftsds}.
+This new \gls{SDS} of type \cleaninline{Real} is lifted to the \gls{MTASK} program with \cleaninline{lowerSds}.
%The \cleaninline{mapRead} ensures that every write to \cleaninline{localSds} is automatically time-stamped when it is written to \cleaninline{latestTemp}.
-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{liftsds}---automatically communicates new temperature values from the microcontroller to the server.
+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={
latestTemp :: SDSLens () (? (DateTime, Real)) (DateTime, Real)
latestTemp = mapReadWrite (listToMaybe, \x xs -> ?Just [x:xs]) ?None tempSDS[+\label{lst_t4t:mtasktemp:di1}\srcmark{DI}+]
-devTask :: Main (MTask v Real) | mtask, dht, liftsds v[+\label{lst_t4t:mtasktemp:devTask}+]
+devTask :: Main (MTask v Real) | mtask, dht, lowerSds v[+\label{lst_t4t:mtasktemp:devTask}+]
devTask =
DHT (DHT_DHT DHT_pin DHT11) \dht ->[+\label{lst_t4t:mtasktemp:DHT}+][+\label{lst_t4t:mtasktemp:si1}\srcmark{SI}+]
- liftsds \localSds =[+\label{lst_t4t:mtasktemp:liftsds}+][+\label{lst_t4t:mtasktemp:co1}\srcmark{CO}+]
+ lowerSds \localSds =[+\label{lst_t4t:mtasktemp:liftsds}+][+\label{lst_t4t:mtasktemp:co1}\srcmark{CO}+]
mapRead (snd o fromJust) (dateTimeStampedShare latestTemp)[+\label{lst_t4t:mtasktemp:o}+][+\label{lst_t4t:mtasktemp:sn1}\srcmark{SN}+]
In {main = rpeatEvery (ExactSec interval)[+\label{lst_t4t:mtasktemp:rpeatevery}+][+\label{lst_t4t:mtasktemp:sn2}\srcmark{SN}+]
(temperature dht >>~.[+\label{lst_t4t:mtasktemp:temperature}+][+\label{lst_t4t:mtasktemp:si2}\srcmark{SI}+]
\label{fig_t4t:cwtsDiagram}
\end{figure}
-\section{\texorpdfstring{\glsxtrshort{UOG}}{UoG} smart campus case study}%
+\section{UoG smart campus case study}%
\label{sec_t4t:Case}
The basis for our comparison between tiered and tierless technologies are four \gls{IOT} systems that all conform to the \gls{UOG} smart campus specifications (\cref{sec_t4t:OperationalComparison}). There is a small (12 room) deployment of the conventional \gls{PYTHON}-based \gls{PRS} stack that uses Raspberry Pi supersensors, and its direct comparator is the tierless \gls{CRS} implementation: also deployed on Raspberry Pis.
To represent the more common microcontroller sensor nodes we select ESP8266X powered \gls{WEMOS} D1 Mini microcontrollers. To evaluate tierless technologies on microcontrollers we compare the conventional \gls{PYTHON}\slash\gls{MICROPYTHON} \gls{PWS} stack with the tierless \gls{CWS} implementation.
\centering
\begin{subfigure}[t]{.49\textwidth}
\centering
- \includegraphics[width=.9\textwidth]{wemos}
- \caption{A \gls{WEMOS} used in \gls{PWS} and \gls{CWS}}.%
+ \includegraphics[width=.9\textwidth]{wemosg}
+ \caption{A \gls{WEMOS} used in \gls{PWS} and \gls{CWS}.}%
\end{subfigure}%
\begin{subfigure}[t]{.49\textwidth}
\centering
- \includegraphics[width=.9\textwidth]{prss}
+ \includegraphics[width=.9\textwidth]{prssg}
\caption{A Raspberry Pi used in \gls{PRS} and \gls{CRS}.}%
\end{subfigure}
\caption{Exposed views of sensor nodes.}%%
%\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.
The Raspberry Pi supersensor node used in \gls{CRS} and \gls{PRS} use more power as they have a general purpose ARM processor and run mainstream Linux. With all sensors enabled, they consume \qtyrange{1}{2}{\watt}, depending on ambient load. So a microcontroller sensor node consumes an order of magnitude less power than a supersensor node.
-\section[Is tierless \texorpdfstring{\glsxtrshort{IOT}}{IoT} programming easier than tiered?]{\hspace{-9pt}Is tierless \texorpdfstring{\glsxtrshort{IOT}}{IoT} programming easier than tiered?}%
+\section[Is tierless \IOT{} programming easier than tiered?]{\hspace{-9pt}Is tierless \IOT{} programming easier than tiered?}%
\label{sec_t4t:ProgrammingComparison}
-
This section investigates whether tierless languages make \gls{IOT} programming \emph{easier} by comparing the \gls{UOG} smart campus implementations. The \gls{CRS} and \gls{CWS} implementations allow us to evaluate tierless languages for
resource-rich and for resource-constrained sensor nodes respectively. The \gls{PRS} and \gls{PWS} allow a like-for-like comparison with tiered \gls{PYTHON} implementations.
There are several main reasons for the similarity.
One is that the server-side code, i.e.\ for the presentation and application layers, is identical for both resource rich\slash{}constrained implementations.
-The identical server code accounts for approximately 40\% of the \gls{PWS} and \gls{PRS} codebases, and approximately 85\% of the \gls{CWS} and \gls{CRS} codebases (\cref{fig_t4t:multipercentage}).
+The identical server code accounts for approximately 40\% of the \gls{PWS} and \gls{PRS} codebases, and approximately 85\% of the \gls{CWS} and \gls{CRS} codebases (\cref{fig_t4t:multipercentage}\todo{make gray\-sca\-le}).
For the perception and network layers on the sensor nodes, the \gls{PYTHON} and \gls{MICROPYTHON} implementations have the same structure, e.g.\ a class for each type of sensor, and use analogous libraries.
Indeed, approaches like CircuitPython \citep{CircuitPython} allow the same code to execute on both resource-rich and resource-constrained sensor nodes.
The tierless implementations use just two conceptually-similar \glspl{DSL} embedded in the same host language, and a single paradigm (\cref{table_t4t:languages,table_t4t:paradigms}). In contrast, the tiers in \gls{PRS} and \gls{PWS} use six or more very different languages, and both imperative and declarative paradigms. Multiple languages are commonly used in other typical software systems like web stacks, e.g.\ a recent survey of open source projects reveals that on average at least five different languages are used \citep{mayer2015empirical}. Interoperating components in multiple languages and paradigms raises a plethora of issues.
-Interoperation \emph{increases the cognitive load on the developer} who must simultaneously think in multiple languages and paradigms. This is commonly known as semantic friction or impedance mismatch \citep{ireland2009classification}. A simple illustration of this is that the tiered \gls{PRS} source code comprises some 38 source and configuration files, whereas the tierless \gls{CRS} requires just 3 files (\cref{table_t4t:multi}). The source could be structured as a single file, but to separate concerns is structured into three modules, one each for \glspl{SDS}, types, and control logic \citep{wang_maintaining_2018}.
+Interoperation \emph{increases the cognitive load on the developer} who must simultaneously think in multiple languages and paradigms. This is commonly known as semantic friction or impedance mismatch \citep{ireland_classification_2009}. A simple illustration of this is that the tiered \gls{PRS} source code comprises some 38 source and configuration files, whereas the tierless \gls{CRS} requires just 3 files (\cref{table_t4t:multi}). The source could be structured as a single file, but to separate concerns is structured into three modules, one each for \glspl{SDS}, types, and control logic \citep{wang_maintaining_2018}.
The developer must \emph{correctly interoperate the components}, e.g.\ adhere to the \gls{API} or communication protocols between components. The interoperation often entails additional programming tasks like marshalling or demarshalling data between components. For example, in the tiered \gls{PRS} and \gls{PWS} architectures, \gls{JSON} is used to serialise and deserialise data strings from the \gls{PYTHON} collector component before storing the data in the Redis database (\cref{lst_t4t:json}).
%e.g.\ to marshall and demarshall data between components.
\Cref{lst_t4t:mtasktemp} illustrates communication in a tierless \gls{IOT} language. That is, the \gls{CWTS} temperature sensor requires just three lines of communication code, and uses just three communication functions. The
\cleaninline{withDevice} function on \cref{lst_t4t:mtasktemp:withdevice} integrates a sensor node with the server, allowing tasks to be sent to it. The
\cleaninline{liftmTask} on \cref{lst_t4t:mtasktemp:liftmtask} integrates an \gls{MTASK} in the \gls{ITASK} runtime by compiling it and sending it for interpretation to the sensor node.
-The \cleaninline{liftsds} on \cref{lst_t4t:mtasktemp:liftsds} integrates \glspl{SDS} from \gls{ITASK} into \gls{MTASK}, allowing \gls{MTASK} tasks to interact with data from the \gls{ITASK} server.
+The \cleaninline{lowerSds} on \cref{lst_t4t:mtasktemp:liftsds} integrates \glspl{SDS} from \gls{ITASK} into \gls{MTASK}, allowing \gls{MTASK} tasks to interact with data from the \gls{ITASK} server.
The exchange of data, user interface, and communication are all automatically generated.
\subsection{High level abstractions}%
\begin{table}
\centering
- \caption{Comparing \gls{CLEAN} and \gls{PYTHON} programming abstractions using the \gls{PWTS} and \gls{CWTS} temperature sensors (\gls{SLOC} and total number of files.)}%
+ \caption{Comparing \gls{CLEAN} and \gls{PYTHON} programming abstractions using the \gls{PWTS} and \gls{CWTS} temperature sensors (\gls{SLOC} and total number of files).}%
\label{table_t4t:temp}
\begin{tabular}{llccl}
\toprule
As examples, the step combinator \cleaninline{>>*.} allows the task value on the left-hand side to be observed until one of the steps is enabled;
and the \cleaninline{viewSharedInformation} (line 31 of \cref{lst_t4t:mtasktemp}) part of the UI will be automatically updated when the value of the \gls{SDS} changes. Moreover, each \gls{SDS} provides automatic updates to all coupled \glspl{SDS} and associated tasks. Thirdly, the amount of explicit type information is minimised in comparison to other languages, as much is automatically inferred \citep{hughes1989functional}.
-\section{Could tierless \texorpdfstring{\glsxtrshort{IOT}}{IoT} programming be more reliable than tiered?}%
+\section{Could tierless \IOT{} programming be more reliable than tiered?}%
\label{sec_t4t:Discussion}
% Phil: so widely known that a citation is unnecessary \citep{madsen1990strong}.
That said, many distributed system components written in languages that primarily use static typing, like \gls{HASKELL} and Scala, use some dynamic typing, e.g.\ to ensure that the data arriving in a message has the anticipated type \citep{epstein2011towards,gupta2012akka}.
-In a typical tiered multi-language \gls{IOT} system the developer must integrate software in different languages with very different type systems, and potentially executing on different hardware. The challenges of maintaining type safety have long been recognised as a major component of the semantic friction in multi-language systems, e.g.\ \citep{ireland2009classification}.
+In a typical tiered multi-language \gls{IOT} system the developer must integrate software in different languages with very different type systems, and potentially executing on different hardware. The challenges of maintaining type safety have long been recognised as a major component of the semantic friction in multi-language systems, e.g.\ \citet{ireland_classification_2009}.
Even if the different languages used in two components are both strongly typed, they may attribute, often quite subtly, different types to a value. Such type errors can lead to runtime errors, or the application silently reporting erroneous data. Such errors can be hard to find. Automatic detection of such errors is sometimes possible, but requires an addition tool like Jinn \citep{Jinn,Furr2005}.
%Such errors can be hard to debug, partly because there is very limited tool support for detecting them
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