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

diff --git a/concl/concl.tex b/concl/concl.tex
index 57a0cd0..c454398 100644
--- a/concl/concl.tex
+++ b/concl/concl.tex
@@ -2,11 +2,64 @@
 
 \input{subfilepreamble}
 
+\setcounter{chapter}{9}
+
 \begin{document}
 \input{subfileprefix}
 \chapter{Coda}%
-\label{chp:conclusion}
-\section{Reflection}
+\label{chp:conclusion}%
+\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 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 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.
+
+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.
+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.
+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.
+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?}
+
+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.
+
+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}.
 
 \input{subfilepostamble}
 \end{document}