From c47dd25cb66f3e557d592653def2d87e4527203a Mon Sep 17 00:00:00 2001
From: Ekaitz Zarraga <ekaitz@elenq.tech>
Date: Thu, 29 Aug 2024 01:52:40 +0200
Subject: LOCO: more on proposal part
---
papers/LOCO-24/contents.latex | 161 ++++++++++++++++++++++++++++++------------
1 file changed, 117 insertions(+), 44 deletions(-)
(limited to 'papers/LOCO-24')
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
--
cgit v1.2.3