You Want to Talk About The Elephant in The Room? Fine.

chromatic on 2006-02-28T02:25:14

Damian recently gave a talk in Australia about the lessons learned from the wearying Perl 6 project. I've been a cabal member for only three years, but one of my lessons is The Opinions of People Who Do Not Contribute Do Not Matter.

Any ambitious idea that makes it past the idea stage to an actual implementation will likely attract all sorts of fans and foes. If you've paid attention to Perl 6 (or Perl 5) you've likely seen the numbingly-repeated claim from one person or another that "I don't really care about Perl 6, but I'll tell anyone who might possibly listen to me that the project has BIG PROBLEMS and NO ONE BESIDES ME wants to talk about them." (Not a direct quote; I cut out some profanity.)

I'm pretty sick of hearing that. Here's the deal. Here's the real problem with Perl 6.

There aren't enough people to do the work.

Go through the list of top contributors to the design or to Parrot or to Pugs. Make a list of all of the people working full-time and fully funded. I'll wait.

Short list, isn't it?

If you want to do a bit more research, make a list of all of the potential man-years that the project could have had over the past five and a half years for all of the contributors. Then make a list of all of the actual funded man-years.

If you still feel like complaining that you're not getting a world class successor to and immense improvement upon Perl 6 on your preferred schedule for free and that the small army of volunteers isn't doing exactly what you want when you want, hey -- you have that right.

Just don't expect anyone who's actually done something useful to care. (Don't expect to pass off some half-formed opinion as if it were complete and utter truth in my presence without me asking for some sort of fact to back up your talk, either. Maybe I won't say anything. Maybe I will. If someone said stupid things about something you cared about and put a lot of time into for the betterment of humanity or at least some small part of it, you might care a little bit too.)

There's your elephant. Any questions?

Update: See also dragonchild's Why Perl 6 is Taking So ... Long.


Weary? Yes.

Ovid on 2006-02-28T02:46:05

I freely confess that I'm one of the folks tired of waiting for Perl 6, but not because I think it's being handled particularly poorly or that folks aren't working hard enough. It's just that after years of waiting, I want to something I can use in a production environment. Yes, mistakes have been made here and there (and there and there), but the people involved are human and people should be more willing to forgive.

Having seen just a little bit of what's going on with Parrot and Perl 6, I'm actually quite happy that the project is still very much alive. It's a testament to the will of those driving the project that it's still there. And for those of us who still believe in in (most of us, I suspect), it's because we've seen what Perl 6 is trying to do and we really, really want it.

I've been hearing for a few years that Perl 6 will never see the light of day. I confess that I inwardly bristled at the comments and couldn't understand why people were saying that. Having seen things up close, I now understand why they're saying that, but I still think they're wrong. I am very grateful that you and many others are still willing to put in so much time and effort despite the armchair quarterbacks.

Thanks to everyone for hanging in there. I'm not the sort to say "I told you so", but when Perl 6 comes out, I will this time. Loudly :)

related?

modred on 2006-02-28T11:50:26

You don't think that the feeling of "no one wants to talk about problem X" and "There aren't enough people to do the work." are related?

Or how about the barriers to entry to help out? Real or perceived I've noticed a definite feeling of "I would never deign to tell $perl_deity that $x is wrong. $perl_deity is so much smarter than me"

Barrier to entry?

Crag on 2006-02-28T17:06:13

"I would never deign to tell $perl_deity that $x is wrong. $perl_deity is so much smarter than me"

That doesn't sound like a barrier to entry for helping out, that sounds like confusion about what the words "wrong" and "smarter" mean. If someone sees some '$x' they think is a problem, then either they're haven't researched it enough, or they are wrong and the documentation isn't clear enough about why, or they're right and the problem needs attention. As far as real barriers, there is no social barrier to helping out with Pugs. Audrey hands out commit bits like a drug dealer drumming up more business. Pugs seems like the ideal place to get started if one wants to help out. Once a new helper has familiarized themselves with Pugs they can easily move on to other areas.

Re:Barrier to entry?

Eric Wilhelm on 2006-03-18T04:45:23

"Audrey hands out commit bits like a drug dealer drumming up more business." LOL!

If only there were more pushers, and maybe some money changing hands.

I must confess that I have not been involved in Perl6 as much as I would like. I have enough demons as it is and not enough daemons.

Re:related?

chromatic on 2006-02-28T18:48:02

If by some chance you consider me a Perl deity (guru maybe, if you squint at Nat's Seven Stages chart and ignore a few steps), then please feel free to tell me I'm wrong. I write about Perl more than most programmers, so the volume of my opinions makes it likely that I'll be wrong often.

Re:related?

Alias on 2006-03-18T04:45:36

Indeed, you shouldn't hold back.

I tell him he's wrong all the time, and the result has (mostly) been better code. :)

Re:related?

Damian on 2006-02-28T22:17:13

I would never deign to tell $perl_deity that $x is wrong. $perl_deity is so much smarter than me.
As someone whose specific job it is to tell Larry when I think he's wrong, I can certainly empathize with that trepidation. ;-)

But I can also tell you that bona fide @perl_deities are smart enough to know that they're not always smart enough. And humble enough to welcome corrections when they're needed.

The thing I've found most useful (both in telling someone else they're wrong, and in being told myself) is to do it in the right spirit and in the right tone. In particular, to be non-confrontational and specific.

That is, instead of:

"Your plans to make public attribute variables polymorphic are a disaster. I can't believe you're willing to wreck the entire OO model with this assinine decision! Please reconsider this egregious blunder."
say something like:
"I read about the decision to make public attribute variables polymorphic and I had some concerns about it. It seems to me that polymorphic attributes variables will be prone to many of the same problems that tied variables can produce. Specifically, that they introduce a risk of very subtle bugs in very common kinds of OO code, bugs that can only be found at runtime from derived classes and in unusual circumstances. For example:

(give specific example here)

Maybe I'm missing something obvious, but isn't that kind of mistake going to trip up a lot of ordinary programmers, who almost certainly won't be expecting covariant behaviour from a implementation feature such as an attribute variable?"

You'd be amazed how grateful people can be when their genuine mistakes are pointed out to them in a constructive and courteous manner...especially by correspondents who recognize the possibility that the defect might not be in the idea itself, but rather in the exposition of it.

Re:related?

sigzero on 2006-03-01T02:37:54

Here is a rule I live by that the Marines taught me. Never bitch unless you have at least two suggestions for improvement.

Re:related?

Alias on 2006-03-18T04:47:26

Oh neat, I specifically like the "at least 2" part.

(adds it to his "unless you have a better way, and are willing to do the work if you have to")

Whoa there, note quite...

mrjoltcola on 2006-03-27T16:50:29

1st let me say I DO have a right to spout because I, for one, actually did write a large portion of Parrot from 01 to 04.

>There aren't enough people to do the work.

Chromatic, you are only half right, or maybe you are right now, but retroactively wrong. There WERE enough people to do the work. Dan left after I left for the same reason that I left. People issues. Leo is very likely a great guy, in person, but he was hard to work with, and he was just plain rude over email. So now he is the patch monster with full reign.

When you come along and join an open source project, and stand on other folk's shoulders, there is an important thing to bring with you, respect and courtesy, especially to those who wrote the "poor mess" that you are trying to improve upon. There was a distinct lack of this going on, and I'm not the only one that dealt with it.

That is the real elephant in the room, IMO, but only the original coders knew about it because it was kept off list.

Parrot, grandiose? I don't think so. A huge mess, yes. If you want specifics, I can go into them, but what everyone touts as grandiose design is simply not so. Continuations are not so big a deal, as I initially implemented them in a matter of hours. People tout this as one of Parrot's grand design decisions, but I don't agree. That is a point of view from the outside looking in. The real problem was lack of comradery, teamwork, communication and respect. None of that is technical, but the effect it had was to reduce the number of technically capable people who care to help.

Thanks for bringing up the subject, though. :)