On 10/23/07, Peter William Lount <peter at smalltalk.org> wrote:
>
> That's interesting. Thus Erlang DOES IN FACT HAVE SHARED MEMORY between
> processes: for code and for data. I'd like to learn more about that.
> Could anyone provide more details?

*sigh*.  It does *not* have shared *mutable* memory, and that is the
key.  If I have to contextualize everything I say every time I say it
my mails are going to get even longer, and I'm writing books as it is.
 But I stated several times that sharing is no problem *when it's read
only*.

> One proposal was a "copy-on-write" object space model where objects that
> are about to be written to in a Smalltalk process would be copied to
> that processes private object space - in effect that processes view of
> the "image".
>
> To implement a copy-on-write technique would require operating system
> support for the typical modern mainstream operating system. To implement
> copy-on-write requires a synchronization primitive to be used by the
> operating system - if I'm not mistaken - at least for a few instructions
> while the page tables are updated - a critical section.

What are you on about?  This has been done in Smalltalk before with a
system that had certain objects in ROM.  It's pretty simple and
requires no OS help and no locking.

The VM handles requests made by processes.  So if a process makes a
request that modifies something in the read only space, the VM simply
copies the data to the processes "area" and makes the update.  Simple.
 It requires no OS help obviously and *no locking* because *by
definition the read only space can not be changed*.

The only issue not handled by this is *code* changes, so this needs a
separate mechanism as it does in Erlang (which also can change the
code at runtime):  the old and new code areas.  Smalltalk does this
now with "ObsoleteObject", so it shouldn't be a show stopper.

> One of the crucial aspects that Alan Kay (and others) have promoted over
> and over again is the ability of a language to be expressed in itself.
> This has a certain beauty to it as well as a mathematical aesthetic that
> has important ramifications that go way beyond those characteristics. To
> have a "mobius" system that can rewrite itself while retaining
> functioning versions across a continuous evolutionary path one requires
> a system that can be expressed in itself. Alan Kay points to a page in
> the Lisp Manual where Lisp is implemented in itself. Since Smalltalk is
> supposed to be a general purpose programming language it is crucial that
> it have this aspect of being able to implement itself with itself. So
> far Squeak comes close to this - at least with respect to the virtual
> machine which is written in the slang subset of Smalltalk.

Ok, so what's the problem?  The system I'm proposing would also be
written in Slang.  I'm certainly not going to do it in C anymore then
I have to.

> Unfortunately
> Squeak relies upon manually written C files for binding with the various
> operating systems. Co-existence with C based technology has it's price
> and it's high in that it blocks access to the entire system from within
> the system; by being blocked one is prevented from online interactive
> exploration and experimentation that we are used to at the Smalltalk
> source code level. At least this is being addressed in the amazing work
> of Ian Piumarta (http://piumarta.com/pepsi/pepsi.html) and the
> incredible work of LLVM (http://llvm.org). In fact I highly recommend
> that Squeak move from it's current obsolete C compilers to make use of
> either of these two projects as the bottom of the VM. Apple is funding
> LLVM and Ian's work seems to be part of the work of Alan Kay's
> Viewpoints Research Institute (http://www.vpri.org).

Now we move into our areas of common ground. :)  I too look forward to
the day that we can walk away from the ultimate premature optimization
that is C.

> The "non-destructive" assignment aspect of Erlang is typical of
> non-write-in-place functional and object database systems. It's a key
> aspect of the ZokuScript Object Database Management System and
> Technologies. However it's not a panacea that the silver bullet utopians
> think it is. As with any other solution matrix it has it's benefits,
> payoffs, minuses and costs. These need to be balanced for every
> application. As Wolfgang points out there are issues with it such as the
> "cycle" problem that need to be overcome via implementation exceptions.

Of course.  In CS everything is a trade off.  I never proposed message
passing as a silver bullet, but rather the analogical equivalent of a
GC in the concurrency world.

> The other issue is how fine to you cut the objects? At what point do you
> say enough is enough? That is at what point does a process say oh, I
> don't really have control of changes to the object in question... as
> that object is private to another object space. Thus control needs to be
> passed to a process in the other object space likely on another compute
> node. For example corporate security constraints may require that
> certain data remain on the server while only permitting some data to be
> shared with a laptop node running remotely.

If the message passing is explicit, and the system isn't trying to do
anything fancy for me, this is no issue.  As far as "oh I don't
control the object in question", this is encapsulation.  Some people
even consider encapsulation a good thing. ;)

> It's important to consider the wider issues involved in distributed
> systems that are to be deployed in the real world. For Smalltalk to
> evolve we must get really serious about these issues ahead of the curve
> that others are pursuing now.

Exactly.  And wasting precious resources to get where Java was 10
years ago when everyone else has realized that model can't scale is
exactly what we need to avoid.

> The erlangification (erlangization, or erlangisation) of Smalltalk may
> be a radical enough transformation that it's no longer Smalltalk. If
> that's the way of Squeak that's fine however it seems that a fork is
> likely the result (and yes, the pun of forking was intended).

No, what I envision will act just like Smalltalk does today with the
singular exception that you wont have need of #critical:, Semaphore or
any of that stuff anymore.  And since most people don't use it, it
doesn't look that painful to me.

All the interprocess communication is just going to be accomplished as
message sends like everything else.