Pure dynamic casts?

[language_fan]

Wed, 23 Sep 2009 10:43:53 -0400, Jeremie Pelletier thusly wrote:

> You're right about concurrency being a different concept than threading,
>   but I wouldn't give threading away for a pure concurrent model either.
> I believe D is aiming at giving programmers a choice of the tools they
> wish to use. I could see uses of both a concurrent model with message
> passing and a threading model with shared data used at once in a
> program.

The danger in too large a flexibility is that concurrency is not easy and 
it is getting incresingly complex. You need to be extraordinary good at 
manually managing all concurrent use of data. If I may predict something 
that is going to happen, it is that there will be high level models that 
avoid many low level pitfalls. These models will not provide 100% 
efficiency, but they are getting faster and faster, without compromizing 
the safety aspect. This already happened with memory allocation (manual 
vs garbage collection - in common applications, but not in special 
cases). Before that we gave some of the error detection capabilities to 
the compiler (e.g. we do not write array bounds checks ourselves 
anymore). And optimizations (e.g. register allocation). You may disagree, 
but I find it much more pleasant to find that the application does never 
crash even though it works 15% slower than an optimal C++ code would.

> Shared data is always faster than message passing so you could
> implement real time code with it, and use messsage passing for other
> parts such as delegating GUI messages from the main loop.

Shared data is maybe faster on shared memory machines, but this is not a 
fact in the general case.

> 
> Shared data being harder to manage than message passing does not make it
> a bad thing, it just means you can have two different models for two
> different usages.

Shared data is not a single homogenous model. Things like transactional 
memory work in shared memory systems, but still they have different 
semantics.