coda/coda.tex

   1 \documentclass[../thesis.tex]{subfiles}
   2
   3 \input{subfilepreamble}
   4
   5 \setcounter{chapter}{10}
   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 The term \gls{IOT} refers to the interconnected network of physical devices that are connected to each other and the internet.
  19 The edge, or perception, layer of an \gls{IOT} system is often powered by microcontrollers.
  20 These small and cheap computers do not have powerful hardware but are energy efficient and support many sensors and actuators.
  21 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.
  22 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.
  23 This generates a lot of semantic friction.\todo[inline]{benoem ook de andere problemen. Geen over all type check om correcte samenwerking te garanderen.}
  24 Furthermore, \gls{IOT} systems become convoluted because they are dynamic, multi-tiered, multi-user, multitasking, interactive, distributed, and collaborative in nature.
  25 \Gls{TOP} proves a suitable programming paradigm that allows the declarative specification of exactly such systems.
  26 However, edge devices are often too computationally restricted to be able to run a full-fledged \gls{TOP} system such as \gls{ITASK}.
  27 The dissertation is structured as a purely functional rhapsody in three episodes.
  28
  29 In order to get \gls{TOP} to resource-constrained edge devices we use special tools: \glspl{DSL}.
  30 The dissertation shows several techniques for creating \glspl{EDSL} in \cref{prt:dsl}.
  31 Then it shows a tool, \gls{MTASK}, a \gls{TOP} system for \gls{IOT} edge devices in \cref{prt:top}.
  32 Finally, in \cref{prt:tvt} it compares how this approach compares to existing approaches for programming \gls{IOT} systems.
  33
  34 \subsection{\nameref{prt:dsl}}
  35 \Cref{prt:dsl} presents some tool crafting techniques 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
  38 Classy deep embedding is a novel \gls{EDSL} embedding technique.
  39 When embedding \glspl{DSL}, one always has to make concessions.
  40 It is either easy to add language constructs, or to add interpretations of the terms, but never both.
  41 Some advanced embedding techniques found ways of mitigate this issue.
  42 Tagless-final embedding offers a way of extending a shallowly embedded \gls{DSL} both in constructs and interpretations.
  43 Classy deep embedding is the organically grown counterpart for deep embedding a \gls{DSL}.
  44 It allows orthogonal extension of language constructs and interpretations with minimal boilerplate and no advanced type system extensions.
  45
  46 When embedding a \gls{DSL} in a language, much, but not all, of the machinery is inherited.
  47 An example of this are host-language data types.
  48 They are not automatically useable in the \gls{DSL} because the interfaces such as constructors, deconstructors, constructor predicates, and pattern matching are not inherited.
  49 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}.
  50 The scaffolding is generated using template metaprogramming and quasiquotation is used to alleviate the programmer from the syntax burden and support pattern matching.
  51
  52 \todo[inline]{Paar zinnen over het nut van deze tool crafts: het maakt het voor DSL-developpers in het algemeen makkelijker om uitbreidbare DSLs te maken.}
  53
  54 \subsection{\nameref{prt:top}}
  55 General-purpose \gls{TOP} systems cannot run on edge devices due to their significant hardware requirements.
  56 However, with the right techniques, \glspl{DSL} can be created that can be executed on edge devices while maintaining the high abstraction level.
  57 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.
  58
  59 \Cref{prt:top} contains a complete overview of such a tool: the \gls{MTASK} system.
  60 The \gls{MTASK} language is a unique domain-specific \gls{TOP} \gls{EDSL} designed system for edge devices.
  61 The \gls{MTASK} system is fully integrated with the \gls{ITASK} system, a \gls{TOP} system for programming distributed web applications.
  62 In the \gls{ITASK} system, there are abstractions for details such as user interfaces, data storage, client-side platforms, and persistent workflows.
  63 The \gls{MTASK} language abstracts away from edge device specific details such as sensor and actuator access, heterogeneity in hardware, and multitasking and scheduling.
  64 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.
  65 This tight integration makes programming full \gls{IOT} systems using \gls{TOP} possible without major compromises.
  66 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.
  67 Its design, integration with \gls{ITASK}, implementation, and green computing facilities are shown.
  68
  69 \todo[inline]{Paar zinnen over het nut}
  70
  71 \subsection{\nameref{prt:tvt}}
  72 Using tierless programming, many issues that arise with tiered programming are mitigated.
  73 This has already been observed in web applications.
  74 The \gls{MTASK} system show that it is possible to program edge devices of a \gls{IOT} systems using \gls{TOP}.
  75 Furthermore, when used together with \gls{ITASK}, entire \gls{IOT} systems can be programmed tierlessly.
  76 Whether this novel approach to programming tiered systems also reduces the \gls{IOT} develop grief is answered in \cref{prt:tvt}.
  77 This episode presents a four-way qualitative and quantitative comparison of the following systems:
  78 \gls{PRS}, a tiered system based on resource-rich edge devices powered by \gls{PYTHON};
  79 \gls{PWS}, a tiered system based on resource-constrained edge devices by \gls{MICROPYTHON};
  80 \gls{CRS}, a tierless system based on resource-rich edge devices powered by \gls{ITASK};
  81 \gls{CWS}, a tierless system based on resource-constrained edge devices powered by \gls{MTASK}.
  82
  83 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.
  84 On the other hand, using a tierless system compared to a tiered system reduces the developer grief significantly.
  85
  86 Every layer of the entire \gls{IOT} system is specified in a single source, the same strong type system, and similar high abstraction level.
  87 The tierless approach results in fewer \gls{SLOC}, files, programming languages and programming paradigms.
  88 All code is simultaneously checked by a single compiler, reducing interoperability problems.
  89 Furthermore, all communication and integration is automatically generated, reducing interoperability issues even more.
  90
  91 However, it is not a silver bullet, there are some disadvantages as well.
  92 Tierless languages are novel, and hence often lack tooling and community support.
  93 They contain high-level tierless abstractions that the programmer has to master.
  94 The low-level specific semantics of the final application may become more difficult to distill from the specification.
  95 Finally, the system is more monolithic compared to tiered approaches.
  96 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}.
  97
  98 \input{subfilepostamble}
  99 \end{document}