On 5/29/12 3:01 PM, Alex Rønne Petersen wrote:
On 29-05-2012 23:54, Andrei Alexandrescu wrote:
On 5/29/12 2:49 PM, Alex Rønne Petersen wrote:
On 29-05-2012 23:32, Andrei Alexandrescu wrote:
On 5/29/12 1:35 AM, deadalnix wrote:
Le 29/05/2012 01:38, Alex Rønne Petersen a écrit :
I should probably add that Java learned it long ago, and yet we
adopted
it anyway... blergh.
That is what I was about to say. No point of doing D if it is to
repeat
previously done errors.
So what is the lesson Java learned, and how does it address
multithreaded programming in wake of that lesson?
Andrei
It learned that allowing locking on arbitrary objects makes controlling
locking (and thus reducing the chance for deadlocks) impossible.
And how does Java address multithreading in general, and those issues in
particular, today?
Andrei
It doesn't, and neither does C#. Java still encourages using
synchronized, and C# still encourages using lock, but many prominent
figures in those programming language communities have written blog
posts on why these language constructs are evil and should be avoided.
Some citations (beyond the known fallacies of Java 1.0) would be great.
Thanks.
Besides, it seems to me that D can't quite make up its mind. We have TLS
by default, and we encourage message-passing (through a library
mechanism), and then we have the synchronized statement and attribute.
It just seems so incredibly inconsistent. synchronized encourages doing
the wrong thing (locks and synchronization).
Each paradigm has its place. Lock-based programming is definitely here
to stay, and when the paradigm is needed, doing it with synchronized
objects is better than most alternatives/
Andrei
