diff options
| -rw-r--r-- | papers/LOCO-24/contents.latex | 161 |
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 |