X-Git-Url: https://git.martlubbers.net/?a=blobdiff_plain;f=concl%2Fconcl.tex;h=b2ce8e5719ac3048f6fb719b95ba2a2d46b1d500;hb=7af43f4cbbc7792ec22553a84468cde77f429a11;hp=c4543980e31cf66fde64770dcf3b4ab146fd5f66;hpb=5a27c37e8d41687aae6fc84e92c7d630880618bf;p=phd-thesis.git

diff --git a/concl/concl.tex b/concl/concl.tex
index c454398..b2ce8e5 100644
--- a/concl/concl.tex
+++ b/concl/concl.tex
@@ -8,58 +8,88 @@
 \input{subfileprefix}
 \chapter{Coda}%
 \label{chp:conclusion}%
+\ifSubfilesClassLoaded{\glsunsetall}{}%
 \begin{chapterabstract}
 	This chapter concludes the dissertation and reflects on the work.
 \end{chapterabstract}
 \section{Reflections}
-\todo[inline]{chap\-ter\-ab\-stract weg?}
-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 layered systems such as \gls{IOT} systems is very complex.
-The complexity mainly arises from the fact that each layer of the system is built up using different computers, hardware architectures, programming languages, programming paradigms, and abstraction levels.
+
+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} system 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.
+Furthermore, \gls{IOT} systems become convoluted because they are dynamic, multi-tiered, multi-user, multitasking, interactive, distributed, and collaborative in nature.
 \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 traditional \gls{TOP} systems.
-This thesis sheds light on how to orchestrate complete \gls{IOT} systems using \gls{TOP}.
-It specifically fills in the knowledge gap for edge devices.
-The contributions are split up into three episodes.
+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.
+
+In order to get \gls{TOP} to resource-constraind edge devices we use special tools: \glspl{DSL}.
+The dissertation shows several techniques for creating \glspl{EDSL}.
+Then it shows a tool, \gls{MTASK}, a \gls{TOP} system for \gls{IOT} edge devices.
+Finally it compares how this approach compares to existing approaches for programming \gls{IOT} systems.
 
-In \cref{prt:dsl}, two novel techniques for embedding \glspl{DSL} in \gls{FP} languages are presented: the classy deep \gls{EDSL} embedding technique and a way of generating boilerplate for data types using template metaprogramming.
-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.
+\subsection{Tool craft}
+\Cref{prt:dsl} presents some tool crafting techniques 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.
+When embedding \glspl{DSL}, one always has to make concessions.
+It is either easy to add language constructs, or to add interpretations of the terms, but never both.
+Some advanced embedding techniques found ways of mitigate this issue.
 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.
-Furthermore, when embedding a \gls{DSL} in a language, much of the machinery is inherited.
-However, data types are not automatically useable in the \gls{DSL} because the interfaces such as constructors, deconstructors and constructortests 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.
 
-\Cref{prt:top} contains a complete overview of the \gls{MTASK} system: its design, integration with \gls{ITASK}, implementation, and green computing facilities.
+When embedding a \gls{DSL} in a language, much, but not all, of the machinery is inherited.
+An example of this are host-language data types.
+They are not automatically useable in the \gls{DSL} because the interfaces such as constructors, deconstructors, constructor predicates, and pattern matching are not inherited.
+I show how to automatically generate the required boilerplate for shallowly embedded \glspl{DSL} in order to make data types from the host language 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 and support pattern matching.
+
+\subsection{Tools}
+General-purpose \gls{TOP} systems cannot run on edge devices due to their significant hardware requirements.
+However, with the right 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.
 The \gls{MTASK} language is a unique domain-specific \gls{TOP} \gls{EDSL} designed system for edge devices.
-The system is fully integrated with the \gls{ITASK} system, a \gls{TOP} system for programming distributed web applications.
+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.
-All layers of the entire \gls{IOT} system are specified in a single source, the same strong type system, and similar high abstraction level.
-Therefore, they are simultaneously checked by a single compiler, reducing interoperability problems.
-Furthermore, all communication and integration is automatically generated, reducing the interoperability even more.
 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.
-\todo[inline]{benoem geïntroduceerde semantische wrijving? Het feit dat mTask strikter is?}
+Its design, integration with \gls{ITASK}, implementation, and green computing facilities are shown.
+
+\subsection{Comparison}
+Using tierless programming, many issues that arise with tiered programming are mitigated.
+This has already been observed in web applications.
+The \gls{MTASK} system show that it is possible to program edge devices of a \gls{IOT} systems using \gls{TOP}.
+Furthermore, when used together with \gls{ITASK}, entire \gls{IOT} systems can be programmed tierlessly.
+The question whether this novel approach to programming tiered systems also reduces the \gls{IOT} develop grief is answered in \cref{prt:tvt}.
+This episode presents a four-way qualitative and quantitative comparison of the following systems:
+\gls{PRS}, a tiered system based on resource-rich edge devices powered by \gls{PYTHON};
+\gls{PWS}, a tiered system based on resource-constrained edge devices by \gls{MICROPYTHON};
+\gls{CRS}, a tierless system based on resource-rich edge devices powered by \gls{ITASK};
+\gls{CWS}, a tierless system based on resource-constrained edge devices powered by \gls{MTASK}.
+
+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.
 
-In \Cref{prt:tvt}, traditional \gls{IOT} system programming, tiered programming, is qualitatively and quantitatively compared to tierless programming.
-The comparison demonstrates 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.
+Every layer of the entire \gls{IOT} system is 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.
-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 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}.
+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}, but 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}