\chapter{Finale}%
\label{chp:finale}
\begin{chapterabstract}
- \noindent This chapter wraps up the monograph by means of:
+ This chapter wraps up the monograph by means of:
\begin{itemize}
\item a conclusion;
\item an outlook on future work;
\end{chapterabstract}
\section{Finale}
-Traditionally, \gls{IOT} have been programmed using layered architectures.
+Traditionally, \gls{IOT} has been programmed using layered, or tiered, architectures.
Every layer has its own software and hardware characteristics, resulting in semantic friction.
-\Gls{TOP} is a declarative programming paradigm designed for specifying multi-tiered interactive systems.
+\Gls{TOP} is a declarative programming paradigm designed to describe multi-tiered interactive systems.
However, it is not straightforward to run \gls{TOP} systems on resource-constrained devices such as edge devices.
The \gls{MTASK} system bridges this gap by providing a \gls{TOP} programming language for edge devices.
-It is a full-fledged \gls{TOP} language hosted in a tiny functional programming language containing basic tasks, task combinators, support for sensors and actuators, and interrupts.
-It is integrated seamlessly in \gls{ITASK}, a \gls{TOP} system for interactive web applications.
+It is a full-fledged \gls{TOP} language hosted in a tiny \gls{FP} language.
+Besides the usual \gls{FP} constructs, it contains basic tasks, task combinators, support for sensors and actuators, and interrupts.
+It integrates seamlessly in \gls{ITASK}, a \gls{TOP} system for interactive web applications.
Hence, all layers of an \gls{IOT} system can be programmed from a single declarative specification.
-\Gls{ITASK} abstracts away from the gritty details of interactive web applications such as program distribution, web applications, data storage, and user management.
-The engine of \gls{MTASK} abstracts away of all technicalities such as communication, abstractions for sensors and actuators, interrupts and (multi) task scheduling.
-
-Devices are connected to the \gls{ITASK} system at run time using a single function that takes care of all the communication and error handling.
-When connected to a device, tasks written in the \gls{MTASK} \gls{DSL} can be lifted to \gls{ITASK} tasks.
-The tasks are specified and compiled at run time, i.e.\ \gls{CLEAN} can be used as a macro language for constructing \gls{MTASK} tasks, tailor making them for the work that needs to be done.
+In \gls{ITASK}, abstraction are available for the gritty details of interactive web applications such as program distribution, web applications, data storage, and user management.
+The engine of \gls{MTASK} abstracts away of all technicalities specific to edge devices such as communication, abstractions for sensors and actuators, interrupts and (multi) task scheduling.
+
+Any device equipped with the \gls{MTASK} \gls{RTS} can be used in the system and dynamically receive tasks for execution.
+This domain-specific \gls{OS} only needs to be programmed once, hence saving precious write cycles on the program memory.
+The \gls{MTASK} devices are connected to the \gls{ITASK} system at run time using a single function that takes care of all the communication and error handling.
+Once connected to a device, tasks written in the \gls{MTASK} \gls{DSL} can be lifted to \gls{ITASK} tasks.
+The tasks are specified and compiled at run time, i.e.\ \gls{CLEAN} can be used as a macro language for constructing \gls{MTASK} tasks, tailor making them for the current work requirements.
When lifted, other tasks in the system can interact with the task through the usual means.
-Furthermore, \gls{ITASK} \glspl{SDS} can be \emph{lowered} to \gls{MTASK} tasks as well, allowing for bidirectional automatic data sharing between \gls{MTASK} tasks and the \gls{ITASK} system.
-The \gls{MTASK} device is equipped with a domain-specific \gls{OS} that only needs to be programmed once after which the device can continuously receive new tasks.
-\todo[inline]{Uitbreiden}
+Furthermore, \gls{ITASK} \glspl{SDS} can be \emph{lowered} to \gls{MTASK} tasks as well, allowing for bidirectional automatic data sharing between \gls{MTASK} tasks and the \gls{ITASK} system irrespective of task relations.
+\todo{Uit\-brei\-den?}
\section{Future work}
\todo[inline]{De grens tussen future en related work is soms vaag maar ik heb het zo goed als mogelijk proberen te scheiden. Mis ik hier nog iets?}
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.
-\Citep{suchocki_microscheme:_2015} created Microscheme, a functional language targeting \gls{ARDUINO} compatible microcontrollers.
+\Citet{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}.
}\label{tbl:multithreadingcompare}
% \begin{tabular}{lc>{\columncolor[gray]{0.95}}cc>{\columncolor[gray]{0.95}}cc>{\columncolor[gray]{0.95}}cc}
\begingroup
+ % default is 6pt
\setlength\tabcolsep{4.5pt}
\begin{tabular}{lccccccc}
\toprule
However, this version used a simplified version of \gls{MTASK} without functions.
This was later improved upon by creating a simplified interface where \glspl{SDS} from \gls{ITASK} could be used in \gls{MTASK} and the other way around \citep{lubbers_task_2018}.
It was shown by \citet{amazonas_cabral_de_andrade_developing_2018} that it was possible to build real-life \gls{IOT} systems with this integration.
-Moreover, a course on the \gls{MTASK} simulator was provided at the 2018 \gls{CEFP}\slash\gls{3COWS} winter school in Ko\v{s}ice, Slovakia \citep{koopman_simulation_2018}.
+Moreover, a course on the \gls{MTASK} simulator was provided at the 2018 \gls{CEFP}\slash\gls{3COWS} winter school in Ko\v{s}ice, Slovakia \citep{koopman_simulation_2023}.
\subsection{Transition to \texorpdfstring{\glsxtrlong{TOP}}{Task-oriented programming}}
The \gls{MTASK} language as it is now was introduced in 2018 \citep{koopman_task-based_2018}.
Later the byte code compiler and \gls{ITASK} integration was added to the language \citep{lubbers_interpreting_2019}.
Moreover, it was shown that it is very intuitive to write microcontroller applications in a \gls{TOP} language \citep{lubbers_multitasking_2019}.
One reason for this is that a lot of design patterns that are difficult using standard means are for free in \gls{TOP} (e.g.\ multithreading).
-In 2019, the \gls{CEFP}\slash\gls{3COWS} summer school in Budapest, Hungary hosted a course on developing \gls{IOT} applications with \gls{MTASK} as well \citep{lubbers_writing_2019}.
+In 2019, the \gls{CEFP}\slash\gls{3COWS} summer school in Budapest, Hungary hosted a course on developing \gls{IOT} applications with \gls{MTASK} as well \citep{lubbers_writing_2023}.
\subsection{\texorpdfstring{\Glsxtrlong{TOP}}{Task-oriented programming}}
In 2022, the SusTrainable summer school in Rijeka, Croatia hosted a course on developing greener \gls{IOT} applications using \gls{MTASK} as well \citep{lubbers_green_2022}.
repositories / phd-thesis.git / blobdiff