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 \todo[inline]{chap\-ter\-ab\-stract weg?}
  16 The term \gls{IOT} has already been known for almost thirty years.
  17 Only recently, the exponential growth of the number of \gls{IOT} edge devices is really ramping up.
  18 Programming layered systems such as \gls{IOT} systems is very complex.
  19 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.
  20 This generates a lot of semantic friction.
  21 Furthermore, \gls{IOT} systems become convoluted because they are dynamic, multi-tiered, multi-user, multitasking, interactive, distributed, and collaborative.
  22 \Gls{TOP} proves a suitable programming paradigm that allows the declarative specification of exactly such systems.
  23 However, edge devices are often too computationally restricted to be able to run a full-fledged \gls{TOP} system such as \gls{ITASK}.
  24 This thesis sheds light on how to orchestrate complete \gls{IOT} systems using \gls{TOP}.
  25 It specifically fills in the knowledge gap for edge devices.
  26 The contributions are split up into three episodes.
  27
  28 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.
  29 In \gls{DSL} embedding techniques, one always has to make concessions.
  30 Either it is easy to extend the language in language constructs or in interpretations but never both.
  31 Tagless-final embedding offers a way of extending a shallowly embedded \gls{DSL} both in constructs and interpretations.
  32 Classy deep embedding is the organically grown counterpart for deep embedding a \gls{DSL}.
  33 It allows orthogonal extension of language constructs and interpretations with minimal boilerplate and no advanced type system extensions.
  34 Furthermore, when embedding a \gls{DSL} in a language, much of the machinery is inherited.
  35 However, data types are not automatically useable in the \gls{DSL} because the interfaces such as constructors, deconstructors and constructortests are not inherited.
  36 I show how to automatically generate boilerplate for \glspl{DSL} in order to make data types first-class citizens in the \gls{DSL}.
  37 The scaffolding is generated using template metaprogramming and quasiquotation is used to alleviate the programmer from the syntax burden.
  38
  39 \Cref{prt:top} contains a complete overview of the \gls{MTASK} system: its design, integration with \gls{ITASK}, implementation, and green computing facilities.
  40 The \gls{MTASK} language is a unique domain-specific \gls{TOP} \gls{EDSL} designed system for edge devices.
  41 The \gls{MTASK} system is fully integrated with the \gls{ITASK} system, a \gls{TOP} system for programming distributed web applications.
  42 In the \gls{ITASK} system, there are abstractions for details such as user interfaces, data storage, client-side platforms, and persistent workflows.
  43 The \gls{MTASK} language abstracts away from edge device specific details such as sensor and actuator access, heterogeneity in hardware, and multitasking and scheduling.
  44 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.
  45 This tight integration makes programming full \gls{IOT} systems using \gls{TOP} possible without major compromises.
  46 All layers of the entire \gls{IOT} system are specified in a single source, the same strong type system, and similar high abstraction level.
  47 Therefore, they are simultaneously checked by a single compiler, reducing interoperability problems.
  48 Furthermore, all communication and integration is automatically generated, reducing the interoperability even more.
  49 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.
  50 \todo[inline]{benoem geïntroduceerde semantische wrijving? Het feit dat mTask strikter is?}
  51
  52 In \Cref{prt:tvt}, traditional \gls{IOT} system programming, tiered programming, is qualitatively and quantitatively compared to tierless programming.
  53 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.
  54 Concretely, it results in fewer \gls{SLOC}, files, programming languages and programming paradigms.
  55
  56 However, it is not a silver bullet.
  57 However, it has some disadvantages as well.
  58 Tierless languages are novel, and hence lacking tooling and community support.
  59 They contain many high-level tierless abstractions that the programmer has to master.
  60 The low-level specific semantics of the final application may become more difficult to destill from the specification.
  61 Finally, the system is quite monolithic.
  62 Changing components within the system is easy if it already is supported in the \gls{EDSL}.
  63 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}.
  64
  65 \input{subfilepostamble}
  66 \end{document}