in reply to Re^10: Backend diversity for Rakudo
in thread Backend diversity for Rakudo

I'm not impressed by your repeated claims that "Perl 6 hates concurrency and refuses to do anything about it!" and then your repeated refusal to do anything other than hurl abuse and then your repeated citations of the disinterest of Perl 6 developers of listening to you as evidence that they hate concurrency and refuse to do anything about it.

I think instead that Perl 6 developers (though I only speak for myself) have a disinterest in random abuse.

I (speaking again only for myself, though I believe the sentiment extends beyond myself) welcome proposals, code, and specific use cases and even actionable criticisms from people with concrete experience working with and designing concurrent systems.

Replies are listed 'Best First'.
Re^12: Backend diversity for Rakudo
by BrowserUk (Patriarch) on Aug 17, 2010 at 22:58 UTC
    and then your repeated refusal to do anything other than hurl abuse

    Show me this alleged abuse?

    Since when has a technical opinion by a person demonstrably familiar with the subject matter; that neither mentions, nor alludes to any individual or group; constitute "hurling abuse"?

    Show me where I said: "Perl 6 hates concurrency and refuses to do anything about it!" or "it's too late for Perl 6 or Parrot to do anything sane with concurrency.".

    Or any of the myriad other distractions you routinely manufacture to divert from the reality of what I've actually said, and my attempts to engender dialogue on this subject. Here and in other forums.

    If you are in a maze, and you encounter a dead end, do you repeatedly bang your head against it and try to break through; or give up and retrace your steps?

    Had it been possible to have a coherent dialogue on this subject, I'd still be in there talking. And had it been possible to reach an agreement about a technically sound, achievable approach to achieving this goal; I'd be in there contributing in whatever way I could.

    It hasn't; so I'm not.


    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.
      Show me where I said: "Perl 6 hates concurrency and refuses to do anything about it!"...
      ... given the low priority, bordering on active hostility, towards concurrency, achieving the will to correct such problems is very unlikely.

      BrowserUk, Re^8: Backend diversity for Rakudo

      ... or "it's too late for Perl 6 or Parrot to do anything sane with concurrency.".

      BrowserUk, Re^6: Backend diversity for Rakudo

      Do you consider those words constructive efforts to engender dialog?

        Can you not see that: . given the low priority, bordering on active hostility, towards concurrency, achieving the will to correct such problems is very unlikely. is vastly different to: "Perl 6 hates concurrency and refuses to do anything about it!"...?

        Can you deny that only considering concurrency now, after 10 years of development, is: given the low priority,"?

        Do I need to dig out all the quotes from Perl Community leaders and one-time Parrot lead developers etc. saying stuff like "threads is spelt 'fork'"; and generally denying that threads are useful? Does that not constitute "bordering on active hostility"?

        Again you attribute quotes: "it's too late for Perl 6 or Parrot to do anything sane with concurrency.". not for things I said; but for your interpretation of what I said.

        For a start I was referring to Parrot alone--not Perl 6.

        But actually, I do believe it is too late to retro-fit threading to Parrot.

        One reason is: I don't believe you can ever achieve good performance using a register-based VM in a threaded environment. Each thread has its own stack, and that is where all thread local entities should live. Using a common heap for low-level interpreter entities (eg. register spill files), creates the need for too much locking.

        I don't believe that user-space threading is a viable solution to concurrency in the rapidly encroaching world of multi-core CPUs.

        Hence: "achieving the will to correct such problems is very unlikely".

        Do you consider those words constructive efforts to engender dialog?

        I've pretty much ceased to try and engender dialog, because: a) past experiences show tell me I'd be wasting my time; and b) because I believe it is too late to do so.

        I've considered attempting to start afresh on a stack-based VM that targets kernels threads from the ground up. Kernels threads because a) they're the ONLY form of concurrency that scales on modern, multi-core cpus; b) because all the other forms of single process concurrency can (easily) be layered on top. No other form of threading can make that claim.

        But I realise that I don't have the skills to do it alone; nor the following to get the right skills behind it.

        So yes. It is my opinion that Rakudo is too little to late. And I reserve the right to express that opinion. Do you deny me that?


        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.