\begin{document}
\input{subfileprefix}
-\chapter{Could tierless languages reduce IoT development grief?}%
+\chapter{Tiered versus tierless programming}%
\label{chp:smart_campus}
\begin{chapterabstract}
- \Gls{IOT} software is notoriously complex, conventionally comprising multiple tiers.
- Traditionally an \gls{IOT} developer must use multiple programming languages and ensure that the components interoperate correctly. A novel alternative is to use a single \emph{tierless} language with a compiler that generates the code for each component and ensures their correct interoperation.
+ \Gls{IOT} software is notoriously complex, usually comprising multiple tiers.
+ Traditionally an \gls{IOT} developer must use multiple programming languages and ensure that the components interoperate correctly.
+ A novel alternative is to use a single \emph{tierless} language with a compiler that generates the code for each component and their correct interoperation.
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.
\section{Introduction}%
\label{sec_t4t:Intro}
-Conventional \gls{IOT} software stacks are notoriously complex and pose very significant software development, reliability, and maintenance challenges. \Gls{IOT} software architectures typically comprise multiple components organised in four or more tiers or layers \citep{sethi2017internet,Ravulavaru18,Alphonsa20}. This is due to the highly distributed nature of typical \gls{IOT} applications that must read sensor data from end points (the \emph{perception} layer), aggregate and select the data and communicate over a network (the \emph{network} layer), store the data in a database and analyse it (the \emph{application} layer) and display views of the data, commonly on web pages (the \emph{presentation} layer).
+Conventional \gls{IOT} software stacks are notoriously complex and pose very significant software development, reliability, and maintenance challenges. \Gls{IOT} software architectures typically comprise multiple components organised in four or more tiers or layers \citep{sethi2017internet,ravulavaru18,alphonsa20}. This is due to the highly distributed nature of typical \gls{IOT} applications that must read sensor data from end points (the \emph{perception} layer), aggregate and select the data and communicate over a network (the \emph{network} layer), store the data in a database and analyse it (the \emph{application} layer) and display views of the data, commonly on web pages (the \emph{presentation} layer).
Conventional \gls{IOT} software architectures require the development of separate programs in various programming languages for each of the components\slash{}tiers in the stack. This is modular, but a significant burden for developers, and some key challenges are as follows.
\begin{enumerate*}
\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}.
+A radical alternative development paradigm uses a single \emph{tierless} language that synthesises 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}.
In a tierless language the developer writes the application as a single program. The code for different tiers is simultaneously checked by the compiler, and compiled to the required component languages. For example, Links compiles to HTML and JavaScript for the web client and to SQL on the server to interact with the database system. Tierless languages for \gls{IOT} stacks are more recent and less common, examples include
-Potato \citep{troyer_building_2018} and \gls{CLEAN} with \imtask{} \citep{lubbers_interpreting_2019}.
+Potato \citep{troyer_building_2018}, and \gls{CLEAN} with \imtask{} \citep{lubbers_interpreting_2019}.
-\Gls{IOT} sensor nodes may be microcontrollers with very limited compute resources, or supersensors: resource-rich single board computers like a Raspberry Pi. A tierless language may target either class of sensor node, and microcontrollers are the more demanding target due to the limited resources, e.g.\ small memory, executing on bare metal \etc.
+\Gls{IOT} sensor nodes may be microcontrollers with very limited compute resources, or supersensors: resource-rich single board computers like a Raspberry Pi. A tierless language may target either class of sensor node, and microcontrollers are the more demanding target due to the limited resources, e.g.\ small memory, executing on bare metal, \etc.
Potentially a tierless language both reduces the development effort and improves correctness as correct interoperation and communication is automatically generated by the compiler. A tierless language may, however, introduce other problems. How expressive is the language? That is, can it readily express the required functionality? How maintainable is the software? Is the generated code efficient in terms of time, space, and power?
-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}.
+This chapter 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}.\label{enum:c1}
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
\end{description}
-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.
+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 chapter.
\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 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}).
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.
-
\subsubsection{Tier splitting and placement}
A key challenge for a tierless language is to determine which parts of the program correspond to a particular tier and hence should be executed by a specific component on a specific host.
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}.
\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.
+To make this chapter 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}.
+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_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.
+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{Task-oriented programming}
Task combinators compose tasks into more advanced tasks, either in parallel or sequential and allow task values to be observed by other tasks.
As tasks can be returned as the result of a function, recursion can be freely used, e.g.\ to express the repetition of tasks.
There are also standard combinators for common patterns.
-Tasks can exchange information via \glspl{SDS} \citep{ParametricLenses}.
+Tasks can exchange information via \glspl{SDS} \citep{parametriclenses}.
All tasks involved can atomically observe and change the value of a typed \gls{SDS}, allowing more flexible communication than with task combinators.
\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 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.
+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 \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}.
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.
+\newpage%
\begin{lstClean}[%
numbers=left,
mainTask :: Task Real
mainTask
- = withDevice deviceInfo \dev -> liftmTask} devTask dev[+\label{lst_t4t:mtasktemp:liftmtask}+][+\label{lst_t4t:mtasktemp:withdevice}+][+\label{lst_t4t:mtasktemp:co2}\srcmark{CO}+]
+ = withDevice deviceInfo \dev -> liftmTask devTask dev[+\label{lst_t4t:mtasktemp:liftmtask}+][+\label{lst_t4t:mtasktemp:withdevice}+][+\label{lst_t4t:mtasktemp:co2}\srcmark{CO}+]
-|| viewSharedInformation [] latestTemp[+\label{lst_t4t:mtasktemp:wi1}\srcmark{WI}+]
<<@ Title "Latest temperature"[+\label{lst_t4t:mtasktemp:wi2}\srcmark{WI}+]
\end{lstClean}
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.
\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}.
-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.
+As the tierless languages synthesise the code to be executed on the sensor nodes, we need to confirm that the generated code is sufficiently memory efficient.
\begin{table}
\centering
\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
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}\todo{make gray\-sca\-le}).
+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}).
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.
+Indeed, approaches like CircuitPython \citep{circuitpython} allow the same code to execute on both resource-rich and resource-constrained sensor nodes.
Like \gls{PYTHON} and \gls{MICROPYTHON}, \gls{ITASK} and \gls{MTASK} are designed to be similar, as elaborated in \cref{sec_t4t:ComparingTierless}. The similarity is apparent when comparing the \gls{ITASK} \gls{CRTS} and \cimtask{} \gls{CWTS} room temperature systems in \cref{lst_t4t:itaskTempFull,lst_t4t:mtasktemp}. That is, both implementations use similar \glspl{SDS} and lenses; they have similar \cleaninline{devTask}s that execute on the sensor node, and the server-side \cleaninline{mainTask}s are almost identical: they deploy the remote \cleaninline{devTask} before generating the web page to report the readings.
\midrule
Code Location & Functionality & \gls{PYTHON} & \gls{CLEAN}\\
\midrule
- Sensor Node & Sensor Int. & imperative & declarative\\
- & Sensor Node & imperative & declarative\\
+ Sensor Node & Sensor Interface & Imperative & Declarative\\
+ & Sensor Node & Imperative & Declarative\\
\midrule
- Server & Manage Nodes & imperative & declarative\\
- & Web Int. & both & declarative\\
- & Database Int. & both & declarative\\
+ Server & Manage Nodes & Imperative & Declarative\\
+ & Web Interface & Both & Declarative\\
+ & Database Interface & Both & Declarative\\
\midrule
- Communication & Communication & imperative & declarative\\
+ Communication & Communication & Imperative & Declarative\\
\midrule
& Total & 2 & 1 \\
\bottomrule
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}]
-
channel = 'sensor_status.%s.%s' % (hostname,
sensor_types.sensor_type_name(s.sensor_type))
self.r.publish(channel, s.SerializeToString())
Another reason that the tierless \gls{CLEAN} implementations are concise is because they use powerful higher order \gls{IOT} programming abstractions.
For comprehensibility the simple temperature sensor from \cref{sec_t4t:mtasks} (\cref{lst_t4t:mtasktemp}) is used to compare the expressive power of \gls{CLEAN} and \gls{PYTHON}-based \gls{IOT} programming abstractions.
-There are implementations for all four configurations: \gls{PRTS} (\gls{PYTHON} Raspberry Pi Temperature Sensor)\footnotemark, \gls{PWTS}\footnotemark[\value{footnote}],
+There are implementations for all four configurations: \gls{PRTS}\footnotemark, \gls{PWTS}\footnotemark[\value{footnote}],
\footnotetext{Lubbers, M.; Koopman, P.; Ramsingh, A.; Singer, J.; Trinder, P. (2021): Source code, line counts and memory stats for PRS, PWS, PRT and PWT.\ Zenodo.\ \href{https://doi.org/10.5281/zenodo.5081386}{10.5281/zenodo.5081386}.} \gls{CRTS}\footnotemark{} and \gls{CWTS}\footnotemark[\value{footnote}].
\footnotetext{Lubbers, M.; Koopman, P.; Ramsingh, A.; Singer, J.; Trinder, P. (2021): Source code, line counts and memory stats for CRS, CWS, CRTS and CWTS.\ Zenodo.\ \href{https://doi.org/10.5281/zenodo.5040754}{10.5281/zenodo.5040754}.}
but as the programming abstractions are broadly similar, we compare only the \gls{PWTS} and \gls{CWTS} implementations.
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}.
+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}.
\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 {
failover [] _ = throw "Exhausted device pool"
failover [d:ds] mtask = try (withDevice d (liftmTask mtask)) except
where except MTEUnexpectedDisconnect = failover ds mtask
- except _ = throw e
+ except e = throw e
\end{lstClean}
In the \gls{UOG} smart campus application, this can be done by creating a pool of sensor nodes for each room and when a sensor node fails, assign another one to the task.
\label{sec_t4t:support}
Community and tool support are essential for engineering reliable production software. \Gls{PRS} and \gls{PWS} are both \gls{PYTHON} based, and \gls{PYTHON}\slash\gls{MICROPYTHON} are among the most popular programming languages \citep{cass2020top}. \Gls{PYTHON} is also a common choice for some tiers of \gls{IOT} applications \citep{tanganelli2015coapthon}.
Hence, there are a wide range of development tools like \glspl{IDE} and debuggers, a thriving community and a wealth of training material. There are even specialised \gls{IOT} Boards like PyBoard \& WiPy that are specifically programmed using \gls{PYTHON} variations like \gls{MICROPYTHON}.
+\pagebreak
In contrast, tierless languages are far less mature than the languages used in tiered stacks, and far less widely adopted.
This means that for \gls{CWS} and \gls{CRS} there are fewer tools, a far smaller developer community, and less training material available.
\begin{table}
\small
- \caption{Comparing tierless \gls{IOT} languages for resource-rich sensor nodes (\gls{ITASK} \gls{EDSL}), for resource-constrained sensor nodes (\gls{MTASK} \gls{EDSL}), and their \gls{CLEAN} host language.}%
+ \caption{Comparing tierless \gls{IOT} \glspl{DSL} for resource-rich sensor nodes (\gls{ITASK}), for resource-constrained sensor nodes (\gls{MTASK}), and their \gls{CLEAN} host language.}%
\label{table_t4t:languagecomparison}
\begin{tabular}{llll}
\toprule
User-defined datatypes & Yes & Yes & No \\
Task oriented & No & Yes & Yes \\
Higher-order tasks & {--} & Yes & No \\
- Execution Target & Commodity PC & Commodity PC & microcontroller\\
- & & and Browser & microcontroller\\
+ Execution Target & Commodity PC & Commodity PC & Microcontroller\\
+ & & and browser & Microcontroller\\
Language Implementation & Compiled or & Compiled and & Interpreted\\
- & interpreted & interpreted & Interpreted\\
+ & interpreted & interpreted & \\
\bottomrule
\end{tabular}
\end{table}
\subsection{Future work}
-This paper is a technology comparison between tiered and tierless technologies. The metrics reported, such as code size, numbers of source code files, and of paradigms are only indirect, although widely accepted, measures of development effort. A more convincing evaluation of tierless technologies could be provided by conducting a carefully designed and substantial user study, e.g.\ using N-version programming.
+This chapter is a technology comparison between tiered and tierless technologies. The metrics reported, such as code size, numbers of source code files, and of paradigms are only indirect, although widely accepted, measures of development effort. A more convincing evaluation of tierless technologies could be provided by conducting a carefully designed and substantial user study, e.g.\ using N-version programming.
A study that implemented common benchmarks or a case study in multiple tierless \gls{IOT} languages would provide additional evidence for the generality of the tierless approach. Such a study would enable the demonstration and comparison of alternative design decisions within tierless languages, as outlined in \cref{sec_t4t:characteristics}.
repositories / phd-thesis.git / blobdiff