Perl-Sensitive Sunglasses | |
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
Well, after reading that PDD (and linked groups posts) I feel a lot more comfortable about the direction of concurrency (in parrot).
In the past I'd tried to follow Dan's posts regarding the research being done in parrot concurrency (before the whole Leo/Dan explosion) and I hadn't really revisited the topic to check the progress being made. What I liked in the PDD:
To my limited experience, that all sounds well-reasoned. The perl6 Concurrency DRAFT spec seems quite thin on detail at this moment... is that not where this discussion should be focussed? To me it seems as though a wide variety of concurrency paradigms could be efficiently implemented based on the primitives and HLL concepts defined in the PDD. Perhaps other monks have some ideas about what specifically could not be efficiently supported (or implemented without hazard) based on the HLL constructs in the PDD. Personally, I have two observations on the perl6 DRAFT spec: 1) I'm concerned that the language (and perhaps semantics) of the DRAFT spec are defined in terms of STM concepts. I certainly don't discount STM as a good programming model (provided undo/redo hooks and some sort of module-boundry "contracts" for the sake of composability are provided); the concern I have is that language concurrency patterns (wrt: composability) are still in their infancy and I wonder whether one can efficiently model other concurrency paradigms on top of STM constructs.
2) Is perl6 going to be written off as unusable (by under-sold users of other languages) if it doesn't at least expose POSIX-like shared everything APIs? I personally prefer a share/copy-nothing-by-default approach but can understand how shared-everything is very appealing to some folk. After all if parrot supports it, shouldn't perl6 at least expose it for completeness-sake? -David In reply to Re^13: Slow evolution of Perl = Perl is a closed Word
by erroneousBollock
|
|