LOCO: more on proposal part

1 files changed, 117 insertions, 44 deletions

diff --git a/papers/LOCO-24/contents.latex b/papers/LOCO-24/contents.latex
index 800c4d4..7253dc3 100644
--- a/papers/LOCO-24/contents.latex
+++ b/papers/LOCO-24/contents.latex
@@ -278,64 +278,122 @@ Computing}{December 05, 2024}{Glasgow, Scotland, United Kingdom }
 
 \section{Embracing the language}
 
-%% TODO: embracing the language means embracing the people
+  %% TODO: embracing the language means embracing the people
 
-From what we just discussed we can see most interesting things in Unix's ideas
-are dangerous from von Neumann to shared-resource concurrency and others are
-not comfortable for programmers, who prefer to use interpreted languages
-instead as the abstractions they provide are easier to deal with. But CPUs are
-optimized for the Unix case, instead of embracing the facilities the
-programmers prefer to use.
+  From what we just discussed we can see most interesting things in Unix's
+  ideas are dangerous from von Neumann to shared-resource concurrency and
+  others are not comfortable for programmers, who prefer to use interpreted
+  languages instead as the abstractions they provide are easier to deal with.
+  But CPUs are optimized for the Unix case, instead of embracing the facilities
+  the programmers prefer to use.
 
 \subsection{Personal computers}
 
-%% TODO: What's `personal` in personal computer? embrace the user-programmer
-%% TODO: make sure dates are right
+  %% TODO: is this part of the intro really?
+
+  %% TODO: What's `personal` in personal computer? embrace the user-programmer
+  %% TODO: make sure dates are right
+
+  Personal computers like those before the 90s were simple. A user could
+  maintain them and even manipulate the electronics. They often made a strong
+  bet for one language (ZX Spectrum / Apple II with BASIC), but the languages
+  had poor abstraction capabilities.
+
+  The introduction of larger RAM memories and more complex CPUs, made the
+  personal computing industry pivot towards Unix-based operating systems, as
+  they were proven to work in complex scenarios. This shift contributed to the
+  extinction of many \textit{simple} operating systems that flourished during
+  the previous era but facilitated the galloping increase personal computing
+  specs in the following years\cite{EvolutionComputing:Larus}.
+
+  %% TODO graphical user interfaces hid the programming part
+
+  Graphical User Interfaces, \textit{GUI}, became widespread in the early 1980s
+  and made computers accessible and useful to many
+  people\cite{EvolutionComputing:Larus} but at the expense of the access to
+  lower level capabilities, as \textit{protecting the user}, and the computing
+  literacy that traditional text-oriented usage encouraged.
+
+
+  Operating systems like Oberon \cite{Oberon:Wirth} blur the line between
+  \textit{GUI}s and programming, making them work together instead of hiding
+  the programming part of the system, while keeping a simple core in its design
+  that keeps the system maintainable, still making a strong bet for the
+  language (Oberon).
+
+  Our proposal is to recover the feeling of personal computers from the 80s,
+  but with the powerful abstraction capabilities we widely regard as
+  comfortable.
+
+  %% TODO: explain the GUI apparition and how before everyone was a vernacular
+  %% programmer and now it's not like that
+  %% TODO: if we want to improve the connection with the vernacular programmer,
+  %% we need to ask ourselves: what's a language? \cite{MythsPL:Shaw}
+
+  For \textit{vernacular programmers}, because they represent the vast majority
+  of programmers \cite{MythsPL:Shaw}: simplicity (few concepts), explorability
+  (repl), flexible, practical, also valid for professional programmers,
+  extendable, can represent other kind of goals like \textit{HDLs} and even
+  \textit{data} via DSLs.
+
+\subsection{The language}
+
+  If we want to embrace the language we need to choose a language to embrace.
+  We have to place a bet: but we are betting to the widest option we know that
+  is also \textit{practical}.
+
+  Scheme:
+  \begin{itemize}
+    \item It's abstract enough
+    \item Other languages can compile to it (Wisp)
+    \item Simple concepts but powerful abstractions
+    \item Minimal standard
+    \item Extensibility
+    \item Language oriented programming (Racket)
+    \item Proven experience with the lambda papers and lisp machines => abandoned,
+  but still living in Emacs.
+  \end{itemize}
 
-Personal computers like those before the late 90s were simple. A user could
-maintain them and even manipulate the electronics. The introduction of larger
-RAM memories and more complex CPUs, made the personal computing industry pivot
-towards Unix-based operating systems, as they were proven to work in complex
-scenarios. This shift contributed to the extinction of many \textit{simple}
-operating systems that flourished during the previous era but facilitated the
-galloping increase personal computing specs of the 90s and beginning of the
-2000s, doubling in performance every 2 years\cite{EvolutionComputing:Larus}.
+\subsection{Operating System}
 
-%% TODO graphical user interfaces hid the programming part
+  Unix based operating systems, have demonstrated to have several troublesome
+  concepts that are stuck in modern day programmers and users, but valid
+  alternatives had also been successfully proven in other areas of the
+  programming practice. Betting in a language enables applying those in the
+  operating system level.
 
-Graphical User Interfaces, \textit{GUI}, became widespread with the
-introduction of the Apple Macintosh computer in the early 1980s. This user
-interface change made computers accessible and useful to many more
-people\cite{EvolutionComputing:Larus} but at the expense of the access to lower
-level capabilities, as \textit{protecting the user}, and the computing literacy
-that traditional text-oriented usage encouraged.
+\subsubsection{The kernel-interpreter}
 
-%% TODO: explain the GUI apparition and how before everyone was a vernacular
-%% programmer and now it's not like that
-%% TODO: if we want to improve the connection with the vernacular programmer,
-%% we need to ask ourselves: what's a language? \cite{MythsPL:Shaw}
+  From the programming perspective, the \textit{kernel} and programming
+  language \textit{interpreters} act as hosts: they prepare an isolated
+  environment for the running program and manage resources for it via
+  system-calls vs function calls, while running what it is written in the
+  program body.
 
-For \textit{vernacular programmers}, because they represent the vast majority
-of programmers \cite{MythsPL:Shaw}: simplicity (few concepts), explorability
-(repl), flexible, practical, also valid for professional programmers,
-extendable, can represent other kind of goals like \textit{HDLs} and even
-\textit{data} via DSLs.
+  When a interpreter as a \textit{userspace} program, there are two layers of
+  interpretation. Engineering the kernel as an interpreter reduces its
+  complexity and allows for further specialization for the chosen language.
 
-Operating systems like Oberon \cite{Oberon:Wirth} blur the line between
-\textit{GUI}s and programming, making them work together instead of hiding the
-programming part of the system, while keeping a simple core in its design that
-keeps the system maintainable.
+\paragraph{Managed memory}
+  Virtual memory is an attempt to isolate programs from each other but it is a
+  leaky abstraction that can be exploited. Removing direct access to memory,
+  replacing it with managed memory, removes the need of virtual memory.
 
+\paragraph{No threads/processes but tasks}
+  Unix-style parallelism, reinforced by modern \textit{multi-core} CPU design,
+  focuses on the implementation rather than the usage. Browser-like task design
+  based on Coroutines/Generators/Asynchronous calls.
 
-\subsection{Operating System}
-\subsubsection{No kernel/interpreter separation}
-\subsubsection{No threads/processes but tasks}
-\subsubsection{No virtual memory}
-\subsubsection{Capability based security "lambda-style"}
+\paragraph{Capability based security "lambda-style"}
   Reduces the amount of permission issues inherited from von Neumann style and
-  Unix.
+  Unix. No user support.
+
+\subsubsection{Filesystem}
+
+  This allows for new paradigms in Filesystem design.
+
+\subsection{CPU designed for the kernel-interpreter}
 
-\subsection{CPU}
 \subsubsection{Optimization for tree structures}
 \subsubsection{Hardware garbage collection}
 \subsubsection{Extendable CPU}
@@ -343,6 +401,21 @@ keeps the system maintainable.
   \cite{riscvSelfHostingComputer:Somlo}
 
 
+\section{Conclusion}
+
+  The usage of commodity hardware like FPGAs and the reduction of needs from
+  the CPU by eliminating the Kernel and some of the associated complexity could
+  reduce the environmental (\textit{shipping}, waste associated with
+  \textit{periodic upgrades}) and human cost (\textit{security},
+  \textit{awareness}) of personal computers.
+
+  Extending the reach of the language enriches the relationship the user has
+  with the computer. If the selected language is powerful in terms of the level
+  of abstraction it can provide, it could become the only tool a user needs for
+  every single administration task, including hardware upgrade or optimization.
+
+  Embracing the language is embracing the person in charge of the computer.
+
 %% The acknowledgments section is defined using the "acks" environment
 %% (and NOT an unnumbered section). This ensures the proper
 %% identification of the section in the article metadata, and the