Beefy Boxes and Bandwidth Generously Provided by pair Networks
No such thing as a small change
 
PerlMonks  

Re^5: -Ofun times

by Anonymous Monk
on Apr 14, 2014 at 12:46 UTC ( [id://1082245]=note: print w/replies, xml ) Need Help??


in reply to Re^4: -Ofun times
in thread -Ofun times

Why not triage things? In the long list of things. I would prefer to be spec complete first and then take up optimization. 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?

Whatever we do, we'll get hate and pushback from random people on the Internet, so 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. Secondly if a project is 14 years late. And all people see is sub projects and re writes how do you expect people to react?

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. If we ever see, its just a good thing to have.

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.

Replies are listed 'Best First'.
Re^6: -Ofun times
by raiph (Deacon) on Apr 14, 2014 at 20:20 UTC
    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.

    Peace.

      Wooooow, Ralph.

      Way to blame everyone else. I mean, really. It's the negativity here on PerlMonks that's to blame. If only everyone could be enlightened by the fine folk of #perl6 as to just how well things are going, we wouldn't continually harp on how perl-6 has delivered nothing useful and usable for 14 years. We'd be enlightened.

      Do you know why people think that MOARVM is a joke? Because perl-6 has never been honest about it. First it was "Oh, let's experiment with the JVM". Then it was "Well, we've been working on this in secret." All the while no one ever has said "I would use perl-6 if only it had half-arsed support on *three* backends instead of half-arsed support on just one or maybe two."

      Blame everyone else all you want, but it's clear to everyone outside of your weird little #perl6 echochamber that Rakudo chased everyone away from Parrot and then used that as a justification for starting yet another series of half-arsed rewrites.

      I'm sure you're not reading this anymore because it challenges your weird fragile little worldview, but have you ever considered the reason that you get so much pushback that you think is "consistently unproductive and frequently down right hostile" is because the things you spew have so little resemblance to reality?

      No-one cares what Nick Clark is doing. No one cares how many emails Damian Conway sends. None of that matters because it's yet another year when perl-6 doesn't exist in a usuable form (unless you're Moritz's personal hero, writing production IRC bots!!) and continues to make Perl look worse and worse and weird little marketing trolls like you try to blow sunshine up our arses about how if we clap our hands and just BELIEVE hard enough it's really not so bad. It'll be done any day now. You're confident in that prediction. Very confident.

        Please stop, this is immature.
Re^6: -Ofun times
by moritz (Cardinal) on Apr 14, 2014 at 14:53 UTC

      No, but you don't need Anonymous monks to tell you why things have gone so wrong with Perl 6

      A little bit of analysis will help. Even if one agrees Parrot was dying. JVM was perfect for nearly 95% of the programming world. You absolutely didn't have to start work on Moar VM at all. Contrary to whatever a few negligible number of users out of negligible number of total users that Perl 6 has would have told you. The world is no urgent to see Perl 6 run on Mono, Java script, HipHop VM or anything. All languages in their first cut production release run on one VM and that's perfectly acceptable. Instead we now have a situation where the spec needle hasn't moved a degree on the completion meter, whilst bulk of the effort now goes in working on Moar VM and making Rakudo working on Moar VM.

      Is it really that hard to notice the problem here? You have strayed off course and put months of effort to achieve results nobody needs currently

      List of things to be done should have been To make Rakudo spec complete, faster, with documentation and standard libraries. And in that order.

      I know how all of this is going to play out eventually. Another year from now. Rakduo as-is now, will run on Moar VM while there will be few more new projects to port it to dozen other VM's. Because a few random lurkers on IRC will tell you how cool it is to make Rakudo run on their Toy VM's. While the focus should actually be on serious users, Who are likely to never use anything apart from JVM or Mono(Sometime in the future). Serious users who need a finished product on one VM properly, with documentation, no show stopper bugs, and standard library

      And well yeah coming to the project management part. Any average PM will tell you why it is important to keep your enthusiasm in control to finish of your current goals. No matter how tempting new projects feel, or how much your hands itch to start coding for a new project. Finishing off what you've started is more important

        Any average PM will tell you why it is important to keep your enthusiasm in control to finish of your current goals.

        Yea, and any average PM would also tell you that in order to get some long term project done, you need to get people motivated. Most of (all?) the people working on Perl 6 does it just for fun, and they are entitled to do whatever they want with their free time and follow the path that betters suits their guts.

        If you don't like that, start sending money to the project so we can change the motivation factor from fun to money. Or just contribute your time and do that parts that you thing that should be done now.

        Otherwise, just shut up, please!

        You absolutely didn't have to start work on Moar VM at all.

        MoarVM gave us speed. It is like 3 to 5 times faster to recompile the compiler which helps the devs a lot. Especially spectesting within 6 minutes is way nicer than waiting 30 minutes or more.

        MoarVM also gave us concurrency on the same fast VM, and also Unicode introspection. There is no other VM that can do that now or within, say, a few months. So IMO the decision to create MoarVM was a very very good one.

        Instead we now have a situation where the spec needle hasn't moved a degree on the completion meter...

        Not true. And you just have to look at this graph: https://github.com/perl6/specs/graphs/contributors S11 and S22 get completed (module versioning, cpan, etc). The specs for concurrency got written (S17) and S15 (strings and unicode) is now in a very good shape.

        List of things to be done should have been To make Rakudo spec complete, faster, with documentation and standard libraries. And in that order.

        In some areas it is very hard to spec something without a way to play with it. Like for concurrency. It was very helpful to have a sort of working implementation to play with, then spec how it should look like and then adjust the implementation. That happened within the last ten months I think.

        I know how all of this is going to play out eventually. Another year from now. Rakduo as-is now, will run on Moar VM while there will be few more new projects to port it to dozen other VM's.

        I know the devs very well (hey, I am one of them), and I can say that there won't be dozens of VMs that get targeted within near future. There was a GSoC project to target JavaScript last year, and I do not see any other VM that would give Perl 6 such a benefit that would trick one of the devs into working on it. Surely there are "outsiders" that try to make it run on other VMs like luajit, but there is also RPerl and Perl5i that does not trick any of the Perl 5 devs into working on it...

        And well yeah coming to the project management part. Any average PM will tell you why it is important to keep your enthusiasm in control to finish of your current goals. No matter how tempting new projects feel, or how much your hands itch to start coding for a new project. Finishing off what you've started is more important

        +1

        Don't waste your time. #perl6 is convinced that the only way to get a working perl-6 is to do it exactly as they have done it. Er, haven't done it yet.

        They are just misunderstood geniuses to whom the rules of project management could not possibly apply.

      Do you honestly think it even matters anymore?

      Jenda
      Enoch was right!
      Enjoy the last years of Rome.

      It couldn't be any worse than what you have, at least since you drove off Nat, Allison, and Jesse.

      How about that! If your project is so broken that it's burned out THOSE three brilliant people, maybe there's something fishy going on.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://1082245]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others studying the Monastery: (6)
As of 2024-04-23 16:56 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found