From 9e0f8888cd74bc3394833d7d0a8b8261ac4f0c74 Mon Sep 17 00:00:00 2001
From: Ekaitz Zarraga <ekaitz@elenq.tech>
Date: Thu, 29 Aug 2024 13:30:46 +0200
Subject: LOCO: lay out the Proposal further

---
 papers/LOCO-24/contents.latex | 240 +++++++++++++++++++++++++++---------------
 1 file changed, 154 insertions(+), 86 deletions(-)

(limited to 'papers/LOCO-24/contents.latex')

diff --git a/papers/LOCO-24/contents.latex b/papers/LOCO-24/contents.latex
index 7253dc3..9a59dd3 100644
--- a/papers/LOCO-24/contents.latex
+++ b/papers/LOCO-24/contents.latex
@@ -80,6 +80,8 @@ Computing}{December 05, 2024}{Glasgow, Scotland, United Kingdom }
 %% the next command will enable that style.
 %%\citestyle{acmauthoryear}
 
+%% Easy way to write code inline
+\newcommand{\code}{\texttt}
 
 %% end of the preamble, start of the body of the document source.
 \begin{document}
@@ -278,92 +280,136 @@ Computing}{December 05, 2024}{Glasgow, Scotland, United Kingdom }
 
 \section{Embracing the language}
 
-  %% 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.
+  If a computing system aims to embrace the language, it needs to make a proper
+  analysis of what a programming language is and how people make use of the
+  programming facilities that computing systems provide. Focusing on providing
+  facilities for \textit{vernacular programmers}\cite{MythsPL:Shaw} shapes a
+  good compromise between available technical literacy from the user side and a
+  wide audience to benefit.
+
+%  %% 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.
 
 \subsection{Personal computers}
 
-  %% 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.
+%% TODO: do this the other way around!!! (to make it shorter)
+% Before the Unix model won, personal computers were mainstream: they were
+% simple and so on. We think those computers had the base where we can build
+% computers that embrace the language and the person
+  Before the Unix model flooded the personal computer market, computers were
+  simple devices designed to be operated by a single person, each brand
+  marketed their own \textit{ad-hoc} operating system and most of them had a
+  vehicular language. Computer users were familiarized with the system and were
+  able to manipulate it down to the electronics, creating a large generation of
+  computer enthusiasts that still lasts today.
+
+  The introduction of Graphical User Interfaces, \textit{GUI}, widened the
+  spectrum of users \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 usage encouraged.
+
+  Treating the users as adults (not protecting them from themselves), like
+  early personal computers did, and providing them the adequate interface for
+  exploration happens to be a extremely powerful way to explore optimization
+  and simplification of computing systems \cite{Oberon:Wirth}.
+
+%  %% 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}
+  The \textit{Lisp} family of languages have proven to be flexible and powerful
+  (Lisp Machines and currently Emacs) and \textit{Scheme} has a long history of
+  research in language and CPU design (lambda papers).
+
+  \textit{Scheme} is a simple language, with a minimal standard, but that
+  enables a huge level of abstraction thanks to its minimal but powerful core
+  concepts which are also present in mainstream programming languages today
+  (Python, JavaScript) reducing the friction with seasoned programmers.
+
+  The nature of the Lisp family of languages also makes them suitable as file
+  formats (sxml) for storage and configuration files, writing DSLs (language
+  oriented programming), or extending the language (GOOPS, WISP) to the users'
+  needs (Typed Racket, Kawa).
+
+%  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: srfi-119) (srfi-110 for the
+%    difficulty of reading)
+%    \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.
+%    \item Typed Racket / Kawa / ...
+%  \end{itemize}
+
+  
 
 \subsection{Operating System}
 
-  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.
+%  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.
 
 \subsubsection{The kernel-interpreter}
-
   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
@@ -374,31 +420,51 @@ Computing}{December 05, 2024}{Glasgow, Scotland, United Kingdom }
   interpretation. Engineering the kernel as an interpreter reduces its
   complexity and allows for further specialization for the chosen language.
 
-\paragraph{Managed memory}
+\subsubsection{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.
+  leaky abstraction that can be exploited\cite{SpectreMeltdown:HillMasters}.
+  Removing direct access to memory, replacing it with managed memory, removes
+  the need of virtual memory.
 
-\paragraph{No threads/processes but tasks}
+\subsubsection{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.
 
-\paragraph{Capability based security "lambda-style"}
+\subsubsection{Capability based security "lambda-style"}
   Reduces the amount of permission issues inherited from von Neumann style and
-  Unix. No user support.
+  Unix. No \textit{user} support.
 
 \subsubsection{Filesystem}
-
   This allows for new paradigms in Filesystem design.
 
-\subsection{CPU designed for the kernel-interpreter}
+
+\subsection{Hardware for the kernel-interpreter}
+
+  Once the language is chosen and the structure of the kernel is well-defined,
+  many optimizations can be applied to the underlying hardware, the same way it
+  is done nowadays.
 
 \subsubsection{Optimization for tree structures}
+  \textit{Scheme} is based (not only that, the language itself is a list) in
+  the \textit{cons cell}, similar to a \textit{linked-list} node, and the data
+  structures that can be created from it (\textit{lists} and \textit{trees}).
+  Optimizing the CPU for that case, with fast lookups and \code{car} and
+  \code{cdr} operations hugely impacts in its performance.
+
 \subsubsection{Hardware garbage collection}
-\subsubsection{Extendable CPU}
+  When the whole system uses managed memory, the Garbage Collection,
+  \textit{GC}, can be pushed down in the stack. Oberon's GC is in the kernel,
+  but we could push it down to the hardware.
 
-  \cite{riscvSelfHostingComputer:Somlo}
+\subsubsection{Extendable CPU}
+  In order to test all those options, we could work in a FPGA, even using a HDL
+  written in \textit{Scheme}. The FPGAs are more power hungry and not as fast
+  as ASICs but the reduction of complexity proposed in this paper should be
+  enough for personal computing. Also, letting the user configure the CPU from
+  the computer itself reduces the need for constant upgrades, uses commodity
+  hardware instead of very specialized devices and reduces the chance of a
+  supply chain attack in many levels \cite{riscvSelfHostingComputer:Somlo}.
 
 
 \section{Conclusion}
@@ -416,6 +482,8 @@ Computing}{December 05, 2024}{Glasgow, Scotland, United Kingdom }
 
   Embracing the language is embracing the person in charge of the computer.
 
+\clearpage
+
 %% 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
-- 
cgit v1.2.3

