> On Feb 21, 2021, at 10:44 AM, tim Rowledge <tim at rowledge.org> wrote:
> 
> 
> 
>> On 2021-02-21, at 7:18 AM, Liam Proven <lproven at gmail.com> wrote:
>> 
>> 
> [snip]
>> ISTM that the flipside of this is the point from my talk: that if you
>> choose a single, sufficiently-powerful programming language, that you
>> can build the entire stack in that one language and avoid the polyglot
>> complexity of a modern FOSS xNix.
> 
> I'm pretty sure that with sufficient time, determination, staff, and luck, one could write a full stack of software in any language at all. I mean, I've been involved in a few (partial) attempts over the decades. RISC OS was almost entirely written in ARM assembler, even a lot of the applications. The Interval MediaPad was Smalltalk all the way down to process scheduling and interrupt handling. And so on. 
> 
> I guess that my engineering/designer ethos is simply happier to suggest that saving time by avoiding the tedious bits someone has already done is a good way of getting to do the fun bits. Of course, it does depend on what one considers 'the fun bits'. For me, that is doing stuff in Smalltalk, frequently the doing stuff *to* Smalltalk part.
> 
> I'm content to consider those lowest level bits as very large primitives and then just use them. There's absolutely no reason I can think of why we shouldn't have a world where lower level bits get gradually replaced by Smalltalk whilst other users keep on 'talking. Indeed I remember a nice example from ... a long time ago... when Eliot realised that the RISC OS filesystem code provided sufficiently low level commands that he could make a DOS format read/write filestream class for an OS that used a decidedly 'interesting' file format natively.
> 
> Consider this as a suggestion to remember the protocol for eating an Elephant (not that one should actually do that; they get quite annoyed) - don't try to swallow it all at once. We have a rather good language system in Smalltalk. Linux is a not appalling stratum to build over; start by perhaps replacing some of the insane numbers of unix applications filling /usr/bin etc. Gradually infiltrate and push down and out and up. Eventually there's nothing left but the POST and initial loader, the rest just gets garbage collected.

+10.  Don’t let the perfect be the enemy of the good.  Incremental progress benefits from amplifying feedback. An absence of progress can’t.

>> What I would like to see would be a modern take on the single-language
>> dynamic environments that were starting to appear on workstations in
>> the late 1970s to early 1980s: specifically, the
>> non-filesystem-centric ones, because as I've said elsewhere -- and in
>> last year's FOSDEM talk (
>> https://liam-on-linux.livejournal.com/69099.html ) -- I think that,
>> _pace_ suitable OSes to support it -- PMEM tech could render the
>> entire concept of disk drives (HDDs, SDDs, whatever) obsolete.
> 
> 
> Yes, the idiotic tyranny of the unix 'everything is a file' approach has a long tail and needs winding up and hanging in the back of the 'weird ideas from the primitive past' cupboard. The one thing good about it is that the *consistency* provided a lot of leverage. Rather like the consistency of 'everything is an object; yes, even that' for Smalltalk.
> 
> 
>> 
>>> The simple answer to approach this quite closely and fairly painlessly is to use an install of some linux system without the X-nightmare and use the frame buffer as the Smalltalk display. Yes, sure, there are other minimal OS' that Ken pointed out too.
>> 
>> Simple to implement, perhaps, but still a big mess o' C, still
>> completely filesystem-centric, impossible to further simplify, and
>> essentially impossible for any single human to completely understand.
> 
> I am minded of a Wise Saying from the Very Wise Alan Knight -
> 
> `One of the great leaps in OO is to be able to answer the question “How does this work?” with “I don’t care”.`[1]
> 
> Sometimes it is more practical to accept there isn't enough time to know it all. I had to give up trying to understand the details of CPU design some years ago and just let it be something I use. Now, I will certainly cheer loudly if someone comes up with a way to simplify things enough to solve all this; I'm just not going to hold my breath since blue is such a bad choice of colour for my face.
> 
> 
> 
>>> I suggest that we also need to make it practical in this new world to have many Smalltalk images running at the same time so as to insulate said email/browser/twitter/etc from each other in case of serious problems, so we'd want some sort of (Smalltalk implemented, obviously) windowing system.
>> 
>> This is a big issue. I have only a sketchy high-level theoretical
>> understanding of Smalltalk. AFAIK the IBM RoarVM supports a
>> multithreaded multicore Smalltalk engine, but how IBM would feel about
>> anyone attempting to port that to Oberon or something, I don't know.
> 
> My thought these days is to skip the attempts to have a single memory space shared between threads/cores/whatever and have many separate systems running and communicating. Yes, it may be 'less performant' to pass bits down whatever variety of damp string required, but so what. Computers are better than 10 million times faster today than they were when we did BrouHaHa on RISC OS and the Active Book. Let's have a 512 core AARCH64 machine running 1500 images. In your pocket (admittedly right now a fairly large and well cooled pocket).
> 
> I'd also point back to some of Alan's early writings about Smalltalk being a like collection of biological cells with the 'cell walls' isolating each from the other and communication being by (chemical) messages. Separate worlds seem much better implemented in separate memory spaces to me.
> 
> 
> tim
> [1] My most famous Wise Saying is probably "An x86 cpu is a waste of perfectly good sand", dating from circa 1985 when I first got ARMed. People laughed back then. Not so much now.
> 
> --
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> No one is listening until you make a mistake
> 
> 
>