[Cuis-dev] Dynabook and education

[Philip Bernhart]

Hi,

Hilaire Fernandes via Cuis-dev <cuis-dev at lists.cuis.st> writes:

> Le 17/06/2020 à 12:44, Douglas Brebner via Cuis-dev a écrit :
>> On 17/06/2020 11:17, Hilaire Fernandes via Cuis-dev wrote:
>>> - *namespace* for safe installation of applications/bundles,
>>>
>>> - *sandbox environment* for safe execution of applications/bundles,
>>>
>> I've recently been thinking of some kind of Actors in the form on 
>> sub-images or mini images ran in parallel that may be a way to handle 
>> those cleanly.
>>
>> Inspired somewhat by Alan Kays comment about how the computer should 
>> be split into smaller computers. Objects don't quite have the 
>> properties to be that (due to Process) but the Image *does*.
>>
> Oh yes this is wise. Even stronger, we do not have the choice given the 
> single thread nature of the VM, it will be a waste of resources to not 
> have several image running in parallel. I vaguely know that there are 
> inter process protocol for communication between process (IPC). Should 
> it be fast enough for communication between applications deployed in 
> different images?

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.

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.

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.

So don't design around the ARE but around the what-needs-to-be-done.


My 0.02 EUR,
Philip