| |
 | Posted by Mark Evans |  Permalink Reply |
|
Mark Evans 
| Daniel Y. wrote
> It's almost impossible to come with a good concurrency
> system for an imperative language like D. Java's model
> sucks, and to write a better model we need to (AFAICT):
> either lots of primitives and go the Ada way, or use a
> Actor-like model. IMO it's better to define the
> concurrency in the libraries and hope for the best ;)
Before I go on permanent vacation from D news, I should
address the claim that good concurrency in imperative
languages, specifically Java, is "almost impossible."
My counterclaim will be Flow Java as cited by
Peter Van Roy of Mozart/Oz fame (scroll down):
http://lambda.weblogs.com/discuss/msgReader$7453
So, good concurrency can indeed mesh with imperative
languages like Java (and D). It doesn't take radical
surgery, either. The Flow Java extension is described
as conservative and moderate.
Note, I am not claiming that concurrent operations will
be done in an imperative style, just correcting the
statement that implementation & design is hard.
The Armstrong talk is worthwhile for some real-world
concurrency case studies. Relevant to D is that
Erlang is used in commercial firmware, which presumably
would be one of D's targeted domains (aspiring as it
does to be a new systems language).
My interest in dataflow concurrency is more than theory.
I have used it extensively in LabVIEW work. LabVIEW
gives concurrency for free. Independent data flows run
concurrently without special instructions.
It appears we must wait for more documentation on Flow
Java. The point here is that the Java integration job
has been done, not merely talked about. I expect LtU
will run a feature on it eventually.
May your horizons ever expand and good luck to all-
Mark
|
