2e7038e4ce54363bc23f03e9aeec2da2934c3ff4
[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 \begin{chapterabstract}
12 This chapter concludes the dissertation and reflects on the work.
13 \end{chapterabstract}
14 \section{Reflections}
15 While the term \gls{IOT} has already been known for almost thirty years, the exponential growth of the number of \gls{IOT} edge devices is really ramping up recently.
16 \todo{chap\-ter\-ab\-stract weg?}
17 Programming layered systems such as \gls{IOT} systems is very complex because on each layer of the system, different computers, hardware architectures, programming languages, programming paradigms, and abstraction levels are required.
18 This generates a lot of semantic friction.
19 Furthermore, \gls{IOT} systems are very convoluted because they are dynamic, multi-tiered, multi-user, multitasking, interactive, distributed, and collaborative.
20 \Gls{TOP} proves a suitable programming paradigm that allows the declarative specification of exactly such systems.
21 However, edge devices are often too computationally restricted to be able to run traditional \gls{TOP} systems.
22 This thesis shed light on orchestrating complete \gls{IOT} system using \gls{TOP}, specifically filling in the knowledge gap for edge devices in three episodes.
23
24 \Cref{prt:dsl} presented two novel techniques for embedding \glspl{DSL} in \gls{FP} languages: the classy deep \gls{EDSL} embedding technique and a way of generating boilerplate for data types using template metaprogramming.
25 In \gls{DSL} embedding techniques, one always has to make concessions.
26 Either it is easy to extend the language in language constructs or in interpretations but never both.
27 Tagless-final embedding offers a way of extending a shallowly embedded \gls{DSL} both in constructs and interpretations.
28 Classy deep embedding is the organically grown counterpart for deep embedding a \gls{DSL}.
29 It allows orthogonal extension of language constructs and interpretations with minimal boilerplate and no advanced type system extensions.
30 Furthermore, when embedding a \gls{DSL} in a language, much of the machinery can be inherited.
31 However, data types are not automatically useable in the \gls{DSL} because the interfaces such as constructors, deconstructors and constructortests are not inherited.
32 I show how to automatically generate boilerplate for \glspl{DSL} in order to make data types first-class citizens in the \gls{DSL}.
33 The scaffolding is generated using template metaprogramming and quasiquotation is used to alleviate the programmer from the syntax burden.
34
35 \Cref{prt:top} gave an overview of the \gls{MTASK} system, it's design, integration with \gls{ITASK}, implementation, and green computing facilities.
36 Using advanced \gls{DSL} embedding technique, a \gls{TOP} \gls{DSL} for the \gls{IOT} edge devices can be created that allows programming the small microcomputers according to the same high abstraction level as on the server.
37 The \gls{MTASK} system is a \gls{TOP} system for edge devices.
38 It is fully integrated with \gls{ITASK} and hence allows the programmer to specify all layers of an \gls{IOT} system in a single specification.
39 The \gls{MTASK} \gls{DSL} is set up in such a way that it is possible to create high-level \gls{TOP} programs performing common \gls{IOT} edge devices work dynamically and send them to the edge device at run time.
40
41 \Cref{prt:tvt} qualitatively and quantitatively compared traditional \gls{IOT} system programming, tiered programming, to the tierless programming.
42 We have shown 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.
43 Concretely, it results in fewer \gls{SLOC}, files, programming languages and programming paradigms.
44
45 However, it is not a silver bullet.
46 Tierless languages are novel, and hence lacking tooling and community support.
47 They contain many high-level tierless abstractions that the programmer has to master.
48 The low-level specific semantics of the final application may become more difficult to destill from the specification.
49 Finally, the system is quite monolithic.
50 Changing a components within the system is easy if it already exists in the host language.
51 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}.
52
53 \input{subfilepostamble}
54 \end{document}