X-Git-Url: https://git.martlubbers.net/?a=blobdiff_plain;f=concl%2Fconcl.tex;h=17a7828d218d5d62be88c089410b0a224cd09b4c;hb=c1b9a0995445470a66854861c04df440b7d7ffb3;hp=bc5cccf4aabaaa58ce29f453bd29f0f98ee9c295;hpb=61948f6acce6b49f4612f0c32c3e8728e899628c;p=phd-thesis.git diff --git a/concl/concl.tex b/concl/concl.tex index bc5cccf..17a7828 100644 --- a/concl/concl.tex +++ b/concl/concl.tex @@ -2,82 +2,93 @@ \input{subfilepreamble} +\setcounter{chapter}{9} + \begin{document} \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} +\label{chp:conclusion}% +\ifSubfilesClassLoaded{\glsunsetall}{}% +\begin{chapterabstract} + This chapter concludes the dissertation and reflects on the work. +\end{chapterabstract} +\section{Reflections} + +This dissertation shed light on orchestrating complete \gls{IOT} systems using \gls{TOP}. + +The term \gls{IOT} refers to the interconnected network of physical devices that are connected to each other and the internet. +The edge, or perception, layer of an \gls{IOT} systems is often powered by microcontrollers. +These small and cheap computers do not have powerful hardware but are energy efficient and support many sensors and actuators. +While the term \gls{IOT} has already been known for almost thirty years, only recently, the exponential growth of the number of \gls{IOT} edge devices is really ramping up. +Programming \gls{IOT} systems is very complex because each layer of the system is built with different computers, hardware architectures, programming languages, programming paradigms, and abstraction levels. +This generates a lot of semantic friction. +Furthermore, \gls{IOT} systems become convoluted because they are dynamic, multi-tiered, multi-user, multitasking, interactive, distributed, and collaborative. +\Gls{TOP} proves 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 a full-fledged \gls{TOP} system such as \gls{ITASK}. + +The dissertation is structured as a purely functional rhapsody in three episodes. +It shows different techniques that aid crafting the tools required, i.e.\ creating the programming languages. +Then it shows the tool, \gls{MTASK}, a \gls{TOP} system for \gls{IOT} edge devices. +Finally it compares how this tool compares to existing tools. + +\subsection{Tool craft} +First some techniques for tool crafting are presented in \cref{prt:dsl} that are useful for creating \gls{TOP} languages for \gls{IOT} edge devices. +It presents two novel techniques for embedding \glspl{DSL} in \gls{FP} languages: +Classy deep embedding is a novel \gls{EDSL} embedding technique. +In \gls{DSL} embedding techniques, one always has to make concessions. +Either it is easy to extend the language in language constructs or in interpretations but never both. +Tagless-final embedding offers a way of extending a shallowly embedded \gls{DSL} both in constructs and interpretations. +Classy deep embedding is the organically grown counterpart for deep embedding a \gls{DSL}. +It allows orthogonal extension of language constructs and interpretations with minimal boilerplate and no advanced type system extensions. + +When embedding a \gls{DSL} in a language, much, but not all, of the machinery is inherited +For example, data types are not automatically useable in the \gls{DSL} because the interfaces such as constructors, deconstructors and constructor predicates are not inherited. +I show how to automatically generate boilerplate for \glspl{DSL} in order to make data types first-class citizens in the \gls{DSL}. +The scaffolding is generated using template metaprogramming and quasiquotation is used to alleviate the programmer from the syntax burden. + +\subsection{Tools} +General-purpose \gls{TOP} systems cannot run on edge devices due to their sizeable hardware requirements. +However, using advanced \gls{DSL} embedding techniques, \glspl{DSL} can be created that can be executed on edge devices while maintaining the high abstraction level. +By embedding domain-specific knowledge into the language and execution platform, and leaving out general-purpose functionality \gls{TOP} languages can be made suitable for edge devices. + +\Cref{prt:top} contains a complete overview of such a tool: the \gls{MTASK} system. +Its design, integration with \gls{ITASK}, implementation, and green computing facilities are shown. +The \gls{MTASK} language is a unique domain-specific \gls{TOP} \gls{EDSL} designed system for edge devices. +The \gls{MTASK} system is fully integrated with the \gls{ITASK} system, a \gls{TOP} system for programming distributed web applications. +In the \gls{ITASK} system, there are abstractions for details such as user interfaces, data storage, client-side platforms, and persistent workflows. +The \gls{MTASK} language abstracts away from edge device specific details such as sensor and actuator access, heterogeneity in hardware, and multitasking and scheduling. +Tasks in the \gls{MTASK} system are compiled at run time and sent to the device dynamically in order to support create dynamic systems where tasks are tailor-made for the current work requirements. +This tight integration makes programming full \gls{IOT} systems using \gls{TOP} possible without major compromises. +Using only three simple functions, devices are connected to \gls{ITASK} servers, \gls{MTASK} tasks are integrated in \gls{ITASK}, and \gls{ITASK} \glspl{SDS} accessed from within \gls{MTASK} tasks. + +\subsection{Comparison} +Previous episodes show that it is possible to program all layers of an \gls{IOT} systems using \gls{TOP}. +Using tierless programming, many issues that arise with tiered programming are mitigated. +This has already been observed in web applications. +The question whether this novel approach to programming tiered systems also reduces the develop grief is answered in \cref{prt:tvt}. +This episode presents a four-way qualitatively and quantitatively comparison of the following systems: +\begin{enumerate*} + \item \gls{PRS}, a tiered system based on resource-rich edge devices powered by \gls{PYTHON}; + \item \gls{PWS}, a tiered system based on resource-constrained edge devices by \gls{MICROPYTHON}; + \item \gls{CRS}, a tierless system based on resource-rich edge devices powered by \gls{ITASK}; + \item \gls{CWS}, a tierless system based on resource-constrained edge devices powered by \imtask{}. +\end{enumerate*} + +This comparison shows that when using a programming paradigm that is available both for resource-rich and resource-constrained edge devices, there is little difference in developer grief. +On the other hand, using a tierless system compared to a tiered system reduces the developer grief significantly. + +Using either \imtask{} when dealing with resource-constrained devices such as microcontrollers or just \gls{ITASK} for all layers all layers of the entire \gls{IOT} system are specified in a single source, the same strong type system, and similar high abstraction level. +The tierless approach results in fewer \gls{SLOC}, files, programming languages and programming paradigms. +All code is simultaneously checked by a single compiler, reducing interoperability problems. +Furthermore, all communication and integration is automatically generated, reducing interoperability issues even more. +% +However, it is not a silver bullet, there are some disadvantages as well. +Tierless languages are novel, and hence often lack tooling and community support. +They contain high-level tierless abstractions that the programmer has to master. +The low-level specific semantics of the final application may become more difficult to distill from the specification. +Finally, the system is more monolithic compared to tiered approaches. +Changing components within the system is easy if it already is supported in the \gls{EDSL}. +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}