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.

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.

(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 :)

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.

"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.

We?

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.

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

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.

... 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 second [id://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?

That sounds like a really interesting poll question - why not submit it to poll ideas quest (read How do I create a Poll? first, though)?

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

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

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...

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.

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.