Fwd: Shim OS [response to: partially Squeak based OS]

I responded directly to Liam, but noted a lof of interest on this list..
FYI,
-KenD
-------- Original Message --------
..
Liam,

I noted your post on the Squeak mailing list and enjoyed the FOSDEM
slides.

I happen to have been at Apple during the 90's and have experience
writing in SK8Script, NewtonScript, Dylan, MacLisp,  ScriptX, and
Smalltalk (among others).  Glad to see someone notice these things.

A couple of thoughts..

Device drivers are, for me, complex and painful.

Not considering device drivers as my value added area, my thought was to
use a "shim" OS, so I got the vm-display-fbdev (frame-buffer display) up
for use with Alpine Linux (MUSL + Busybox).  I am primarily a Cuis
Smalltalk user (I like small; Note class counts in
https://github.com/Cuis-Smalltalk/Learning-Cuis) but Squeak works here
as well.

Ultibo.org is an interesting Free Pascal based unikernel for Raspberry
Pi's.  Makes use of multicores.

Detecting and recovering from driver SW and HW failures is critical to
robustness.

Minix3.org is a microkernel whose Reincarnation Server can reload failed
drivers.

Erlang's HydrOS is meant to deal with HW failures
(http://www.erlang-factory.com/static/upload/media/1498583896660864samwilliamshowtobuildanoswitherlang_awhistlestoptourofhydros.pdf 
)

Good on ya,
-KenD

On 2021-02-20, at 6:51 PM, [hidden email] wrote:

Device drivers are, for me, complex and painful.

I don't think I've ever met anyone for whom that is not the case.

On Sun, 21 Feb 2021 at 03:51, <[hidden email]> wrote:
>
> I responded directly to Liam, but noted a lof of interest on this list..

Did you? May I ask -- to which address?

Oh my word, that's quite a back-catalogue! I am impressed.

I generally find -- and this time is no exception -- that Lisp folk
are _strongly_ resistant to any suggestion that perhaps a more
conventional syntax, layered on top of a conventional prefix-notation
Lisp, would make it a lot more accessible to a lot more people.

One objection to this is that it significantly impedes the use of Lisp
macros. On the other hand, many former Lispers are now enthusiastic
about various modern xNix scripting languages that in recent versions
include closures, lambda calculus and so on, and yet none of these can
use Lisp-type macros.

I suspect that while Lisp's macros are immensely powerful, at least
potentially, they might also make it very hard to read and debug
someone else's code, and therefore not be ideal for cooperative team
development... And that is a sad commercial necessity.

But this is not germane to the Smalltalk side of my proposal. ;-)

> A couple of thoughts..
>
> Device drivers are, for me, complex and painful.

I am sure you're not alone.

> Not considering device drivers as my value added area, my thought was to
> use a "shim" OS, so I got the vm-display-fbdev (frame-buffer display) up
> for use with Alpine Linux (MUSL + Busybox).  I am primarily a Cuis
> Smalltalk user (I like small; Note class counts in
> https://github.com/Cuis-Smalltalk/Learning-Cuis) but Squeak works here
> as well.

I have played around with Alpine a little, but even a lightweight
Linux is still a formidable amount of code, and therefore will still
need frequent updates and so on. That's part of what I wanted to break
away from.

Secondly, I was trying to look to the future, to an OS that could run
well on a machine with only RAM and persistent memory, without disk
drives or anything pretending to be disk drives.

I seriously think that in time PMEM could turn the notion of disk
drives into legacy technology, as obsolete as tape drives -- i.e.
still relevant for big enterprise servers, but completely gone from
typical end-user devices.

Thirdly, I suspect that keeping any element of existing technology
stacks -- for instance, such as a bare-metal shim OS implemented in C
-- will preserve some of the many problems with the existing stack,
and represent a temptation to import other bits of the stack as well.

> Ultibo.org is an interesting Free Pascal based unikernel for Raspberry
> Pi's.  Makes use of multicores.

I am aware of it. I have a copy, and have installed Free Pascal and
Lazarus, and am trying to revive dusty corroded memories of Pascal
coding in the 1980s...

I was hoping to resurrect my corroded skills -- meagre at the time --
by trying to do some bare-metal vintage-computer emulation. Both the
Sinclair QL and Atari ST operating systems have completely FOSS
derivatives these days, and getting them running on the RasPi would be
fun. But probably far beyond my skills... :-( There is not much
existing code to draw upon: Delphi was not a popular tool for writing
emulators.

> Detecting and recovering from driver SW and HW failures is critical to
> robustness.

This is true.

> Minix3.org is a microkernel whose Reincarnation Server can reload failed
> drivers.

It is, but it's still an *nix. _Heavily_ filesystem-centric,
implemented in C, not yet multicore capable, and anyway, it is its own
thing and doing just fine. Most widely-deployed x86 xNix as it is in
every recent Intel CPU.

> Erlang's HydrOS is meant to deal with HW failures
> (http://www.erlang-factory.com/static/upload/media/1498583896660864samwilliamshowtobuildanoswitherlang_awhistlestoptourofhydros.pdf
> )

OK, this one is new to me! Erlang is a bit niche, though, and as I
understand it, the price of its resilient multiprocess model is that
it is quite slow...

--
Liam Proven – Profile: https://about.me/liamproven
Email: [hidden email] – gMail/gTalk/gHangouts: [hidden email]
Twitter/Facebook/LinkedIn/Flickr: lproven – Skype: liamproven
UK: +44 7939-087884 – ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053

On Sun, 21 Feb 2021 at 07:12, tim Rowledge <[hidden email]> wrote:
>
> I don't think I've ever met anyone for whom that is not the case.

Heh. :-)

> Writing an entire OS seems to me to be a Quixotic dream; why bother?  Yes, I know Dan Ingall's famous quotation -
> "An operating system is a collection of things that don't fit into a language. There shouldn't be one."
>
> However, I think that one can look at this rather differently than "have no operating system". I think the practical approach is  "have nothing that doesn't fit in your language system". If we make a system that can talk to everything that an underlying OS kernel and facilities provides - device drivers, scheduling, interrupt handling, storage abstraction, network blah-blah-blah - then there is no OS as a separate thing that anyone need care about. There are no "things that don't fit into a language".

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.

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.

> 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.

> One would still need to work out how to handle all the facilities we take for granted for our daily use of a computer; a *good* email system, web browsing, assorted social media interfaces and on and on.

A2 can do a surprising amount of this already, today. For a niche
experimental OS it is amazingly complete.

http://ignorethecode.net/blog/2009/04/22/oberon/

> 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.

> It's doable. I think it might take a bit more than the usual

It is no small project, certainly.

But parts of it are already there. A2 exists and works. Squeak exists
and works. Putting one on the other is not impossible. That would
yield a proof-of-concept to get people interested...

--
Liam Proven – Profile: https://about.me/liamproven
Email: [hidden email] – gMail/gTalk/gHangouts: [hidden email]
Twitter/Facebook/LinkedIn/Flickr: lproven – Skype: liamproven
UK: +44 7939-087884 – ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053

> On 2021-02-21, at 7:18 AM, Liam Proven <[hidden email]> 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.

>
> 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; [hidden email]; http://www.rowledge.org/tim
No one is listening until you make a mistake

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

PS to Liam -
please don't take any of these comments as implying you shouldn't try; consider them reminiscences from some old farts that have tried in the past and have some suggestions about thing *not* to waste time on. Learn from our mistakes because none of us have time to repeat everyone else's.


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: BIK: Buggered if I Know

On 21/02/2021 18:44, tim Rowledge wrote:
> 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 would so love to have a machine like that. Maybe some kind of
LittleSmalltalk or SmallWorld derivative could be used for tiny non-GUI
specialised images.

On Sun, 21 Feb 2021 at 19:44, tim Rowledge <[hidden email]> wrote:
>
> 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.

Point conceded. I would submit that the core thing is perhaps a
_single_ language, and one that is simple and accessible enough for
children, adult learners, amateurs, part-timers and so on. One that
won't blow your foot of if you fail to dereference a pointer or access
the 42nd element of a 40-element array.

>  RISC OS was almost entirely written in ARM assembler, even a lot of the applications.

Sure, but that's not really a good thing, IMHO.

It remains possible; e.g.
http://www.kolibrios.org/en/
http://menuetos.net/

That it's possible doesn't mean it's a good idea. Remember, Acorn
originally tried using Modula-2:
https://en.wikipedia.org/wiki/ARX_(operating_system)


> The Interval MediaPad was Smalltalk all the way down to process scheduling and interrupt handling. And so on.

Do tell? Google draws a blank.

> 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.

Interesting!

> 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.

I disagree.

For instance, firstly, this does seem to be what the systemd project
is largely doing. It is causing a lot of alienation and anger.

Secondly, this way you can never escape from the core assumptions,
which is precisely what I am trying to do.

As a parallel example: ISTM that the GNOME team are trying to design a
simple, almost smartphone-like desktop for Linux by slowly & gradually
rewriting a Windows-95 like desktop, implemented in plain ol' C,
removing features that they do not use and therefore deem unnecessary.
Personally I find the result an unusable mess and it's caused a lot of
people to desert to other desktops, massively splintering the Linux
desktop space and seriously damaging Linux. Worse still, due to
absence of ideas and knowledge, most of the new alternatives are just
other rip-offs of Win95. Poor ones, but with a lot of chrome.

> 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.

Well, ISTM that you won't ever get there by piecemeal replacing bits
of Linux, file-by-file.

> 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.

Plan 9 took this a lot further. It got nowhere, to a first approximation.

> 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.

Which again flies in the face of C, which wants you to know and
understand how CPUs work. Worse still, the CPU in question being a
mid-1970s PDP-11.

> 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).

Sounds good but I lack enough knowledge of Smalltalk (yet, if I'm
lucky) to judge how feasible it is.

My objectives were to try to propose a new way to build a new OS based
solidly on existing FOSS tools and technology, and not to reinvent yet
more wheels.

> 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.

Perhaps so.

> [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.

:-)

--
Liam Proven – Profile: https://about.me/liamproven
Email: [hidden email] – gMail/gTalk/gHangouts: [hidden email]
Twitter/Facebook/LinkedIn/Flickr: lproven – Skype: liamproven
UK: +44 7939-087884 – ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053

On Sun, 21 Feb 2021 at 20:33, Eliot Miranda <[hidden email]> wrote:

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

The problem with this is that it leads to a rather toxic final conclusion...

https://dreamsongs.com/RiseOfWorseIsBetter.html

https://dreamsongs.com/WorseIsBetter.html

--
Liam Proven – Profile: https://about.me/liamproven
Email: [hidden email] – gMail/gTalk/gHangouts: [hidden email]
Twitter/Facebook/LinkedIn/Flickr: lproven – Skype: liamproven
UK: +44 7939-087884 – ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053

> On Feb 22, 2021, at 4:43 AM, Liam Proven <[hidden email]> wrote:
>
> On Sun, 21 Feb 2021 at 20:33, Eliot Miranda <[hidden email]> wrote:
>
>> +10.  Don’t let the perfect be the enemy of the good.  Incremental progress benefits from amplifying feedback. An absence of progress can’t.
>
> The problem with this is that it leads to a rather toxic final conclusion...

/A/ problem with this is that it /can/ lead to a rather toxic final conclusion...

You can’t prove a negative.  It isn’t always the case.  And even the classic example of the Learning Research Group/Systems Concept Group at PARC going blue plane and producing Smalltalk is a bit of a myth.  There was still incremental progress here.  Smalltalk-72 was written in BASIC.  ‘74 evolved into ‘76 evolved into ‘80.  The hardware evolved from the Alto to the Dorado.

So this whole idea that the only way one gets to the future is by making giant leaps is, frankly, baloney.  The part of it which *isn’t* baloney is the part if it about how marketing can cause a bad idea to drown out a good idea (VHS vs Betamax etc).  But that’s not about incrementalism; that’s about capitalism.

On Mon, 22 Feb 2021 at 16:48, Eliot Miranda <[hidden email]> wrote:
>
> /A/ problem with this is that it /can/ lead to a rather toxic final conclusion...

OK, conceded. :-)

>  And even the classic example of the Learning Research Group/Systems Concept Group at PARC going blue plane and producing Smalltalk is a bit of a myth.

I do not understand "going blue plane". What does that mean?

>  Smalltalk-72 was written in BASIC.

Good heavens, really? :-) How wonderful! Do you have any more info?

‘74 evolved into ‘76 evolved into ‘80.  The hardware evolved from the
Alto to the Dorado.

> So this whole idea that the only way one gets to the future is by making giant leaps is, frankly, baloney.

Hmmm. That is not what I was getting at. I developed this theme at
some length in my _previous_ FOSDEM talk:
https://liam-on-linux.livejournal.com/69099.html

You might find it interesting. I would be interested in any comments.

--
Liam Proven – Profile: https://about.me/liamproven
Email: [hidden email] – gMail/gTalk/gHangouts: [hidden email]
Twitter/Facebook/LinkedIn/Flickr: lproven – Skype: liamproven
UK: +44 7939-087884 – ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053

SOn 22/02/21 12:14 am, tim Rowledge wrote:
> 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).

Pretty close! Many peripherals today are smart and come with their own
cores and images. My linux desktop already has over 1400 'firmwares'
waiting to be downloaded on demand. Smartphones, too, have tens of smart
peripherals with multiple cores and custom firmwares.

The main problem with RAM (memory) is not that it is single space. RAM
is 'dumb'. Having a core pull a word from RAM just to increment it is
such a huge waste of cycles and energy. If primitive ops like
incr/decr/complement/add etc. can be delegated to RAM (smart RAM) then
the overall computation will become faster and energy efficient.

Linux kernel itself is small enough that RAM capacity or cost is no
longer a constraint. Most of the bulk in a distro is in the GNU app
stacks and device drivers.

That leaves power (battery). If power can also be smartly distributed,
say at 8-node cluster level, then we can expect to see a cool ;-) pocket
computer running 1500 images concurrently.

After all, Masashi Umezawa's NetMorph demonstrated seamless migration of
live objects across closely coupled Smalltalk images way back in OOPSLA
2002!

Regards .. Subbu

Hi--

      tim writes:

 > One would still need to work out how to handle all the facilities we
 > take for granted for our daily use of a computer; a *good* email
 > system, web browsing, assorted social media interfaces and on and on.

      Liam responds:

 > A2 can do a surprising amount of this already, today. For a niche
 > experimental OS it is amazingly complete.
 >
 > http://ignorethecode.net/blog/2009/04/22/oberon/

      Fun! I like the zooming. I've been using the zooming capabilities
of SqueakJS on mobile devices for a few years now. It's an essential
feature; I like how it's an easily-leveraged part of CSS.


-C

--
Craig Latta  ::  research computer scientist
Black Page Digital  ::  Berkeley, California
663137D7940BF5C0AFC :: 1349FB2ADA32C4D5314CE

On Mon, 22 Feb 2021 at 20:47, Eric Gade <[hidden email]> wrote:
>
> If you've got the time, Dan Ingalls' very recent history of Smalltalk is a really informative read: https://dl.acm.org/doi/pdf/10.1145/3386335

Great! Thank you. Added to the (considerable) list...

--
Liam Proven – Profile: https://about.me/liamproven
Email: [hidden email] – gMail/gTalk/gHangouts: [hidden email]
Twitter/Facebook/LinkedIn/Flickr: lproven – Skype: liamproven
UK: +44 7939-087884 – ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053