On 10/21/07, Igor Stasenko <siguctua at gmail.com> wrote:
>
> I don't think this have a sense. Classes should be treated as regular
> objects (everything is an object - remember?), and due to that fact
> you can't make preferences over different kind of objects.

Ah, but they are the same, I'm not making a difference, I'm making an
optimization and not getting caught. ;)

> Class
> objects and instance objects are the same: objects holding a mutable
> state.

Fine, you can have mutable state.  But only within your own process.
If you change it no other process will see it.

> A method dictionary is a mutable state of class, so changing it should
> affect all objects of given class immediately.

This is a special case in my envisioned system, just as it's a special case now.

> And btw, i starting doubt about 'no sharing at all' paradigm. Just in
> one of the links you given about Erlang, one of the readers commented:
> (http://armstrongonsoftware.blogspot.com/2006/08/concurrency-is-easy.html)

Ok, so someone presented a counter-point about a meaningless analogy,
and that disproves the power of message passing?

You can doubt it if you want.  You can work incredibly hard for the
next 5, 10 years or however long it takes and add native thread shared
state concurrency to Squeak.  But Erlang will continue to gain market
share.  Dinosaurs like Java, with their old shared-state model will
get less and less relevant as concurrent software gets the complexity
explosion that web software is going through now.  And if your fast
you will make it just in time to charge into the party as the last
light goes out.

> There an obvious evidence of a system which performs in parallel by
> having a single shared state - human brain. Do we experience heavy
> 'locking' or 'concurrency' problems?
> Personally, I'm not :) And if so, then why sharing state should be
> considered evil?

For the same reason manual memory management is in most cases:  It's
too hard to get right, it's too hard to reason about, it's impossible
to compose with other software made independently.

Now of course we can get back into the watershed of beating ourselves
for being "bad programmers" but after so many failed projects, and
success itself meaning simply having a small enough critical bugs to
be usable, maybe we should admit we're trying to put the shoe on
backwards.

> Also, in fact, you can't eliminate using shared state at all.

I don't think that's been proven at all.  In fact there have been
OS'es to do exactly that.

> There can be only a ways how to delegate shared state management to
> outer context (such as OS, or VM e.t.c).

That it doesn't have to be shared state.  Does Linux have shared
state?  I don't recall ever having to lock a mutex before reading a
disk, or allocating memory or anything.  Of course Linux does have
shared resources internally, but if you broke it up into smaller
"Kernels" that each had a the same interface between each other then
perhaps this could be eliminated.

> A 'fine-grained' locking is nothing more than manual controlling of
> shared state made by developer.

Exactly, and manual memory management is nothing more then manual
controlling of memory made by the developer.

> Try implement Erlang (or any other system which uses parallel
> computations and having a shared state) without locks and semaphores.

That depends on the OS and CPU, not the problem domain.

> So, tell me, what the difference between
> manually controlling it, or 'magically', like Erlang does?

Seriously?  Well lets see:  (1) lines of code needed to accomplish a
given task, (2) literally man *years* of work time, (3) stability of
finished product (or perhaps you know of a Java/C++/whatever system
that is in heavy use and achieves 9 9's of reliability?), (4)
difficulty of solving bug that do appear due to concurrency, (5) the
ability to solve concurrency issues at *design time* instead of
*implementation time* (probably the most important of all of them),
....

> A proposed a message passing between different OS processes(squeak
> images) is nothing more than letting OS deal with shared state
> problems (locks/queing e.t.c).. naively thinking that we are get rid
> of shared state concurrency. Are we really do?

Please reread what you wrote here because.... What you basically said
is "doing X is nothing more then letting the OS and/or system deal
with the complexity for us and naively thinking it just goes away".
Is this not the exact reason we are using Smalltalk instead of C++, C
or assembler?