On 10/22/07, Sebastian Sastre <ssastre at seaswork.com> wrote:
>
>         1.4 I'm interpreting the normal thousands of processes Erlang
> manages as analogue (so similar in function) to one of this tides and point
> why we cannot make tides of Smalltalk message sends in an image?

We can.  In fact, I think we could do it right now with the existing
VM and some packages that have been written already.

>         3. If I understood well, Erlang's main strenght is not that it has
> functions to do things but that it has a message passing technique really
> great that was designed to take advantage of parallelism in a simple way
> efficiently and making processes very cheap (ceaper than the OS ones).

Erlang processes are much cheaper then OS processes *and* OS threads.
But then, so are Smalltalk's.  The only difference is that Erlang
processes are encapsulated entities that have no shared memory [1],
while Smalltalk's do.

>         The intersticial space of virtual objects, AKA messages sends, can
> be "Erlanged" by making each message send to be in a "process" (the cheap
> ones) of it's own like Erlang messages between "process"?

Well, keep in mind, Erlang is a functional language and code written
in uses functions.  Message sends are for communicating between
processes.

>         Same in other words:
>
>         What consequences will affect us if we make a Squeak to use a VM
> that to pass messages use processes ala Erlang (that are simple, cheap,
> efficient and scalable in a world of "cores")?

If you mean every Smalltalk message send is what an Erlang message
send is, then the results would be devastating.  As I mentioned above,
Erlang does it's work with functions.  In Smalltalk, the equivalent
method of doing work is what Smalltalk calls "messages".  In Erlang
there is a concept of sending messages between processes, and I would
do the same for Smalltalk.

>         Can this allow us to assimilate in the Smalltalk's objects paradigm
> the Erlagn's process paradigm? This is: will this allow us to gain that
> parallelizing benefits preventing us to change the programing paradigm?

We can, and it would [2].  But I think we should, at least at first,
make inter-process message sends very obviously different from
inter-object message sends.  It would be possible, for example, that
objects of type "Process" have a different way of handling messages so
that:

(Processes at: 'bank account') addUSD: 5000

Is actually an inter-process send, but I would still want to use the !
syntax, or something equivalent so it's completely obvious that we are
doing something different.

Inter-process message sends have their own lookup complexity that I
think should be separate from the inter-object message sends we have
now.  For example, in Erlang if you send a message to a process that
happens to be in the same image, a simple reference copy happens (no
danger since variables are immutable).  The other two cases would be:
a different OS/native thread in the same image, and a totally
different image (same computer or on the network).

Now if what you're talking about is basically promoting every object
to it's own process (using the terms I have described so far), then I
haven't really given this much though.  This would be a totally
different paradigm and area of research (maybe like CORBA?).  Though
I'm sure someone somewhere has done research on it (or is currently).
:)

> Sebastian Sastre
> PD: I've tried to imagine if this saves us from having to make code trhead
> safe or not. I was unable to refutate this by myself so I also ask kindly
> that the most experienced and critic minds collaborate on this regard.

Us as people who use Smalltalk?  Yes I believe it does.  It doesn't
make it impossible to make a design that has deadlocks, but imo the
big win is that these concerns move to design time instead of
implementation time.

[1] This is enforced by the language.  As far as I know, the processes
actually share the same heap, etc..  They just don't know it and can't
take advantage of it :)

[2] Well, I believe so anyway, and aim to find out.  The issue is that
Erlang has it easy: you *can't* share data at a language level in
Erlang.  In Smalltalk this gets a little tricky, mainly due to one of
Smalltalk's greatest strengths: Classes are live objects (with state
and so on).  I believe this can be overcome, while preserving the
Smalltalk semantics, but I can't prove it yet. :)