17a7828d218d5d62be88c089410b0a224cd09b4c
[phd-thesis.git] / concl / concl.tex
1 \documentclass[../thesis.tex]{subfiles}
2
3 \input{subfilepreamble}
4
5 \setcounter{chapter}{9}
6
7 \begin{document}
8 \input{subfileprefix}
9 \chapter{Coda}%
10 \label{chp:conclusion}%
11 \ifSubfilesClassLoaded{\glsunsetall}{}%
12 \begin{chapterabstract}
13 This chapter concludes the dissertation and reflects on the work.
14 \end{chapterabstract}
15 \section{Reflections}
16
17 This dissertation shed light on orchestrating complete \gls{IOT} systems using \gls{TOP}.
18
19 The term \gls{IOT} refers to the interconnected network of physical devices that are connected to each other and the internet.
20 The edge, or perception, layer of an \gls{IOT} systems is often powered by microcontrollers.
21 These small and cheap computers do not have powerful hardware but are energy efficient and support many sensors and actuators.
22 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.
23 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.
24 This generates a lot of semantic friction.
25 Furthermore, \gls{IOT} systems become convoluted because they are dynamic, multi-tiered, multi-user, multitasking, interactive, distributed, and collaborative.
26 \Gls{TOP} proves a suitable programming paradigm that allows the declarative specification of exactly such systems.
27 However, edge devices are often too computationally restricted to be able to run a full-fledged \gls{TOP} system such as \gls{ITASK}.
28
29 The dissertation is structured as a purely functional rhapsody in three episodes.
30 It shows different techniques that aid crafting the tools required, i.e.\ creating the programming languages.
31 Then it shows the tool, \gls{MTASK}, a \gls{TOP} system for \gls{IOT} edge devices.
32 Finally it compares how this tool compares to existing tools.
33
34 \subsection{Tool craft}
35 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.
36 It presents two novel techniques for embedding \glspl{DSL} in \gls{FP} languages:
37 Classy deep embedding is a novel \gls{EDSL} embedding technique.
38 In \gls{DSL} embedding techniques, one always has to make concessions.
39 Either it is easy to extend the language in language constructs or in interpretations but never both.
40 Tagless-final embedding offers a way of extending a shallowly embedded \gls{DSL} both in constructs and interpretations.
41 Classy deep embedding is the organically grown counterpart for deep embedding a \gls{DSL}.
42 It allows orthogonal extension of language constructs and interpretations with minimal boilerplate and no advanced type system extensions.
43
44 When embedding a \gls{DSL} in a language, much, but not all, of the machinery is inherited
45 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.
46 I show how to automatically generate boilerplate for \glspl{DSL} in order to make data types first-class citizens in the \gls{DSL}.
47 The scaffolding is generated using template metaprogramming and quasiquotation is used to alleviate the programmer from the syntax burden.
48
49 \subsection{Tools}
50 General-purpose \gls{TOP} systems cannot run on edge devices due to their sizeable hardware requirements.
51 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.
52 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.
53
54 \Cref{prt:top} contains a complete overview of such a tool: the \gls{MTASK} system.
55 Its design, integration with \gls{ITASK}, implementation, and green computing facilities are shown.
56 The \gls{MTASK} language is a unique domain-specific \gls{TOP} \gls{EDSL} designed system for edge devices.
57 The \gls{MTASK} system is fully integrated with the \gls{ITASK} system, a \gls{TOP} system for programming distributed web applications.
58 In the \gls{ITASK} system, there are abstractions for details such as user interfaces, data storage, client-side platforms, and persistent workflows.
59 The \gls{MTASK} language abstracts away from edge device specific details such as sensor and actuator access, heterogeneity in hardware, and multitasking and scheduling.
60 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.
61 This tight integration makes programming full \gls{IOT} systems using \gls{TOP} possible without major compromises.
62 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.
63
64 \subsection{Comparison}
65 Previous episodes show that it is possible to program all layers of an \gls{IOT} systems using \gls{TOP}.
66 Using tierless programming, many issues that arise with tiered programming are mitigated.
67 This has already been observed in web applications.
68 The question whether this novel approach to programming tiered systems also reduces the develop grief is answered in \cref{prt:tvt}.
69 This episode presents a four-way qualitatively and quantitatively comparison of the following systems:
70 \begin{enumerate*}
71 \item \gls{PRS}, a tiered system based on resource-rich edge devices powered by \gls{PYTHON};
72 \item \gls{PWS}, a tiered system based on resource-constrained edge devices by \gls{MICROPYTHON};
73 \item \gls{CRS}, a tierless system based on resource-rich edge devices powered by \gls{ITASK};
74 \item \gls{CWS}, a tierless system based on resource-constrained edge devices powered by \imtask{}.
75 \end{enumerate*}
76
77 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.
78 On the other hand, using a tierless system compared to a tiered system reduces the developer grief significantly.
79
80 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.
81 The tierless approach results in fewer \gls{SLOC}, files, programming languages and programming paradigms.
82 All code is simultaneously checked by a single compiler, reducing interoperability problems.
83 Furthermore, all communication and integration is automatically generated, reducing interoperability issues even more.
84 %
85 However, it is not a silver bullet, there are some disadvantages as well.
86 Tierless languages are novel, and hence often lack tooling and community support.
87 They contain high-level tierless abstractions that the programmer has to master.
88 The low-level specific semantics of the final application may become more difficult to distill from the specification.
89 Finally, the system is more monolithic compared to tiered approaches.
90 Changing components within the system is easy if it already is supported in the \gls{EDSL}.
91 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}.
92
93 \input{subfilepostamble}
94 \end{document}