Fwd: [vwnc] Would you start a new Smalltalk project today?

On Mar 22, 2009, at 12:49 PM, Antony Blakey wrote:

can you illustrate that point?

Another question I would love to have immutability bit for pharo.
Now if you have immutable collection then I imagine that
        - you should copy them when you want to modify them (functional)
        - I was wondering if the object that you put such immutable data  
structure should
        also be immutable

>
> I'm not suggesting adding native threads to Squeak. Squeak is quite a
> minefield as it is. I think it's time for a new model of Smalltalk
> that includes native threads from the get-go, and is a rethinking of
> the Smalltalk tradition, in the same way that Clojure is a rethinking
> of the Lisp tradition. The parallels between Lisp and Smalltalk, in
> terms of their paradigmatic roles, market issues, and communities, is
> quite striking. Why should these two powerhouses of beautiful
> programming not *both* be reborn.

Can you tell a word on clojure?

Stef

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Gulik.


--
http://gulik.pbwiki.com/

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

On 23/03/2009, at 12:32 AM, Stéphane Ducasse wrote:

Immutable data makes concurrency easier because you avoid concurrent  
modification and eliminate synchronisation issues. Clojure adds data  
types with specific concurrency semantics.

Here's some exposition: http://clojure.org/concurrent_programming

> Another question I would love to have immutability bit for pharo.
> Now if you have immutable collection then I imagine that
> - you should copy them when you want to modify them (functional)

That happens automatically. Modification operations are functional

e.g. f(data) -> data'

data' is a different object than data, which remains unchanged.  
Efficiently implementing this is the key, but it's been done.

> - I was wondering if the object that you put such immutable data
> structure should
> also be immutable

Not necessarily - in the case of Clojure you might put a Ref/Var/Atom/
Agent into an immutable structure, and those objects have their own  
concurrency semantics as described in the link above.

Antony Blakey
-------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787

Borrow money from pessimists - they don't expect it back.
   -- Steven Wright



_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

On 23/03/2009, at 7:37 AM, Michael van der Gulik wrote:

> Anybody who relies on the behaviour of the scheduler deserves to be  
> forced to program in BASIC. Semaphores work; use them.

And they work with native threads, which was my point. A more pedantic  
answer to your response is that you take advantage of the scheduler  
all the time when considering priorities and atomicity, but I agree  
with the intent of your statement.

> Smalltalk, the language rather than the implementation, already has  
> fantastic support for concurrency. Smalltalkers just don't know how  
> to use it. We don't need to rethink the model, we just need to learn  
> to use what we have.

Mutexes and semaphores are hardly 'fantastic'. The state of the art in  
support for concurrency is way beyond what Smalltalk provides -  
locking is both primitive and generally not scalable.

Antony Blakey
-------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787

There is nothing more difficult to plan, more doubtful of success, nor  
more dangerous to manage than the creation of a new order of things...  
Whenever his enemies have the ability to attack the innovator, they do  
so with the passion of partisans, while the others defend him  
sluggishly, So that the innovator and his party alike are vulnerable.
   -- Niccolo Machiavelli, 1513, The Prince.



_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Semaphores and Mutexes are the lower level tools.  **Critical sections** implemented in terms of blocks are the fantastic part.

The little that I know about functional languages and their immutable data structures suggests that a LOT of copying occurs.  That has to be expensive in terms of scheduling and memory footprint.

Bill



---
Wilhelm K. Schwab, Ph.D.
bschwab AT anest DOT ufl DOT edu

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Antony Blakey
Sent: Sunday, March 22, 2009 5:40 PM
To: [hidden email]
Subject: Re: [Pharo-project] Fwd: [vwnc] Would you start a new Smalltalk project today?


On 23/03/2009, at 7:37 AM, Michael van der Gulik wrote:

> Anybody who relies on the behaviour of the scheduler deserves to be
> forced to program in BASIC. Semaphores work; use them.

And they work with native threads, which was my point. A more pedantic answer to your response is that you take advantage of the scheduler all the time when considering priorities and atomicity, but I agree with the intent of your statement.

> Smalltalk, the language rather than the implementation, already has
> fantastic support for concurrency. Smalltalkers just don't know how to
> use it. We don't need to rethink the model, we just need to learn to
> use what we have.

Mutexes and semaphores are hardly 'fantastic'. The state of the art in support for concurrency is way beyond what Smalltalk provides - locking is both primitive and generally not scalable.

Antony Blakey
-------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787

There is nothing more difficult to plan, more doubtful of success, nor more dangerous to manage than the creation of a new order of things...  
Whenever his enemies have the ability to attack the innovator, they do so with the passion of partisans, while the others defend him sluggishly, So that the innovator and his party alike are vulnerable.
   -- Niccolo Machiavelli, 1513, The Prince.



_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

On 23/03/2009, at 9:36 AM, Schwab,Wilhelm K wrote:

> Semaphores and Mutexes are the lower level tools.  **Critical  
> sections** implemented in terms of blocks are the fantastic part.

I don't regard critical sections as particularly fantastic.

> The little that I know about functional languages and their  
> immutable data structures suggests that a LOT of copying occurs.  
> That has to be expensive in terms of scheduling and memory footprint.

A lot less than you might think, but this reminds me of the arguments  
people make against Smalltalk and Lisp.

Old radicals become the new conservatives.

Antony Blakey
--------------------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787

The greatest challenge to any thinker is stating the problem in a way  
that will allow a solution
   -- Bertrand Russell


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

On 23/03/2009, at 12:32 AM, Stéphane Ducasse wrote:

> can you illustrate that point?

It might be that Smalltalk and wide-spread immutability and  
fundamentally incompatible. The problem is that Smalltalk's model has  
Objects whose state changes in response to messages. Such state change  
breaks immutability. But if objects are immutable, then the problem is  
that after any mutation operation within a method, subsequent sends  
need to be not to self, but to the newly mutated object. This problem  
cascades, with the effective self needing to change potentially after  
every send. Maybe the solution is to enable that to happen seamlessly  
e.g. 'self' changes as the object mutates (because the object isn't  
actually mutating). Objects do make immutability-based concurrency  
more 'interesting'.

It's important to note that Clojure is a rethinking of Lisp, and the  
end result is not Common Lisp + concurrency + Java interop. I suspect  
that a rethinking of Smalltalk would be similarly different than what  
we now know. This doesn't surprise me - out assumptions about  
concurrency, or the lack of it, and general inexperience with taming  
true concurrency, is a significant context the design of most existing  
languages, with notable exceptions such as CSP/Occam.

Maybe the appropriate concurrency model for Smalltalk IS an ultra-
lightweight fine-grained copy-on-write multiple image model, with that  
being the *only* threading abstraction. If you could control the  
separation e.g. share some objects with well defined concurrency  
semantics like Clojure such STM/Refs/Agents etc, then that might be  
the best fit. OTOH a shared-nothing model would give you CSP/Erlang.  
The implementation challenges are very different, and I must admit I  
don't know enough about Hydra to know if that project has solved this  
issue.

Antony Blakey
-------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787

He who would make his own liberty secure, must guard even his enemy  
from repression.
   -- Thomas Paine



_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

2009/3/23 Antony Blakey <[hidden email]>:
Hydra simply runs separate object memories in separate native threads.
This is clearly share nothing approach.
The only win comparing to running multiple OS processes is the ability
to establish a fast communication between them, as well, as in future,
relax the 'share-nothing' relation towards partial
sharing(islands/vats/micro-images). This i think would be best way to
go, which would require minimal changes to language side. It is also
good, because it is quite incremental i.e. you don't have to rewrite
the whole smalltalk from scratch.
--------
Now about other replies in topic by different people:

Antony right: mutexes, semaphores, critical sections - this is simply
doesn't scales! Forget about it!
Leave these constructs to java & C/C++ , they are existing for more
than 10 years in operating systems and their limitations are well
known :)

immutability - at a large scale, like automatic copy-on-write magic
IMO would be a waste.
And besides, smalltalk is one of the languages who says NO to magic.
That's why i like it so much.  :)



--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Ensure execution of releasing the lock is about as slick as it gets.  You might want to have another look.


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Antony Blakey
Sent: Sunday, March 22, 2009 6:14 PM
To: [hidden email]
Subject: Re: [Pharo-project] Fwd: [vwnc] Would you start a new Smalltalk project today?


On 23/03/2009, at 9:36 AM, Schwab,Wilhelm K wrote:

> Semaphores and Mutexes are the lower level tools.  **Critical
> sections** implemented in terms of blocks are the fantastic part.

I don't regard critical sections as particularly fantastic.

> The little that I know about functional languages and their  
> immutable data structures suggests that a LOT of copying occurs.  
> That has to be expensive in terms of scheduling and memory footprint.

A lot less than you might think, but this reminds me of the arguments people make against Smalltalk and Lisp.

Old radicals become the new conservatives.

Antony Blakey
--------------------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787

The greatest challenge to any thinker is stating the problem in a way that will allow a solution
   -- Bertrand Russell


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> Here's some exposition: http://clojure.org/concurrent_programming

I will reread it then

but do they guarante identity preservation I guess not.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

I had the impression that this was the direction newspeak was going.


On Mar 23, 2009, at 12:15 AM, Antony Blakey wrote:


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

On 23/03/2009, at 6:51 PM, Stéphane Ducasse wrote:

> but do they guarante identity preservation I guess not.

Identity is obviously more important in OO than e.g. functional or  
function-based programming such as Lisp. This is the sort of thing I  
had in mind when I said that Smalltalk and immutability are less  
obviously a good fit than immutability and lisp-like languages such as  
Clojure.

Antony Blakey
-------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787

Nothing is really work unless you would rather be doing something else.
   -- J. M. Barre



_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Igor Stasenko <[hidden email]> wrote:

> | array sum1 sum2 |
> sum1 := 0. sum2 := 0.
> array := Array new: 10.
> [ 1 to: 10000000 do: [ :i | array at: (10 random) put: (Array new: 10) ] ] fork.
> [ 1 to: 10000000 do: [ :i | array at: (10 random) put: (Array new: 10) ] ] fork.
> 1 to: 10000000 do: [ :i | array at: (10 random) put: (Array new: 10) ].

Something I came across leately: Threads are evil -
http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf



_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

On 3/26/09, Markus Fritsche <[hidden email]> wrote:
They're not evil, just mischievous.

I find it a fairly unimpressive article that recites what any decent
programmer already knows about parallel programming.

"This scenario is bleak for computer vendors: their next generation of
machines will become widely known as the ones on which many programs
crash."

heh. True.

Gulik.

--
http://gulik.pbwiki.com/

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

2009/3/25 Michael van der Gulik <[hidden email]>:
hehe
--
To offer a third analogy, a folk definition of insanity is to do the
same thing over and over again
and to expect the results to be different. By this definition, we in
fact require that programmers of
multithreaded systems be insane. Were they sane, they could not
understand their programs.
--
a spin loop is very good illustration of it:

self locked whileTrue:[ self wait ]
:)




--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

To call threaded code incomprehensible is to ignore many appropriate uses of them.  The presumption is that software is thrown together and then made to work, rather than engineered to work correctly from the bottom up.  Rather than focusing to exclusion on the non-determinism of threading, the author should also consider the independence of the individual threads; threads that do one thing and do it well can be far simpler than code that chops lengthy processes into small chunks that can be executed in sequence.

At the risk of sounding prematurely curmudgeonly, I have used both approaches over time (using slicing when threads were not available to me).  I would much rather face an over-protected (hence deadlocking) multi-threaded program than try to sort out a single-threaded switch statement from hell that tries to do the same job.  Of course, I come at this with a Smalltalk bias, where finding the deadlock is often as simple as following a stack trace to an offending critical section.  Dirty writes are a bear in any language, but my general approach is "don't make that mistake."  It works for me.

Bill

---
Wilhelm K. Schwab, Ph.D.
bschwab AT anest DOT ufl DOT edu

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Michael van der Gulik
Sent: Wednesday, March 25, 2009 4:39 PM
To: [hidden email]
Subject: Re: [Pharo-project] Fwd: [vwnc] Would you start a new Smalltalk?project today?

On 3/26/09, Markus Fritsche <[hidden email]> wrote:
They're not evil, just mischievous.

I find it a fairly unimpressive article that recites what any decent programmer already knows about parallel programming.

"This scenario is bleak for computer vendors: their next generation of machines will become widely known as the ones on which many programs crash."

heh. True.

Gulik.

--
http://gulik.pbwiki.com/

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

2009/3/26 Schwab,Wilhelm K <[hidden email]>:
> To call threaded code incomprehensible is to ignore many appropriate uses of them.  The presumption is that software is thrown together and then made to work, rather than engineered to work correctly from the bottom up.  Rather than focusing to exclusion on the non-determinism of threading, the author should also consider the independence of the individual threads; threads that do one thing and do it well can be far simpler than code that chops lengthy processes into small chunks that can be executed in sequence.
>
> At the risk of sounding prematurely curmudgeonly, I have used both approaches over time (using slicing when threads were not available to me).  I would much rather face an over-protected (hence deadlocking) multi-threaded program than try to sort out a single-threaded switch statement from hell that tries to do the same job.  Of course, I come at this with a Smalltalk bias, where finding the deadlock is often as simple as following a stack trace to an offending critical section.  Dirty writes are a bear in any language, but my general approach is "don't make that mistake."  It works for me.
>

Been there did that.. i especially run to a problem with deadlocking,
ended up with coding a classes which enforcing the right order of
entering the critical sections i.e. you can't enter the critical
section B, if you previously not entered into critical section A.
This works, of course, but not an elegant neither scalable.. because
it leads to the point where you can simply have a single global
critical section to be protected from all contention cases :)



--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

 Sig,

That's an interesting view of it, but I generally see it differently.  "Good" threads are independent.  They do things that are either truly separate tasks, or work on something lengthy and "report back" when it is finished.  Being heavily rooted in engineering mechanics and having become something of an amateur grease monkey (hopefully one who knows his limits), I often visualize threads as gears with the stack pointer as a timing mark near the edge.  The critical sections come into play only when the teeth might collide.  It is a flawed analogy, but keeps me grounded.

Bill


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Igor Stasenko
Sent: Wednesday, March 25, 2009 7:33 PM
To: [hidden email]
Subject: Re: [Pharo-project] Fwd: [vwnc] Would you start a new Smalltalk?project today?

2009/3/26 Schwab,Wilhelm K <[hidden email]>:
> To call threaded code incomprehensible is to ignore many appropriate uses of them.  The presumption is that software is thrown together and then made to work, rather than engineered to work correctly from the bottom up.  Rather than focusing to exclusion on the non-determinism of threading, the author should also consider the independence of the individual threads; threads that do one thing and do it well can be far simpler than code that chops lengthy processes into small chunks that can be executed in sequence.
>
> At the risk of sounding prematurely curmudgeonly, I have used both approaches over time (using slicing when threads were not available to me).  I would much rather face an over-protected (hence deadlocking) multi-threaded program than try to sort out a single-threaded switch statement from hell that tries to do the same job.  Of course, I come at this with a Smalltalk bias, where finding the deadlock is often as simple as following a stack trace to an offending critical section.  Dirty writes are a bear in any language, but my general approach is "don't make that mistake."  It works for me.
>

Been there did that.. i especially run to a problem with deadlocking, ended up with coding a classes which enforcing the right order of entering the critical sections i.e. you can't enter the critical section B, if you previously not entered into critical section A.
This works, of course, but not an elegant neither scalable.. because it leads to the point where you can simply have a single global critical section to be protected from all contention cases :)



--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project