enrich intro even more

diff --git a/intro.intro.tex b/intro.intro.tex
index fd7f265..6d264e9 100644 (file)
--- a/intro.intro.tex
+++ b/intro.intro.tex
@@ -41,11 +41,11 @@ example, this layer would be the app that can be used to monitor the
 electricity consumption. These tools on the application layer can again be
 created into a wide variety of programming languages and different paradigms.
 
-The separation of \gls{IoT} in layers is one of the causes of an integration
-problem in \gls{IoT}. The different layers are built with different paradigms,
-programming languages and different architectures which is difficult to
-connect. Rolling out updates is also complicated since reprogramming
-microcontrollers in the field is very expensive.
+The separation of \gls{IoT} in layers is a difficulty when developing \gls{IoT}
+applications. All layers use different paradigms, languages and architecture.
+Rolling out changes to the system is also complicated since reprogramming
+microcontrollers in the field is very expensive. Even the simple repurposing of
+a device requires often a full reprogram.
 
 \subsection{Task Oriented Programming}
 The \gls{TOP} paradigm and the corresponding \gls{iTasks} implementation offer

diff --git a/intro.related.tex b/intro.related.tex
index 69f2166..de306e5 100644 (file)
--- a/intro.related.tex
+++ b/intro.related.tex
@@ -25,7 +25,7 @@ for and \gls{Clean} and \gls{Haskell} which compile the respective code to
 \gls{SAPL}~\cite{domoszlai_compiling_2012}. The \gls{SAPL} language is still a
 functional language and therefore requires big stacks and heaps to operate and
 is therefore not directly suitable for devices with little RAM such as the
-\gls{Arduino} Uno which only boasts $2K$ of RAM. It might be possible to
+\gls{Arduino}~Uno which only boasts $2K$ of RAM. It might be possible to
 compile the \gls{SAPL} code into efficient machine language or \gls{C} but then
 the system would lose its dynamic properties since the microcontroller then
 would have to be reprogrammed every time a new \gls{Task} is sent to the
@@ -55,3 +55,13 @@ functions. There is no intermediate \gls{AST}. Moreover, \gls{Ivory} generates
 static programs and thus it is necessary to reprogram the devices when they
 need to be repurposed. It would be interesting to explore the possibilities of
 writing the client software in an \gls{EDSL} as well.
+
+Not all \gls{IoT} devices run solely compiled code. The popular \emph{ESP8266}
+powered \textsc{NodeMCU} is able to run interpreted \gls{LUA} code. Moreover,
+there is a variation on \gls{Python} called \emph{micropython} that is suitable
+for running on microcontrollers. However, the overhead of the interpreter for
+such rich languages often results into limitations on the program size. It
+would not be possible to repurpose a device with \gls{IoT} because implementing
+this extensibility in the interpreted language leaves no room for the actual
+programs. Also, some devices only have $2K$ of ram, which is not enough for
+this.

diff --git a/todo.txt b/todo.txt
deleted file mode 100644 (file)
index 59754de..0000000
--- a/todo.txt
+++ /dev/null
@@ -1,2 +0,0 @@
-intro: Problem statement en introductie uitwijden
-concl: Uitleggen hoe/of de probleemstelling opgelost is