|Just another Perl shrine|
|( #3333=superdoc: print w/replies, xml )||Need Help??|
TL;DR I'm excited about P6. I see it growing stronger day by day. I'm not surprised that Damian Conway is engaging again, that Nicholas Clark is helping out on #moarvm daily and landing commits, that CPAN integration is underway, and so on. YMMV.
Why not triage things?
Triage and other ordering techniques are bog standard task management techniques. So of course the P6 project are doing that.
This is illustrative of one of several problems I've found in talking about P6. You're assuming a priori that P6ers aren't triaging, which is, imo, tantamount to suggesting P6ers haven't got a clue.
(I can already hear the knee jerk response: "well why else haven't they shipped something "usable and useful" yet? they must be doing something wrong". If that's not your initial response that's great. But if it is then I say you've got work to do with your own mental processes before thinking about continuing this discussion and if it's where you end up then I respectfully request you don't try to continue this discussion.)
No, I'm not willing to discuss our triage lists in this thread, and probably not here at the monastery, because I've found such discussion to be consistently unproductive and frequently down right hostile.
You, and any other monks or readers are encouraged to visit the freenode IRC channel #perl6 and discuss this or any other issue. I think you'll find it productive if you're civil and ask good questions when the right folk (mostly European) are around.
No one here is saying optimization shouldn't be done. The question is when? When product itself is half complete whats the point in optimizing an half complete product?.
First, yes, several folk here are saying optimization shouldn't be done because they explicitly dismiss P6 out of hand. Please think more carefully about your words if you want a more productive outcome from these sorts of exchanges.
I don't agree that the product is half complete (in relation to what would be needed to make optimizing a rational thing to do, so I'm not talking about, say, user doc). Imo it's around 100% complete in relation to what has been deferring most optimization until now.
That said, this is whirlpool dev, so the spec itself isn't complete and the tests matching the spec that exists aren't complete (and probably never will be) and Rakudo doesn't pass all the existing tests (and probably never will on all platforms) and tests aren't the same as something working out in the field.
So "We're probably doomed, we're probably gonna fail ... but just cause were doomed doesn't mean you know we cant get up in the morning and do work" (to quote a Mozillan from before Firefox).
there's nothing left to do but do what we think is best.This is what bought us into this trouble in the first place.
I may be parsing your words incorrectly but you seem to be suggesting that folk doing what they think is best is what got us in to trouble. If you really are thinking that then there is truly no point in engaging. For now I'll work on the basis I'm misparsing you and keep going.
if a project is 14 years late. And all people see is sub projects and re writes how do you expect people to react?
It's probably more like 17+ years late. Many fundamental problems (though not all) that I observed with the Perl language, perl interpreter, and community in the 90s are still extant.
One of the biggest problems is the way folk talk to each other. Why is it that "all people see is sub projects and rewrites" given that this is just a small part of what's actually happening and almost none of my posts here and elsewhere have been about sub-projects or rewrites that weren't essential as far as contributors were concerned?
For example, afaict most P6ers consider MoarVM to be a wonderful saving grace that's rescued us from being dependent on the Parrot project rather than as a random sub project or (unnecessary) rewrite. But you (and many others) choose to see it as the latter despite overwhelming evidence that Parrot is stalled. How can this be? What can we do about it?
Either way the days of the Perl 6 hope are over. We are now in a stage where we accept we won't see a Perl 6 ever.
For those experiencing anger due to unmet expectations, or overwhelming pain due to as yet unrealized hopes, letting go is wise.
I don't think anyone needs to go to the opposite extreme and assume, based on lack of knowledge and/or inability to control the future, that P6 won't ever be what they want it to be. But if that's what it takes for a given individual to get peace then so be it.
Say whatever you like, but by looking at the current progress I see at least 3 years of waiting time till we get something useful.
Who is this "we"? Why are you excluding those (few) who think "we" already have something useful? What's wrong with recognizing that these things aren't a boolean once you go past an individual user or use-case, and that by some measures (eg speed and RAM consumption) it's getting more useful over time?
I see it as entirely plausible that P6 will never be useful and usable enough to interest a lot of folk that find P5 to be fine for their needs.
But I also see it as entirely plausible that it will go the other way, that it'll become increasingly useful and usable for a broader range of user and use-cases than the existing Perl language and perl interpreter have ever covered, and that the P5 and P6 of 2017 will be well on the way to broad reintegration.
A key to a more positive outcome is more contribution and a key to that is having fun, which this isn't. So unless I see posts that I consider respectful towards P6ers, this will be my last post at the monastery for about a month or so. I hope this post will be read by at least one person one day but I very much recognize it's extraordinarily long and boring, and probably not productive, and there's a very good chance that no one will ever read it. Such is life.
»ö« . o O ( "the celebrity tell-all of the Perl-6 cult?" )
In reply to Re^6: -Ofun times