[Cuis-dev] Dynabook and education

[Douglas Brebner]

On 17/06/2020 13:14, Philip Bernhart via Cuis-dev wrote:
> I think it's wiser to not base the design on how things *are* but on
> how things are *supposed to be*. Smalltalk was built at a time where
> the circumstances were vastly different than they are today.
Yeah, I know. I'm still thinking my way through this so the following 
probably won't be very clear.
> Therefore I think that building Objects on the concept of individual
> actors which each have proper isolation inside them and you send them
> a message, which gets put into an inbox internally and then when the
> object has time get's processed and an answer is sent is a better
> continuation of the object message passing style than to introduce
> special objects like whole images who now are supposed to have parallel
> capabilities and others don't.

Well, the whole point of this is to *stop* treating Images as special 
objects because, right now, that's exactly what they are.

This all came about when I asked myself:


"Why isn't the Image an Object?"

and

"Why aren't Objects equivalent to/as powerful as a sub-Image?"


Combining these with Alan's idea of subdividing the computer into 
smaller computers made me realise that maybe they *should* be the same 
thing. Possibly Actors of some sort.

In Smalltalk, we currently subdivide Computers into Images which are 
further subdivided into Objects. Images are as powerful as the 
surrounding computer but Objects are not as powerful as the surrounding 
Image.

Why not?

Can we make them so and would it help simplify the system even further?


> An example in a different programming language would be Erlang. The
> current hip poster-child for concurrent processing and through the
> nicer Elixir veneer used in Startups. Erlang does everything internally
> with actors, which are called there processes. And this can be
> implemented as true parallel processes when the VM supports it on the
> machine. But for a long time the Erlang VM did everything with just
> clever green threads in one process on one CPU as most other naive
> programming languages do it.

The idea of Erlang and Actors is precisely what got me started on this 
path. Along with E-lang Vats, various ways that some single threaded 
languages spin out an async subprocess for blocking/slow tasks, QubesOS, 
and some messing around with tiny, scratch built Little Smalltalk images.


I'm pretty sure this is vague and unclear but I'm still working on the idea.