We report a systematic comparative evaluation of two tierless language technologies for \gls{IOT} stacks: one for resource-rich sensor nodes (\gls{CLEAN} with \gls{ITASK}), and one for resource-constrained sensor nodes (\gls{CLEAN} with \gls{ITASK} and \gls{MTASK}).
The evaluation is based on four implementations of a typical smart campus application: two tierless and two \gls{PYTHON}-based tiered.
- %, with two targeting microcontrollers and two targeting supersensors.
\begin{enumerate*}
\item We show that tierless languages have the potential to significantly reduce the development effort for \gls{IOT} systems, requiring 70\% less code than the tiered implementations. Careful analysis attributes this code reduction to reduced interoperation (e.g.\ two \glspl{EDSL} and one paradigm versus seven languages and two paradigms), automatically generated distributed communication, and powerful \gls{IOT} programming abstractions.
\item We show that tierless languages have the potential to significantly improve the reliability of \gls{IOT} systems, describing how \cimtask{} maintains type safety, provides higher order failure management, and simplifies maintainability.
\item Interoperating components in multiple languages and paradigms increases the developer's cognitive load who must simultaneously think in multiple languages and paradigms, i.e.\ manage significant semantic friction.
\item The developer must correctly interoperate the components, e.g.\ adhere to the \gls{API} or communication protocols between components.
\item To ensure correctness the developer must maintain type safety across a range of very different languages and diverse type systems.
- \item The developer must deal with the potentially diverse failure modes of each component, and of component interoperations.
+ \item The developer must deal with the potentially diverse failure modes of each component, and of component interoperation.
\end{enumerate*}
A radical alternative development paradigm uses a single \emph{tierless} language that synthesizes all components\slash{}tiers in the software stack. There are established \emph{tierless} languages for web stacks, e.g.\ Links \citep{cooper2006links} or Hop \citep{serrano2006hop}.
This paper reports a systematic comparative evaluation of two tierless language technologies for \gls{IOT} stacks: one targeting resource-constrained microcontrollers, and the other resource-rich supersensors. The basis of the comparison is four implementations of a typical smart campus \gls{IOT} stack \citep{hentschel_supersensors:_2016}. Two implementations are conventional tiered \gls{PYTHON}-based stacks: \gls{PRS} and \gls{PWS}. The other two implementations are tierless: \gls{CRS} and \gls{CWS}. Our work makes the following research contributions, and the key results are summarised, discussed, and quantified in \cref{sec_t4t:Conclusion}.
\begin{description}
- \item[C1] We show that \emph{tierless languages have the potential to significantly reduce the development effort for \gls{IOT} systems}.
+ \item[C1] We show that \emph{tierless languages have the potential to significantly reduce the development effort for \gls{IOT} systems}.\label{enum:c1}
We systematically compare code size (\gls{SLOC}) of the four smart campus implementations as a measure of development effort and maintainability \citep{alpernaswonderful,rosenberg1997some}.
The tierless implementations require 70\% less code than the tiered implementations. We analyse the codebases to attribute the code reduction to three factors.
\begin{enumerate*}
access to sensor data through a RESTful \gls{API}.
This allows campus stakeholders to add functionality at a business layer above the layers that we consider here. To date,
simple apps have been developed including room temperature
-monitors and campus utilization maps \citep{hentschel_supersensors:_2016}.
+monitors and campus utilisation maps \citep{hentschel_supersensors:_2016}.
A longitudinal study of sensor accuracy has also been
conducted \citep{harth_predictive_2018}.
\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
+Web applications are necessarily complex distributed systems, with client browsers interacting with a remote web server and data store. Typical \gls{IOT} applications
are even more complex as they combine a web application with a second distributed system of sensor and actuator nodes that collect and aggregate data, operate on it, and communicate with the server.
Both web and \gls{IOT} applications are commonly structured into tiers, e.g.\ the classical four-tier Linux, Apache, MySQL and PHP (LAMP) stack.
-\Gls{IOT} stacks typically have more tiers than webapps, with the number depending on the complexity of the application \citep{sethi2017internet}. While other tiers, like the business layer \citep{muccini2018iot} may be added above them, the focus of our study is on programming the lower four tiers of the \gls{PRS}, \gls{CRS}, \gls{PWS} and \gls{CWS} stacks, as illustrated in \cref{fig_t4t:iot_arch}.
+\Gls{IOT} stacks typically have more tiers than web applications, with the number depending on the complexity of the application \citep{sethi2017internet}. While other tiers, like the business layer \citep{muccini2018iot} may be added above them, the focus of our study is on programming the lower four tiers of the \gls{PRS}, \gls{CRS}, \gls{PWS} and \gls{CWS} stacks, as illustrated in \cref{fig_t4t:iot_arch}.
\begin{description}[style=sameline]
\item [Perception layer] collects the data, interacts with the environment, and consists of devices using light, sound, motion, air quality and temperature sensors.
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{ireland_classification_2009}. 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 web applications \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.
A study of \gls{IOT} stack developers found that interoperation poses a real challenge, that microservices blur the abstraction between tiers, and that both testing and scaling \gls{IOT} applications to more devices are hard \citep{motta2018challenges}.
One way of minimising the challenges of developing tiered polyglot \gls{IOT} software is to standardise and reuse components. This approach has been hugely successful for web stacks, e.g.\ browser standards. The W3C
-Web of Things aims to facilitate re-use by providing standardised metadata and other re-usable technological \gls{IOT} building blocks \citep{guinard_building_2016}. However, the Web of Things has yet to gain widespread adoption. Moreover, as it is based on web technology, it requires the \emph{thing} to run a web server, significantly increasing the hardware requirements.
+Web of Things aims to facilitate re-use by providing standardised metadata and other re-useable technological \gls{IOT} building blocks \citep{guinard_building_2016}. However, the Web of Things has yet to gain widespread adoption. Moreover, as it is based on web technology, it requires the \emph{thing} to run a web server, significantly increasing the hardware requirements.
\section{Tierless languages}%
\label{sec_t4t:TiredvsTierless}
A radical approach to overcoming the challenges raised by tiered distributed software is to use a tierless programming language that eliminates the semantic friction between tiers by generating code for all tiers, and all communication between tiers, from a single program.
Typically a tierless program uses a single language, paradigm and type system, and the entire distributed system is simultaneously checked by the compiler.
-There is intense interest in developing tierless, or multitier, language technologies with a number of research languages developed over the last fifteen years, e.g.\ \citep{cooper2006links, serrano2006hop, troyer_building_2018, 10.1145/2775050.2633367}. These languages demonstrate the
+There is intense interest in developing tierless, or multi-tiered, language technologies with a number of research languages developed over the last fifteen years, e.g.\ \citep{cooper2006links, serrano2006hop, troyer_building_2018, 10.1145/2775050.2633367}. These languages demonstrate the
advantages of the paradigm, including less development effort, better maintainability, and sound semantics of distributed execution. At the same time a number of industrial technologies incorporate tierless concepts, e.g.\ \citep{balat2006ocsigen, bjornson2010composing, strack2015getting}. These languages demonstrate the benefits of the paradigm in practice. Some tierless languages use (embedded) \glspl{DSL} to specify parts of the multi-tier software.
Tierless languages have been developed for a range of distributed paradigms, including web applications, client-server applications, mobile applications, and generic distributed systems. A recent and substantial survey of these tierless technologies is available \citep{weisenburger2020survey}. Here we provide a brief introduction to tierless languages with a focus on \gls{IOT} software.
Example standalone tierless web languages are Links \citep{cooper2006links} and Hop \citep{serrano2006hop}.
From a single declarative program the client, server and database code is simultaneously checked by the compiler, and compiled to the required component languages. For example, Links compiles to HTML and JavaScript for the client side and to SQL on the server-side to interact with the database system.
-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.
+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 \IOT{} languages}
For example a tierless web language must identify client code to ship to browsers, database code to execute in the DBMS, and application code to run on the server.
Tierless web languages can make this determination statically, so-called \emph{tier splitting} using types or syntactic markers like \texttt{server} or \texttt{client} pragmas \citep{cooper2006links,10.1145/2775050.2633367}.
-It is even possible to infer the splitting, relieving the developers from the need to specify it, as illustrated for Javascript as a tierless web language \citep{10.1145/2661136.2661146}.
+It is even possible to infer the splitting, relieving the developers from the need to specify it, as illustrated for JavaScript as a tierless web language \citep{10.1145/2661136.2661146}.
In \cimtask{} and \citask{} tier splitting is specified by functions, e.g.\ the \cimtask{} \cleaninline{asyncTask} function identifies a task for execution on a remote device and \cleaninline{liftmTask} executes the given task on an \gls{IOT} device.
The tier splitting functions are illustrated in examples in the next section, e.g.\ on \cref{lst_t4t:itaskTempFull:startdevtask} in \cref{lst_t4t:itaskTempFull} and \cref{lst_t4t:mtasktemp:liftmtask} in \cref{lst_t4t:mtasktemp}.
\Cimtask{} and \citask{} both use dynamic task placement.
In \cimtask{} sensor nodes are programmed once with the \gls{MTASK} \gls{RTS}, and possibly some precompiled tasks.
-Thereafter a sensor node can dynamically receive \gls{MTASK} programs, compiled at runtime by the server.
-In \citask{} the sensor node runs an \gls{ITASK} server that recieves and executes code from the (\gls{IOT}) server \citep{oortgiese_distributed_2017}.
+Thereafter, a sensor node can dynamically receive \gls{MTASK} programs, compiled at runtime by the server.
+In \citask{} the sensor node runs an \gls{ITASK} server that receives and executes code from the (\gls{IOT}) server \citep{oortgiese_distributed_2017}.
Placement happens automatically as part of the first-class splitting constructs, so \cref{lst_t4t:mtasktemp:liftmtask} in \cref{lst_t4t:mtasktemp} places \cleaninline{devTask} onto the \cleaninline{dev} sensor node.
\subsubsection{Communication}\label{ssec_t4t:communication}
\subsubsection{Security}\label{ssec_t4t:security}
-Security is a major issue and a considerable challenge for many \gls{IOT} systems \citep{alhirabi_security_2021}. There are potentially security issues at each layer in an \gls{IOT} application (\cref{fig_t4t:iot_arch}). The security issues and defence mechanisms at the application and presentation layers are relatively standard, e.g.\ defending against SQL injection attacks. The security issues at the network and perception layers are more challenging. Resource-rich sensor nodes can adopt some standard security measures like encrypting messages, and regularly applying software patches to the operating system. However microcontrollers often lack the computational resources for encryption, and it is hard to patch their system software because the program is often stored in flash memory. In consequence there are infamous examples of \gls{IOT} systems being hijacked to create botnets \citep{203628,herwig_measurement_2019}.
+Security is a major issue and a considerable challenge for many \gls{IOT} systems \citep{alhirabi_security_2021}. There are potentially security issues at each layer in an \gls{IOT} application (\cref{fig_t4t:iot_arch}). The security issues and defence mechanisms at the application and presentation layers are relatively standard, e.g.\ defending against SQL injection attacks. The security issues at the network and perception layers are more challenging. Resource-rich sensor nodes can adopt some standard security measures like encrypting messages, and regularly applying software patches to the operating system. However, microcontrollers often lack the computational resources for encryption, and it is hard to patch their system software because the program is often stored in flash memory. In consequence there are infamous examples of \gls{IOT} systems being hijacked to create botnets \citep{203628,herwig_measurement_2019}.
Securing the entire stack in a conventional tiered \gls{IOT} application is particularly challenging as the stack is implemented in a collection of programming languages with low level programming and communication abstractions. In such polyglot distributed systems it is hard to determine, and hence secure, the flow of data between components. In consequence a small mistake may have severe security implications.
A number of characteristics of tierless languages help to improve security. Communication and placement vulnerabilities are minimised as communication and placement are automatically generated and checked by the compiler. So injection attacks and the exploitation of communication\slash{}placement protocol bugs are less likely. Vulnerabilities introduced by mismatched types are avoided as the entire system is type checked. Moreover, tierless languages can exploit language level security techniques. For example languages like Jif\slash{}split \citep{zdancewic2002secure} and Swift \citep{chong2007secure} place components to protect the security of data. Another example are programming language technologies for controlling information flow, and these can be used to improve security. For example Haski uses them to improve the security of \gls{IOT} systems \citep{valliappan_towards_2020}.
-However many tierless languages have yet to provide a comprehensive set of security technologies, despite its importance in domains like web and \gls{IOT} applications. For example Erlang and many Erlang-based systems \citep{shibanai_distributed_2018,sivieri2012drop}, lack important security measures. Indeed security is not covered in a recent, otherwise comprehensive, survey of tierless technologies \citep{weisenburger2020survey}.
+However, many tierless languages have yet to provide a comprehensive set of security technologies, despite its importance in domains like web and \gls{IOT} applications. For example Erlang and many Erlang-based systems \citep{shibanai_distributed_2018,sivieri2012drop}, lack important security measures. Indeed, security is not covered in a recent, otherwise comprehensive, survey of tierless technologies \citep{weisenburger2020survey}.
\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}.
\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.
Examples of typical tasks range from allowing a user to complete a form, controlling peripherals, moderating other tasks, or monitoring a database.
-From a single declarative description of tasks all of the required software components are generated.
+From a single declarative description of tasks all the required software components are generated.
This may include web servers, client code for browsers or \gls{IOT} devices, and for their interoperation.
That is, from a single \gls{TOP} program the language implementation automatically generates an \emph{integrated distributed system}.
Application areas range from simple web forms or blinking \glspl{LED} to multi-user distributed collaboration between people and machines \citep{oortgiese_distributed_2017}.
\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}).
+Here we present \gls{ITASK} by example, and the first is a complete program to repeatedly read the room temperature from a \gls{DHT} sensor attached to the machine and display it on a web page (\cref{lst_t4t:itaskTemp}).
The first line is the module name, the third imports the \cleaninline{iTask} module, and the main function (\cref{lst_t4t:itaskTemp:systemfro,lst_t4t:itaskTemp:systemto}) launches \cleaninline{readTempTask} and the \gls{ITASK} system to generate the web interface in \cref{fig_t4t:itaskTempSimple}.
-Interaction with a device like the DHT sensor using a protocol like 1-Wire or \gls{I2C} is abstracted into a library. So the \cleaninline{readTempTask} task starts by creating a \cleaninline{dht} sensor object (\cref{lst_t4t:itaskTemp:dhtDef}) thereafter \cleaninline{repeatEvery} executes a task at the specified \cleaninline{interval}. This task reads the temperature from the \cleaninline{dht} sensor, and with a sequential composition combinator \cleaninline{>>~} passes the \cleaninline{temp} value to \cleaninline{viewInformation} that displays it on the web page (\cref{lst_t4t:itaskTemp:viewInformation}).
+Interaction with a device like the \gls{DHT} sensor using a protocol like 1-Wire or \gls{I2C} is abstracted into a library. So the \cleaninline{readTempTask} task starts by creating a \cleaninline{dht} sensor object (\cref{lst_t4t:itaskTemp:dhtDef}) thereafter \cleaninline{repeatEvery} executes a task at the specified \cleaninline{interval}. This task reads the temperature from the \cleaninline{dht} sensor, and with a sequential composition combinator \cleaninline{>>~} passes the \cleaninline{temp} value to \cleaninline{viewInformation} that displays it on the web page (\cref{lst_t4t:itaskTemp:viewInformation}).
The tuning combinator \cleaninline{<<@} adds a label to the web editor displaying the temperature. Crucially, the \gls{ITASK} implementation transparently ships parts of the code for the web-interface to be executed in the browser, and \cref{fig_t4t:itaskTempSimple} shows the UML deployment diagram.
\begin{lstClean}[%
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 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.
+This function reads the temperature from the \gls{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 next action in \cref{lst_t4t:itaskTemp:action2} is always applicable and waits (sleeps) for an interval before returning the old temperature.
\begin{lstClean}[%
numbers=left,
- caption={TempHistory: a tierless \citask{} webapplication that records and manipulates timed temperatures.},
+ caption={TempHistory: a tierless \citask{} web application that records and manipulates timed temperatures.},
label={lst_t4t:TempHistory}]
module TempHistory
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.
-microcontrollers have limited memory capacity, compute power and communication bandwidth, and hence typically no \gls{OS}.
+Microcontrollers have limited memory capacity, compute power and communication bandwidth, and hence typically no \gls{OS}.
These limitations make it impossible to run an \gls{ITASK} server:
there is no \gls{OS} to start the remote task, the code of the task is too big to fit in the available memory and the microcontroller processor is too slow to run it.
The \gls{MTASK} \gls{EDSL} is designed to bridge this gap: \gls{MTASK} tasks can be communicated from the server to the sensor node, to execute within the limitations of a typical microcontroller, while providing programming abstractions that are consistent with \gls{ITASK}.
Like \gls{ITASK}, \gls{MTASK} is task oriented, e.g.\ there are primitive tasks that produce intermediate values, a restricted set of task combinators to compose the tasks, and (recursive) functions to construct tasks.
Tasks in \gls{MTASK} communicate using task values or \glspl{SDS} that may be local or remote, and may be shared by some \gls{ITASK} tasks.
-Apart from the \gls{EDSL}, the \gls{MTASK} system contains a featherlight domain-specific \emph{operating system} running on the microcontroller.
+Apart from the \gls{EDSL}, the \gls{MTASK} system contains a feather-light domain-specific \emph{operating system} running on the microcontroller.
This \gls{OS} task scheduler receives the byte code generated from one or more \gls{MTASK} programs and interleaves the execution of those tasks. The \gls{OS} also manages \gls{SDS} updates and the passing of task results.
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.
Observation of the four implementations shows that they operate as expected, e.g.\ detecting light or motion. To illustrate \cref{fig_t4t:webinterfaces} shows the web interface for the implementations where \gls{CWS} and \gls{CRS} are deployed in a different room from \gls{PWS} and \gls{PRS}.
All four implementations use an identical set of inexpensive sensors, so we expect the accuracy of the data collected is within tolerance levels. This is validated by comparing \gls{PRS} and \gls{PWS} sensor nodes deployed in the same room for some minutes. The measurements show only small variances, e.g.\ temperatures recorded differ by less than \qty{0.4}{\celcius}, and light by less than \qty{1}{lux}. For this room monitoring application precise timings are not critical, and we don't compare the timing behaviours of the implementations.
-% Phil: lets see what the reviewers say
-
\subsubsection{Memory and power consumption}%
%\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}.
-%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.
\begin{table}
In \gls{PWS}, the hand-written \gls{MICROPYTHON} is compiled to byte code for execution on the virtual machine. Low residency is achieved with a fixed size heap and efficient memory management. For example both \gls{MICROPYTHON} and \gls{MTASK} use fixed size allocation units and mark\&sweep garbage collection to minimise memory usage at the cost of some execution time \citep{plamauer2017evaluation}.
The smart campus sensor node programs executing on the Raspberry Pis have far higher maximum residencies than those executing on the microcontrollers: \qty{3.5}{\mebi\byte} for \gls{PRS} and \qty{2.7}{\mebi\byte} for \gls{CRS}. In \gls{CRS} the sensor node code is a set of \gls{ITASK} executing on a full-fledged \gls{ITASK} server running in distributed child mode and this consumes far more memory.
-%The memory used is actually very similar to the memory usage of the server with a single client connected.
In \gls{PRS} the sensor node program is written in \gls{PYTHON}, a language far less focused on minimising memory usage than \gls{MICROPYTHON}. For example an object like a string is larger in \gls{PYTHON} than in \gls{MICROPYTHON} and consequently does not support all features such as \emph{f-strings}.
Furthermore, not all advanced \gls{PYTHON} feature regarding classes are available in \gls{MICROPYTHON}, i.e.\ only a subset of the \gls{PYTHON} specification is supported \citep{diffmicro}.
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.
-
-%\subsection{Temperature Sensor Illustration}
-
\subsection{Comparing tiered and tierless codebases}%
\label{sec_t4t:codesize}
-%A comparison of the Temperature sensor in \gls{PYTHON} Micropyton, Itask \& \gls{MTASK}.
-
\paragraph{Code size}
is widely recognised as an approximate measure of the development and maintenance effort required for a software system \citep{rosenberg1997some}. \Gls{SLOC} is a common code size metric, and is especially useful for multi-paradigm systems like \gls{IOT} systems. It is based on the simple principle that the more \gls{SLOC}, the more developer effort and the increased likelihood of bugs \citep{rosenberg1997some}. It is a simple measure, not dependent on some formula, and can be automatically computed \citep{sheetz2009understanding}.
\Cref{table_t4t:multi} enumerates the \gls{SLOC} required to implement the \gls{UOG} smart campus functionalities in \gls{PWS}, \gls{PRS}, \gls{CWS} and \gls{CRS}. Both \gls{PYTHON} and \gls{CLEAN} implementations use the same server and communication code for Raspberry Pi and for \gls{WEMOS} sensor nodes (rows 5--7 of the table).
The Sensor Interface (SI) refers to code facilitating the communication between the peripherals and the sensor node software. % formerly hardware interface
Sensor Node (SN) code contains all other code on the sensor node that does not belong to any another category, such as control flow. % formerly device output
-%Server communication denotes code that provides the high level communication between the sensor node and the server.
Manage Nodes (MN) is code that coordinates sensor nodes, e.g.\ to add a new sensor node to the system. % formerly device management
Web Interface (WI) code provides the web interface from the server, i.e.\ the presentation layer.
Database Interface (DI) code communicates between the server and the database\strut(s).
Idiomatic \citask{} would use high level abstractions to store persistent data in \pgls{SDS}, requiring just a few \gls{SLOC}.
The total size of \gls{CWS} and \gls{CRS} would be reduced by a factor of two and the percentage of Database Interface code would be even less than in the tiered \gls{PYTHON} implementations.
-
\begin{figure}
\centering
\includegraphics[width=.7\linewidth]{bar_chart.pdf}
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.
+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 unmarshalling 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}).
\begin{lstPython}[caption={\Gls{JSON} Data marshalling in \gls{PRS} and \gls{PWS}: sensor node above, server below.},label={lst_t4t:json}]
\section{Could tierless \IOT{} programming be more reliable than tiered?}%
\label{sec_t4t:Discussion}
-
This section investigates whether tierless languages make \gls{IOT} programming more reliable. Arguably the much smaller and simpler code base is inherently more understandable, and more likely to be correct. Here we explore specific language issues, namely those of preserving type safety, maintainability, failure management, and community support.
\subsection{Type safety}%
\label{sec_t4t:typesafety}
Strong typing identifies errors early in the development cycle, and hence plays a crucial role in improving software quality. In consequence almost all modern languages provide strong typing, and encourage static typing to minimise runtime errors.
-% 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.\ \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
-%Phil: another possible source to discuss \citep{egyed1999automatically}
\begin{lstPython}[caption={\Gls{PRS} loses type safety as a sensor node sends a {\tt\footnotesize double}, and the server stores a {\tt\footnotesize string}.},label={lst_t4t:float},morekeywords={message,enum,uint64,double}]
message SensorData {
\Cref{table_t4t:languagecomparison} summarises the differences between the \gls{CLEAN} \gls{IOT} \gls{EDSL} and their host language.
The restrictions imposed by a resource-constrained execution environment on the tierless \gls{IOT} language are relatively minor. Moreover the \gls{MTASK} programming abstraction is broadly compatible with \gls{ITASK}. As a simple example compare the \gls{ITASK} and \gls{MTASK} temperature sensors in \cref{lst_t4t:itaskTempFull,lst_t4t:mtasktemp}. As a more realistic example, the \gls{MTASK} based \gls{CWS} smart campus implementation is similar to the \gls{ITASK} based \gls{CRS}, and requires less than 10\% additional code: 166 \gls{SLOC} compared with 155 \gls{SLOC} (\cref{table_t4t:multi}).
-Even with these restrictions, \gls{MTASK} programming is at a far higher level of abstraction than almost all bare metal languages, e.g.\ BIT, PICBIT, PICOBIT and Microscheme. That is \gls{MTASK} provides a set of higher order task combinators, shared distributed data stores, \etc. (\cref{sec_t4t:mtasks}). Moreover, it seems that common sensor node programs are readily expressed using \gls{MTASK}. In addition to the \gls{CWTS} and \gls{CWS} systems outlined here, other case studies include Arduino examples as well as some bigger tasks \citep{koopman_task-based_2018,lubbers_writing_2023,lubbers_multitasking_2019}. We conclude that the programming of sensor tasks is well-supported by both \glspl{DSL}.
+Even with these restrictions, \gls{MTASK} programming is at a far higher level of abstraction than almost all bare metal languages, e.g.\ BIT, PICBIT, PICOBIT and Microscheme. That is \gls{MTASK} provides a set of higher order task combinators, shared distributed data stores, \etc. (\cref{sec_t4t:mtasks}). Moreover, it seems that common sensor node programs are readily expressed using \gls{MTASK}. In addition to the \gls{CWTS} and \gls{CWS} systems outlined here, other case studies include \gls{ARDUINO} examples as well as some bigger tasks \citep{koopman_task-based_2018,lubbers_writing_2023,lubbers_multitasking_2019}. We conclude that the programming of sensor tasks is well-supported by both \glspl{DSL}.
\section{Conclusion}%
\label{sec_t4t:Conclusion}
\end{enumerate*}
We show that \emph{tierless languages have the potential to significantly improve the reliability of \gls{IOT} systems}. We illustrate how \gls{CLEAN} maintains type safety, contrasting this with a loss of type safety in \gls{PRS}.
-We illustrate higher order failure management in \cimtask{} in contrast to the \gls{PYTHON}-based failure management in \gls{PRS}. For maintainability a tiered approach makes replacing components easy, but refactoring within the components is far harder than in a tierless \gls{IOT} language. Again our findings are consistent with the simplied \textit{Code Maintenance} benefits claimed for tierless languages \citep{weisenburger2020survey}.
+We illustrate higher order failure management in \cimtask{} in contrast to the \gls{PYTHON}-based failure management in \gls{PRS}. For maintainability a tiered approach makes replacing components easy, but refactoring within the components is far harder than in a tierless \gls{IOT} language. Again our findings are consistent with the simplified \textit{Code Maintenance} benefits claimed for tierless languages \citep{weisenburger2020survey}.
Finally, we contrast community support for the technologies (\cref{sec_t4t:Discussion}).
We report \emph{the first comparison of a tierless \gls{IOT} codebase for resource-rich sensor nodes with one for resource-constrained sensor nodes}.
repositories / phd-thesis.git / blobdiff