Beefy Boxes and Bandwidth Generously Provided by pair Networks
Pathologically Eclectic Rubbish Lister
 
PerlMonks  

No, "We" Don't Have to Do Anything

by chromatic (Archbishop)
on Feb 23, 2006 at 01:51 UTC ( #532137=perlmeditation: print w/ replies, xml ) Need Help??

In Re^3: Building Perl6, brian d foy said:

If we're still designing Perl 6, we're in pretty bad shape.

Now I know brian and I know what he contributes, so this is not a rant aimed at him in any sense of the word. However....

<pet_peeve>We?

One of the most difficult lessons for me to learn from Perl 6 is that people who don't contribute can have all of the opinions they want... but they don't matter.

They can watch the project. They can complain. They can even use the code at any point. They can take the ideas and discussions and learn about what Perl 6 will do or use the ideas in their own projects.

They just don't have any right to expect that they deserve any attention from the people actually contributing.

That's not to say that Perl 6 has taken a long time or that Parrot hasn't have (or doesn't have) problems or that Pugs is good or Pugs is bad or that there's ever been a schedule or ever will be a schedule or anything like that.

It's just that the doors are wide open for people to contribute code, documentation, tests, money, time, ideas, questions, suggestions, hints, and requests in several media. It seems like a minimum standard of courtesy to attempt to contribute in some way before saying "We should..." and "We ought to..." because, frankly, as one of the we I'm doing this for fun and being told what to do by someone who's never even used the code and given feedback is pretty close to the opposite of fun.

There you go: this is the so-called big, unspoken problem with Perl development (Perl 5 and Perl 6). It's not fun for the handful of people actually doing the work, especially when they so rarely hear "Thank you for all of your hard volunteer work" and so often hear "This isn't what I want", "This is taking too long", "You should do what I want how I want right now", and "Why aren't you paying attention to meeeeeeee?"

See MakeMaker. See Module::Build. See the CPAN. See a whole pile of pumpkings. See a hundred other people and projects.</pet_peeve>

Comment on No, "We" Don't Have to Do Anything
Download Code
Re: No, "We" Don't Have to Do Anything
by zshzn (Hermit) on Feb 23, 2006 at 02:13 UTC
    I can imagine how difficult the project is and the pressure it brings. So for what it is worth, I for one will begin to repent for my few criticisms now.

    Thank you for all of your hard volunteer work, everyone working on Perl 6.

Re: No, "We" Don't Have to Do Anything
by spiritway (Vicar) on Feb 23, 2006 at 03:20 UTC

    I second zshzn's comment - thanks for all your hard work in creating Perl 6 - thank you to all the volunteers who are working on it, and thank you to all the people who made Perl 5 what it is. You've created a product that has brought me much enjoyment and fun, as well as turning out to be highly useful for me. I'm not a professional programmer, so 'useful' wasn't on my list. But Perl has proved to be quite useful to me for many tasks that would otherwise have been tedious or even impossible for me. So yes - THANK YOU!!

      I'm not a professional programmer
      That's funny, I tend to see this remark a lot here on Perlmonks.

      I wonder what percentage of people here, are professional programmers, have some other occupation, or are still students... An idea for a poll, perhaps?

Re: No, "We" Don't Have to Do Anything
by Cap'n Steve (Friar) on Feb 23, 2006 at 03:35 UTC
    "One of the most difficult lessons for me to learn from Perl 6 is that people who don't contribute can have all of the opinions they want... but they don't matter."

    Maybe I'm misunderstanding you, but how is submitting your opinion not contributing? Not all of us know other languages, and even those who do might not be able to grasp the complexity of the Perl interpreter.
      ... how is submitting your opinion not contributing?

      Maybe so, but...

      "I don't like the syntax changes." is a useless contribution.

      "It's taking too long." is a useless contribution.

      "I don't want to rewrite my code." is a useless contribution.

      "Parrot is stupid." is a useless contribution.

      "Pugs is too slow." is probably a useless contribution.

      "Ruby/Python/Java/C#/Scheme/SNOBOL/Smalltalk/Lisp/hq9+ does that already and you are losing marketshare." is a useless contribution.

      "Coroutines and continuations are too hard." is a useless contribution.

      "I don't understand part of the synopsis here", "Hey, here's a little patch for a TODO item", and "I don't have time or energy or expertise to contribute but I'm looking forward to the results and appreciate all of your hard work" are useful contributions.

        I'm assuming you're a volunteer (at least I didn't think anyone working on Perl6 was getting paid).

        Actually these are all valuable contributions. Let's look at each one...

        "I don't like the syntax changes."
        What you've done is confusing and counter-intuitive. Even though you're writing it, you have to take into account who will actually be using it. Take a step back and think how the syntax could be made better.
        "It's taking too long."
        If you can't do the job, perhaps it is better if you let someone else do it. Maybe you really don't enjoy what you're doing or just don't have the time. You'll be a much happier person if you stop Maybe you feel like you can't b/c of some sense of duty or something. You have a duty to quit if you're keeping more productive people from working on the project. Also if the project is truly useful, someone else will step up and take care of it.
        "I don't want to rewrite my code."
        Except in very rare cases, code shouldn't have to be rewritten just b/c you upgrade. Clearly you've done something that breaks people's existing code. You need to go back and make sure it does not break existing code.
        "Parrot is stupid."
        Ok this is borderline unhelpful. Ask the person for specific reasons. If a number of people are saying this, then you should consider not using it. Again you need to thing of the people who will be using your product.
        "Pugs is too slow."
        If it is too slow, it needs to be made faster or you need to find another solution.
        "Ruby/Python/Java/C#/Scheme/SNOBOL/Smalltalk/Lisp/hq9+ does that already and you are losing marketshare."
        You really don't need to waste time developing something that you can do else where. If you insist, at the very least check out the other implementation see what its strengths and weaknesses are and try to improve it in your implementation.
        "Coroutines and continuations are too hard."
        You've made something overly complex again. Smart people tend to do this a lot. To be truly brilliant, you have to be able to make complex things simple.

        Now lets look at what you consider useful...

        "I don't understand part of the synopsis here"
        This isn't much different from the above. They're saying they don't understand what you've written. Just like they're saying some you've done is "too hard" or counter-intuitive. If this is considered helpful then the earlier comments also need to be considered helpful.
        "Hey, here's a little patch for a TODO item"
        True, this is by far the most useful. Hopefully they haven't done some really weird stuff and made it too slow or require to you rewrite some of your code.
        "I don't have time or energy or expertise to contribute but I'm looking forward to the results and appreciate all of your hard work"
        This is quite rewarding, but you won't get thanked unless you deserve it. Judging from your attitude, I suspect you're the kind of volunteer who is doing only a mediocre job and preventing someone who can do better from working, because you're claiming you've got it covered. If people aren't thanking you it is time to reevaluate your contribution to the project and your commitment to it. You may just need a break from it or you may need to totally separate yourself from the project.

        I've been involved in a local service club for the last 5 years. Burn-out has a number of symptoms. However the most common I've seen is that the volunteer starts to demand to be thanked and believes only he can do his job. Your posting definitely indicates these signs of burn-out.

        Your volunteer coordinator needs to take immediate action and move to you another more interesting project. He also needs to have a good long talk with you and figure out what you get from volunteering and how the new project can give that to you.

        It may not be possible for you to get what you are looking for. If that is the case, then the coordinator needs to realize this and encourage you to spend your time else where. While he may desperately need your help, someone so full of negative energy will only drive away other volunteers and doom the project. It is tough for everyone involved to realize that an individual who has been involved in the past, may not be able to contribute anymore.

        However the sooner it is done the better for all involved. The volunteer will be out of a situation filling him with negative feelings, other members of the group will no longer have a negative person among them, and someone new will step forward and do the work. Everyone will be happier. And like I said, maybe you only need a couple of months off and can come back refreshed and ready to contribute again. But no worries if you don't come back. You've contributed something and it might be time to move on.

Re: No, "We" Don't Have to Do Anything
by dragonchild (Archbishop) on Feb 23, 2006 at 03:42 UTC
    While I haven't contributed to the P6 discussion for a while (thus, have no comment), this pet peeve is one that's shared by CPAN developers as well. Over the years, I've received a lot of "This is busted" bug reports. As I use nearly all my modules and it was broken, it's obviously a situation I hadn't run into yet. (If I had, it wouldn't be broken now, would it?!)

    Since it's a situation I hadn't run into, what's the incentive for me to write the failing test that keeps the problem from returning? I'm not the one with the bug ... you are. The code is failing your expectations, not mine. By writing the failing test, you are forcing me to look at the bug. More importantly, you've given me a repeatable yardstick by which to measure my progress.

    One of the biggest reasons Pugs such a success is because the developers of Pugs don't write tests. (Audrey is actually (in)famous for not writing them, much to my dismay.) They have a legion of test-writers who contribute hundreds and hundreds of failing tests. It is so much easier to write code to pass a series of tests than it is to write code that is just wandering out into the blue.

    Moral of the story: If you don't like something, write a failing test. Let that be your bitchfest.


    My criteria for good software:
    1. Does it work?
    2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
      While I haven't contributed to the P6 discussion for a while (thus, have no comment)...

      Even if you had only ever posted a question to p6l or asked a question in a talk, that counts as a contribution and your opinion would carry some weight.

Re: No, "We" Don't Have to Do Anything
by thor (Priest) on Feb 23, 2006 at 05:03 UTC
    We?
    Yes, we. One of the huge strengths of Perl (in my opinion) is the community behind it. Once you start breaking things down into "the cool kids" and "losers" (as you're doing above), that community is divided into the haves and the have nots. I think brain d foy has a good point: I don't think as many people are attempting to bully the perl6 process, but I do think that people want a more transparent view into the overall progress of the project. I count myself in the latter group.

    To further expound on the problem as I perceive it, I'm going to go looking for a project summary. I'd assume that an at-a-glance summary would be located here. I'd be wrong. I'll keep looking. Only because I remember the fervor surrounding apocalypses, exegeses, and synopses when this whole thing started, I thought that that might be a good place to start looking for at least the design documents. There are eight apocalypses (number non-contiguously might I add, implying that there are some missing), six exegeses (again numbered non-contiguously), and twelve synopses (more of the same). Okay, so we don't seem to have a complete design available to the public. But maybe there's hope. Maybe there's something like this (admittedly a little out of date) for perl6. A line by line list of tasks and their associated completion. I don't think I'm that bad at searching, but I didn't find it.

    How can anyone know what to work on without a list of items trying to conform to a seemingly incomplete specification? Especially when coordinating with people solely via e-mail often many timezones apart. Maybe it works for you, but it seems to me that it'd be a reciepe for miscoordination and duplication of effort. I don't mean to be hard on a purely volunteer workforce for something that I'm sure to get great utility and enjoyment out of, but that's what I (and probably a lot of others not "in the know") see. It's also hard for me to try to contribute to something that I see as being that chaotic. I want to help, I really do. The whole things seems way too overwhelming. You guys are obviously better at keeping many more balls in the air than I am. Lower the barrier to entry and not only will you help yourself in so far as becoming a little more organized and efficent, but perhaps lurkers like me will come out of the woodwork and lend a hand.

    thor

    The only easy day was yesterday

      One of the huge strengths of Perl (in my opinion) is the community behind it.Once you start breaking things down into “the cool kids” and “losers” (as you're doing above), that community is divided into the haves and the have nots.

      Gary Lawrence Murphy, “Barnraising your IT”:

      Say your community shows up to build you a barn, and you sit on the porch drinking lemonade, criticising their carpentry and pestering them for a completion date, well, just how ludicrous is that scenario? Yet this is exactly what we are doing when we sit back like some ancient king, expecting free software served to us, taking what we need, giving nothing in return except maybe money… or “advocacy.”

      People who do not contribute are not “community.” And note that I (and, I’d assume by his posts, chromatic) use a very non-exclusive definition of “contribute” here. Anyone with 10 minutes of time can do something useful. There are no haves and have-nots, there are only those who drink the lemonade themselves vs. those who offer some to those building their barn.

      (Update: I missed saying that this is not to say anything about how easy it is to contribute 10 minutes to Perl 6. But just attempting to do so and then outlining why you had a hard time doing it is in itself a contribution – which goes to show that all you need is the will to help.)

      Makeshifts last the longest.

        Say your community shows up to build you a barn, and you sit on the porch drinking lemonade, criticising their carpentry and pestering them for a completion date, well, just how ludicrous is that scenario? Yet this is exactly what we are doing when we sit back like some ancient king, expecting free software served to us, taking what we need, giving nothing in return except maybe money… or “advocacy.”

        That analogy is somewhat flawed, because "I" am not the only one to benefit from the barnraising. It's more like a town that decides to build a communal barn that everyone can use (or some other civic project), and everyone is invited to help out. Not everyone is qualified to help build the thing, and in fact, some who try are likely to be in the way.

        I'd certainly love to help out with Perl 6, and I'm sure many others would. Unfortunately, I'm like one of the people who would just get in the way, not understanding how it's done, making clumsy efforts that would just take up someone's time to check it out and find out it's not useful, not really having a clue about the guts of perl.

        The fact is, I haven't even learned Perl 5 well enough to know where its deficiencies lie - (assuming it has any ;-) ). Most of what appears to be needed seems to require considerable technical knowledge. So yes, I feel I would better serve this effort by sitting on the sidelines and at least not interfering.

        Of course, I could also just keep my mouth shut about any putative schedule, and not try to tell folks how to go about writing this massive project. The least I can do is get out of the way and let others work... and to say "Thanks" on occasion.

        Say your community shows up to build you a barn, and you sit on the porch drinking lemonade, criticising their carpentry and pestering them for a completion date, well, just how ludicrous is that scenario? Yet this is exactly what we are doing when we sit back like some ancient king, expecting free software served to us, taking what we need, giving nothing in return except maybe money… or “advocacy.”

        That's fine, as long as everyone knows what a barn is, and how to build one. That's not what we have: we have a bunch of people trying to build "a language", from specs that are full of "perhaps" and "maybe".

        Some of the people are hard at work looking to source marble for the Ionic Columns where the bulls will get sacrifice to Apollo, and some are trying to source cedar and silks for the nesting boxes for the Rookery, and some are hard at working forging metal bars to build the cages for the lions, and some are out in the fields trying to catch rabbits so the barn will have some animals. No one knows if they're building a Temple, a Rookery, a Zoo, a rabbit hutch, or all of the above.

        And some of the people are sitting on the porch, sipping lemonaide in bemusement, trying to figure out what's going on, who's in charge, and what's actually going to be built.

      To further expound on the problem as I perceive it, I'm going to go looking for a project summary.

      Good detective work, thank you! That's something that the project needs and something that those of us who've been around for a while wouldn't have gone looking for ourselves. I'll bring that up and we'll figure out something.

        Just curious, but did anything ever come of this?

        thor

        The only easy day was yesterday

Re: No, "We" Don't Have to Do Anything
by brian_d_foy (Abbot) on Feb 23, 2006 at 05:48 UTC

    (I know chromatic's not really talking about me..., or at least I hope he's not :)

    I thought about not using "we", but I decided to take on some of the blame. I was one of the original people in the room when we decided to do Perl 6. I was the guy who was supposed to work on promoting Perl 6 to the wider community.

    I left the project when I realized that there wasn't a plan, people didn't want a plan, and we were basically marketing hype hoping that someone would come up with an implementation. We called it "the community's rewrite".

    Since then, I've contributed in much more quiet, behind the scenes ways not directly related to the development. I'd still like to get a Perl 6 article into The Perl Review, but people haven't had interesting things to say about it (that we haven't heard before).

    I'm not complaining about the Perl 6 process or how much we've accomplished. I'm ready to support whatever Perl 6 turns out to be. I'm not telling anyone what they should do to implement Perl 6 or what features should be in it. I'm ready to publish about it, write books about it, promote it, and so on. I'll gladly cheerlead whatever Perl 6 is. I'm ready to do my part (the same part I was going to do officially), but outside of the proper project.

    My problem is people pretending that the process is working well and that people asking what's going on are complainers we should ignore. If you're producing something for other people to use, you should pay attention to your user base. Otherwise, use Python :)

    --
    brian d foy <brian@stonehenge.com>
    Subscribe to The Perl Review
      "If you're producing something for other people to use, you should pay attention to your user base."

      I think that's actually a major weakness of open source software in general. I've never been involved in Perl development (waaaay out of my league), but I've seen several other projects where the developers seem to have gone a bit power-mad, ignoring suggestions and even bug reports that have somehow offended them.

        There’s a balance to be struck. If you say yes to everything, you end up making unusable incoherent bloatware. Design is difficult, and committees do it horribly, because it is mostly about leaving out everything that isn’t appropriate. As Linus Torvalds says, his biggest job is saying no to new features.

        But I don’t dispute that few projects find the right balance.

        Makeshifts last the longest.

      There are some FOSS projects that have well defined leaders ... namely the Linux kernel (still feudal in many ways), Python (Guido), and Ruby (Matz), and in general benevolent dictatorship can be a good steering force. Larry did a good job being insert-Diety-here too. Perl 6 appears to still be in commitee, which, for good or bad. The real software engineering question is this: can projects designed en masse like Perl 6 arrive at a workable consensus?

      The current examples going through my mind now are industry standard things like Bluetooth, CIM, and W3C's WSDL/SOAP/etc ... quite the antithesis of our favorite software products in terms of simplicity and transparency.

      Not making a comment either way, just thinking... these things took a long time to evolve and still haven't stabilized, while in general projects with a strong guiding lead (not dictator) have a better chance of communicating vision and bringing contributers in.

      For the percieved "people are complaining" problem chromatic is complaining about to stop, you need good external organization and a way for those people to contribute, rather than just trying to make heads-or-tails of a mailing list, which they'll subscribe to, get confused, and eventually leave. And better defined leadership, timetables (however long), and better laid-out goals help too.

      Finally, don't alienate your critics. They're telling you something. First and foremost, they want your product.

Re: No, "We" Don't Have to Do Anything
by Anonymous Monk on Feb 23, 2006 at 23:23 UTC
    Let's make a deal, then.

    If people stop hyping Perl 6 as if it's wonderful and something I absolutely should start learning, then I'll stop critizing it.

    You can't have it both ways. To hear the people working on the project talk, Perl 6 will be the greatest thing since sliced bread, it will slice, dice, and make jullianne fries, all while solving world hunger, and by the way, it will be out real soon now.

    In reality, the spec isn't complete, the language has been under development for years with little sign of completion, and the hype is overblown.

    It's hypocrisy to tell people that they need to start learning a system that's incomplete, and fragile, and then make promises about the future of that system that you don't intend to keep.

    So, don't tell me about Perl 6 until it's done. Then, if it's any good, I'll learn your silly language. Don't bug me until then, stop shoveling hype and empty promises at me, and then, if what you've done is good, you'll get your praise and your thanks, with a deep measure of gratitude thrown in as well.

    Bitching at people who complain about how long it takes is a lot like promising free coffee and donuts for a grand opening, then serving dirty dishwater and burnt toast instead, and griping at the people for being freeloaders when they came by to see what you had on offer and didn't like it. Yes, people thought they might get something nice for free. No, you don't owe them anything -- except the truth.

    Wake me up when Perl 6 is done. Leave me alone until then. If it never finishes, I just won't care...

      If people stop hyping Perl 6 as if it's wonderful and something I absolutely should start learning, then I'll stop critizing it.

      You misunderstood me. Criticize all you want. Just don't expect anyone actually contributing to the project to care. As far as I can tell, none of us have any obligation to do so.

      If you're not willing to spend ten minutes (in the past five years, you really couldn't spare ten minutes?) making some minimal effort to contribute, I don't consider you a part of the community.

        If you're not willing to spend ten minutes (in the past five years, you really couldn't spare ten minutes?) making some minimal effort to contribute, I don't consider you a part of the community.

        *sigh* Where did that "ten minutes" number come from? It takes a lot longer than that just to read and absorb a single Apocalypse. I read as many as I could for a long time, and tried to work out what they all meant behind all the fluff and ambiguities. They are, or were, riddled with the words "perhaps", "maybe", "might", and "could be". I didn't know then, and I don't know know, what features would make it into the final cut.

        Eventually, I gave up. I realized that the details of the Perl 6 language specifiction were still in flux, so I waited for the designers to make up their minds, and produce a clear vision of exactly what it was that I'd be building, if I decided to get onboard and help them build it.

        I never found one. Eventually, I stopped looking for one. From the complaints I'm hearing now, it sounds like there never was one.

        All through the years, the hype continued. The "ten minutes of your time" thing is just more hype: you and I both know it takes more than ten minutes to do anything even remotely productive. People are saying: "Perl 6 is ready now", "you can run Perl 6 programs under Perl 5 today", and stuff like that; but I still haven't seen the language documentation. To me, that means nothing's really been settled yet, and the whole thread seems to bear that out.

        Perhaps, some people can stand working like that. Maybe they're colledge kids who grasp at any chance to write throw-away code for the fund of coding something. Me, I do far too many pointless re-writes thanks to shifting requirements at work; the only thing worse than wasting my time for pay is wasting my time for free.

        Go ahead -- build Perl 6 however you want. Just stop trying to recruit me... I've burnt out on all the hype.

      What a load of crap. Nobody's forcing you to listen to the hype in the first place. And how are we supposed to recruit volunteers to work on the project without talking about our dreams, realistic or not? How can we know whether they're realistic until we try? How can you label our dreams as "empty promises" when so many of us are still pouring our hearts and souls into implementing whatever part of it is realistic, and when many of us have been ever so careful to remind people again and again that it'll be done when it's done? How can you claim you don't care when you put so much effort into griping?

      Bah...

        What a load of crap. Nobody's forcing you to listen to the hype in the first place.

        Sure, in the sense that no one's "forcing" me to look at billboards while walking downtown. But I still see them, and it's not really optional. The only question is how much attention I'll pay them, and how hard I'll work to mentally screen them out. The same applies to the Perl 6 hype that so often materializes in Perl 5 discussions. It's about as easy to ignore as a Jehova's Witness. :-(

        And how are we supposed to recruit volunteers to work on the project without talking about our dreams, realistic or not?

        Volunteers aren't the first step. Deciding what you're going to build is the first step. Making sure you can build it is second. Getting a big group of people together to do the work happens last, once you know what the work is. Isn't that just basic engineering?

        How can we know whether they're realistic until we try?

        Careful engineering analysis? What problem are you trying to solve with the tool you intend to build? Does your design actually solve that problem? Can your design be implemented with the resources available? What clear and tangible metric will you use to evaluate the success of the project?

        How can you label our dreams as "empty promises" when so many of us are still pouring our hearts and souls into implementing whatever part of it is realistic,

        Effort is a fine thing. Directed effort with a firm goal in mind is better. Results that match what has been promised are best.

        and when many of us have been ever so careful to remind people again and again that it'll be done when it's done? Unfortunately, even more people have not.

        How can you claim you don't care when you put so much effort into griping?

        Well, I do care, a little. Perl 6 affects my job, my future, my career by sheer virtue of existing as a project in the Perl 5 sphere. It affects where people put effort with regards to Perl development, and what managers expect. To some extent, thanks to ugly network effects, I have to care, whether I want to or not.

        For the most part, though, I don't. Yes, I see things I like in Perl 6. I also see things I hate. I don't know whether any or all of those proposed features will actually get implemented, and so I don't know if I should support or condemn the language; I'd just as soon ignore it, reserve judgement, and see what gets built in the end. That's what I try, but it hasn't been working; I still get people telling me: "that'll be fixed in Perl 6"; "try Perl 6: there's Pugs out already", "Perl 6 is almost done".

        I'm just tired of all the hype (as I pointed out in another post). And when you have to defend a project based on "dreams", rather than solid engineering practices, can you really wonder that it's developed so slowly and so poorly? Emotions, dreams, and feelings don't build results; objective analysis, careful design, and rigourous implementation do.

Re: No, "We" Don't Have to Do Anything
by nothingmuch (Priest) on Feb 24, 2006 at 13:40 UTC
    I hope my infamous rant on p6l did not contribute hay to break your camelback.

    Anyway, well said, ++, thank you and so forth. =)

    -nuffin
    zz zZ Z Z #!perl

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://532137]
Approved by atcroft
Front-paged by liverpole
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others cooling their heels in the Monastery: (8)
As of 2014-07-24 06:56 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (158 votes), past polls