\input{subfileprefix}
\chapter{Coda}%
\label{chp:conclusion}
-\section{Conclusion}
-
-\section{Future work}
-
-\section{Related work}
-This section describes the related work.
-The novelties of the \gls{MTASK} system can be compared to existing systems in several categories.
-It is a tierless (\cref{sec:related_tierless}), interpreted (\cref{sec:related_int}) \gls{TOP} (\cref{sec:related_top}) \gls{DSL} (\cref{sec:related_dsl}) that may seem similar at first glance to \gls{FRP} (\cref{sec:related_frp}), it is implemented in a functional language (\cref{sec:related_fp}) and due to the execution semantics, multitasking is automatically supported (\cref{sec:related_multi}).
-\todo{uit\-brei\-den waar mo\-ge\-lijk}
-
-\subsection{Interpretation}\label{sec:related_int}
-There are a myriad of interpreted programming languages available for some of the bigger devices.
-For example, for the popular ESP8266 chip there are ports of \gls{MICROPYTHON}, LUA, Basic, JavaScript and Lisp.
-All of these languages, except the Lisp dialect uLisp (see \cref{ssec:related_fp}), are imperative and do not support multithreading out of the box.
-They lay pretty hefty constraints on the memory and as a result do not work on smaller microcontrollers.
-A interpretation solution for the tiniest devices is Firmata, a protocol for remotely controlling the microcontroller and using a server as the interpreter host \citep{steiner_firmata:_2009}.
-\citet{grebe_haskino:_2016} wrapped this in a remote monad for integration with \gls{HASKELL} that allowed imperative code to be interpreted on the microprocessors.
-Later this system was extended to support multithreading as well, stepping away from Firmata as the basis and using their own \gls{RTS} \citep{grebe_threading_2019}.
-It differs from our approach because continuation points need to be defined by hand there is no automatic safe data communication.
-
-\subsubsection{\texorpdfstring{\Glsxtrlongpl{DSL}}{DSLs} for microcontrollers}\label{sec:related_dsl}
-Many \glspl{DSL} provide higher-level programming abstractions for microcontrollers, for example providing strong typing or 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{}.
-
-\subsection{\texorpdfstring{\Glsxtrlong{FP}}{Functional programming}}\label{sec:related_fp}
-\Citet{haenisch_case_2016} showed that there are major benefits to using functional languages for \gls{IOT} applications.
-They showed that using function languages increased the security and maintainability of the applications.
-Traditional implementations of general purpose functional languages have high memory requirements rendering them unusable for tiny computers.
-There have been many efforts to create a general purpose functional language that does fit in small memory environments, albeit with some concessions.
-For example, there has been a history of creating tiny Scheme implementations for specific microcontrollers.
-It started with BIT \citep{dube_bit:_2000} that only required \qty{64}{\kibi\byte} of memory, followed by {PICBIT} \citep{feeley_picbit:_2003} and {PICOBIT} \citep{st-amour_picobit:_2009} that lowered the memory requirements even more.
-More recently, \citep{suchocki_microscheme:_2015} created Microscheme, a functional language targeting \gls{ARDUINO} compatible microcontrollers.
-The {*BIT} languages all compile to assembly while Microscheme compiles to \gls{CPP}, heavily supported by \gls{CPP} lambdas available even on \gls{ARDUINO} AVR targets.
-An interpreted Lisp implementation called uLisp also exists that runs on microcontrollers with as small as the \gls{ARDUINO} {UNO} \citep{johnson-davies_lisp_2020}.
-
-\subsection{\texorpdfstring{\Glsxtrlong{FRP}}{Functional reactive programming}}\label{sec:related_frp}
-The \gls{TOP} paradigm is often compared to \gls{FRP} and while they appear to be similar---they both process events---, in fact they are very different.
-\Gls{FRP} was introduced by \citet{elliott_functional_1997}.
-The paradigm strives to make modelling systems safer, more efficient, composable.
-The core concepts are behaviours and events.
-A behaviour is a value that varies over time.
-Events are happenings in the real world and can trigger behaviours.
-Events and behaviours may be combined using combinators.
-\Gls{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}.
-
-The way \gls{FRP}, and for that matter \gls{TOP}, systems are programmed stays close to the design when the domain matches suits the paradigm.
-The \gls{IOT} domain seems to suit this style of programming very well in just the device layer\footnote{While a bit out of scope, it deserves mention that for \gls{SN}, \gls{FRP} and stream based approaches are popular as well \citep{sugihara_programming_2008}.} but also for entire \gls{IOT} systems.
-
-For example, Potato is an \gls{FRP} language for building entire \gls{IOT} systems using powerful devices such as the Raspberry Pi leveraging the Erlang \gls{VM} \citep{troyer_building_2018}.
-It requires client devices to be able to run the Erlang \gls{VM} which makes it unsuitable for low memory environments.
-
-The emfrp language compiles a \gls{FRP} specification for a microcontroller to \gls{C} code \citep{sawada_emfrp:_2016}.
-The \gls{IO} part, the bodies of some functions, still need to be implemented.
-These \gls{IO} functions can then be used as signals and combined as in any \gls{FRP} language.
-Due to the compilation to \gls{C} it is possible to run emfrp programs on tiny computers.
-However, the tasks are not interpreted and there is no communication with a server.
-
-Other examples are 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}, Haski \citep{valliappan_towards_2020}, arduino-copilot~\cite{hess_arduino-copilot_2020}.
-
-\subsection{\texorpdfstring{\Glsxtrlong{TOP}}{Task-oriented programming}}\label{sec:related_top}
-\Gls{TOP} as a paradigm with has been proven to be effective for implementing distributed, multi-user applications in many domains.
-Examples are conference management \citep{plasmeijer_conference_2006}, coastal protection \citep{lijnse_capturing_2011}, incident coordination \citep{lijnse_incidone:_2012}, crisis management \citep{jansen_towards_2010} and telemedicine \citep{van_der_heijden_managing_2011}.
-In general, \gls{TOP} results in a higher maintainability, a high separation of concerns and more effective handling of interruptions of workflow.
-\Gls{IOT} applications contain a distributed and multi-user component, but the software on the device is mostly follows multiple loosely dependent workflows.
-The only other \gls{TOP} language for embedded systems is $\mu$Tasks \citep{piers_task-oriented_2016}.
-It is a non-distributed \gls{TOP} \gls{EDSL} hosted in \gls{HASKELL} designed for embedded systems such as payment terminals.
-They showed that applications tend to be able to cope well with interruptions and be more maintainable.
-However, the hardware requirements for running the standard \gls{HASKELL} system are high.
-
-\subsection{Multi tasking}\label{sec:related_multi}
-
-\subsection{Tierless programming on microcontrollers}\label{sec:related_tierless}
+\begin{chapterabstract}
+ This chapter concludes the dissertation and reflects on the work.
+\end{chapterabstract}
+\section{Reflections}
+Programming \gls{IOT} systems is classically complex.\todo{chap\-ter\-ab\-stract weg?}
+Traditionally, on each layer of the system, different computers, hardware architectures, programming languages, programming paradigms, and abstraction levels are required.
+All these factiors generating a lot of semantic friction.
+Furthermore, \gls{IOT} systems are very convoluted because they are dynamic, multi-tiered, multi-user, multitasking, interactive, distributed, and collaborative.
+\Gls{TOP} has shown to provide a suitable programming paradigm that allows the declarative specification of exactly such systems.
+However, edge devices are often too computationally restricted to be able to run traditional \gls{TOP} systems.
+This thesis sheds light on orchestrating complete \gls{IOT} system using \gls{TOP}, specifically filling in the knowledge gap for edge devices in three episodes.
+
+\Cref{prt:dsl} presented two novel techniques for embedding \glspl{DSL} in \gls{FP} languages.
+The novel classy deep embedding technique allows extension of a deeply embedded \gls{DSL} both in language constructs and in language interpretations.
+Furthermore, by using the structural information available at compile time, a lot of the boilerplate required to develop an interoperating \gls{IOT} system can be automatically and hence safely generated.
+
+\Cref{prt:top} gave an overview of the \gls{MTASK} system, it's design, integration with \gls{ITASK}, implementation, and green computing facilities.
+It shows that when the \gls{DSL} is carefully designed, and domain-specific knowledge is embedded in the execution platform, it is possible to create a language that offers the same abstraction level as \gls{ITASK} provides on the server.
+Using advanced \gls{DSL} embedding technique, a \gls{TOP} \gls{DSL} for the \gls{IOT} edge devices can be created that allows programming the small microcomputers according to the same high abstraction level as on the server.
+The \gls{MTASK} \gls{DSL} is set up in such a way that it is possible to create high-level \gls{TOP} programs performing common \gls{IOT} edge devices work dynamically and send them to the edge device at run time.
+
+\Cref{prt:tvt} qualitatively and quantitatively compared traditional \gls{IOT} system programming, tiered programming, to the tierless programming.
+We have shown that programming such complex systems using a tierless approach such as using \gls{MTASK} or even \gls{ITASK} reduces the development effort required to making these systems.
+Concretely, it results in fewer \gls{SLOC}, files, programming languages and programming paradigms.
+
+However, it is not a silver bullet.
+Tierless languages are novel, and hence lacking tooling and community support.
+They contain many high-level tierless abstractions that the programmer has to master.
+The low-level specific semantics of the final application may become more difficult to destill from the specification.
+Finally, the system is quite monolithic.
+Changing a components within the system is easy if it already exists in the host language.
+Adding new components to the system requires the programmer to add it to all complex components of the languages such as the compiler, and \gls{RTS}.
\input{subfilepostamble}
\end{document}
repositories / phd-thesis.git / blobdiff