> -----Mensaje original-----
> De: squeak-dev-bounces at lists.squeakfoundation.org 
> [mailto:squeak-dev-bounces at lists.squeakfoundation.org] En 
> nombre de Jason Johnson
> Enviado el: Martes, 23 de Octubre de 2007 13:58
> Para: The general-purpose Squeak developers list
> Asunto: Re: What about "Erlanging" the smalltalk interstitial 
> space? (wasRE: Multy-core CPUs)
> 
> 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.
> 

Erlang does not have objects so I don't think that one paradigm can map 1:1
the other in both sides. Trying to compare literally will be noisy as
minimum. That's why I'm using, as borgs do :), the word "assimilate" meant
to be parsed as "to take from it's conceptual essence it's virtues and
discarding it's vices".

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

But that will introduce a singularity in the paradigm. I'm afraid that
accept that is too much. Can you find a way of archieve the goal of your
proposal without devastating the "all is an object" premise?

> 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.
> 
And accepting singularities like that is how a language gets it's syntax
polluted and developers has to compensate that uncompletism by having to
remember (and model) in it's brains N more rules. The worst of course is not
the syntax but damaging the paradigm. That's is accepting the policy of
unloading of work the machines to load humans. As I see things humans are
not here for that and machines are not here for that. Dear Jason, I'm in the
"opposite corner of the ring" for that policy.

> 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).
> :)
> 
Mmmm no. I mean that every message send should have a process ala Erlang. Of
course this will only optimize in the other cores the messages sends that
are parallelizable (discern on which is a question that deserves
cogitation). Maybe is just a modest improvement to take advantage of
multicore but it never has any intention to disrupt the paradigm.

> > 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. :)
> 
Well.. To be honest I interpret belief as being the user of a system of
thought and of course diferent from a fact or a model that has enough proofs
of concept to deserve investment (time, efforts, $$, energy, etc).
But I think I see your point. I also think that there is no solution without
tradeoffs and I'm not willing to disrupt the paradigm. To gain my willing
(probably others) show a more complete model that works first ;)

All the best,

Sebastian Sastre