\begin{document}
\input{subfileprefix}
-\chapter{Could tierless languages reduce IoT development grief?}%
+\chapter{Tiered versus tierless programming}%
\label{chp:smart_campus}
\begin{chapterabstract}
\begin{enumerate*}
\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 To ensure correctness the developer must maintain type safety across a range of very different languages and diverse type systems.\todo[inline]{what do you mean by type safety here precisely? how can that happend if non type safe languages are in the mix}
\item The developer must deal with the potentially diverse failure modes of each component, and of component interoperation.
\end{enumerate*}
sensor nodes (i.e.\ Raspberry Pis) and low-cost, low-precision sensors
for indoor environmental monitoring.
-We have deployed sensor nodes into 12 rooms in two buildings. The \gls{IOT} system has an online data store, providing live
+Sensor nodes have been deployed into 12 rooms in two buildings. The \gls{IOT} system has an online data store, providing live
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
\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.
+\todo{again, here it would be good to have a general definition of tierless, and then describe what the possible design choices are, and where in the space iTask/mTask fits}
\subsubsection{Tier splitting and placement}
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.
+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.
+As a 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}.
\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}.
-Of course \gls{SLOC} must be used carefully as it is easily influenced by programming style, language paradigm, and counting method \citep{alpernaswonderful}. Here we are counting code to compare development effort, use the same idiomatic programming style in each component, and only count lines of code, omitting comments and blank lines.
+Of course \gls{SLOC} must be used carefully as it is easily influenced by programming style, language paradigm, and counting method \citep{alpernaswonderful}. Here we are counting lines of code to compare development effort, use the same idiomatic programming style in each component, and only count lines of code, omitting comments and blank lines.
\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
repositories / phd-thesis.git / blobdiff