|
Re^12: Slow evolution of Perl = Perl is a closed Word
by BigAl (Scribe) on Sep 08, 2007 at 21:20 UTC
|
Threading is absolutely critical to Perl 6 and other languages that will run on Parrot. We have a prototype implementation, and the core design document addressing concurrency, a work in progress, will be completed early next year. I'll review the substantial portions of this thread as I polish off the document. | [reply] |
|
|
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:
- first-class support for multiple thread paradigms?
- excellent depth in the GC-under-concurrency topic
- reality-based discussion of COW and VM/ints/threads
- copy constructs base on macros mapping to efficient per-OS code
- they're not throwing in too many language-specific assumptions
- continuation<=>VM mapping looks appropriate
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.
| I understand that in the Haskell community there is still major discussion about how competing concurrency paradigms compose with exceptions, other state-ish monads, and each other. While perl6 doesn't look like it has enough type-inference goodness (at this time) to make the kinds of guarantees necessary to utilise some of the more esoteric constructs, I still have some (probably unfounded) concern that couching the design in STM is a premature "optimisation". |
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
| [reply]
[d/l] |
|
|
Threading is absolutely critical to Perl 6 and other languages that will run on Parrot.
That single sentence is the best news regarding Parrot I have seen written down in the last 3 years.
We have a prototype implementation,
Is this a part of the parrot distribution? Otherwise, it the prototype available for download?
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] |
|
|
Not Quite Perl is part of Parrot, and covered here on the Pugs blog. There's also v6 at CPAN; Pugs, which is written in Haskell; and KindaPerl6 (which should have a real page, but I didn't find one).
| [reply] |
|
|
A reply falls below the community's threshold of quality. You may see it by logging in.
|
|
|
| [reply] |
Re^12: Slow evolution of Perl = Perl is a closed Word
by BrowserUk (Patriarch) on Sep 08, 2007 at 17:56 UTC
|
It's not what I care about, and your attempts to make this personal are wasted.
You are exactly right, you cannot impose a view point upon your fellow volunteers. Even if that view point represents a critical requirement.
And that is exactly the problem with OS projects.
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] |
|
|
And that is exactly the problem with OS projects.
The next time you feel like complaining that Perl 6 or Parrot or whatever project doesn't take you seriously, remember that you agreed that no one gets to tell volunteers what they must care about. If you're not willing to do something, I see no reason why anyone who's actually do something should give your opinion one moment's notice.
You can still use Perl 6 and Parrot when they comes out though. We're just awesome that way.
Earlier you asked for an example of you asking someone to write code for you. I suppose vague, dark intimations that Perl 6 and Parrot are going to fail unless someone magically reads your mind and distills your ominous-sounding concerns into something concrete that somenoe can actually implement aren't precisely the same thing, but if you have something to suggest for Perl 6 and/or Parrot then why in the world are you whinging that no one will ever implement it and your Cassandra-like brilliance will go unnoticed and unlamented until too late?
I promise I won't ignore you if you actually say or do something useful... but will you just stop whining and arguing and do something?
| [reply] |
|
|
... and arguing ...
I'll stop arguing my case when a) someone convinces me it is wrong b) I see no possibility of changing the outcome for which I am arguing.
Breath easy. You have convinced me that the latter is imminent.
... and do something?
Like what?
If you mean take the time to work up patches and submit them, I've already tried that route elsewhere. But, unless there is at least a general acceptance that the purpose of the patch is desirable, there is no point. The effort expended is wasted because someone you've never met, somewhere you've never been, will make a capricious and arbitrary decision that your patch doesn't fit with their blinkered vision and reject it. Been there, done that.
There has to be at least a general concensus amongst the major committers to a project that a particular new feature is desireable, before huge efforts are expended, otherwise that effort is wasted.
For example. If I submitted a patch that required major changes to say 50% of the existing source files; requires that the existing memory management strategy has to be turned on its head; and that causes all the existing language implementations to fail to build; what are the chances of that patch being accepted?
And when you've realised that the answer to that is; 0%, then you will realise why there is no point in attempting to pursue writing such a patch until at least one core developer accepts the premise that the aim of the work is valid.
but will you just stop whining ...
I'm not whining. And about 3-5 years from now, you'll realise that too. And 3-5 years from now do not be at all surprised if I am still around to say: I told you so!
Longevity has only one single advantage: what goes around, comes around.
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] |
