Recently in Opinion Category

Perlbuzz news roundup for 2012-06-04

| No Comments

These links are collected from the Perlbuzz Twitter feed. If you have suggestions for news bits, please mail me at andy@perlbuzz.com.

  • Perl for Big Data: "Hadoop is overrated. Come see what modern Perl can do." (blog.yapcna.org)
  • Why I use Perl: Reliability (modernperlbooks.com)
  • Any language would be improved if it had Perl's testing and library culture. (news.ycombinator.com)
  • Artistic License 2.0 means you don't need any dual-licensing or "same terms as Perl" boilerplate. Just use Artistic 2. (perlbuzz.com)

Perlbuzz news roundup for 2012-02-20

| No Comments

These links are collected from the Perlbuzz Twitter feed. If you have suggestions for news bits, please mail me at andy@perlbuzz.com.

Mark Jason Dominus on giving fish

| 4 Comments

By Mark Jason Dominus, from a talk in 2003, reprinted here with permission. Sadly, it's still relevant today.

The #perl IRC channel has a big problem. People come in asking questions, say, "How do I remove the first character from a string?" And the answer they get from the regulars on the channel is something like "perldoc perlre".

This isn't particularly helpful, since perlre is a very large reference manual, and even I have trouble reading it. It's sort of like telling someone to read the Camel book when what they want to know is how to get the integer part of a number. Sure, the answer is in there somewhere, but it might take you a year to find it.

The channel regulars have this idiotic saying about how if you give a man a fish he can eat for one day, but if you teach him to fish, he can eat for his whole life. Apparently "perldoc perlre" is what passes for "teaching a man to fish" in this channel.

I'm more likely to just answer the question (you use $string =~ s/.//s) and someone once asked me why. I had to think about that a while. Two easy reasons are that it's helpful and kind, and if you're not in the channel to be helpful and kind, then what's the point of answering questions at all? It's also easy to give the answer, so why not? I've seen people write long treatises on why the querent should be looking in the manual instead of asking on-channel, which it would have been a lot shorter to just answer the question. That's a puzzle all right.

The channel regulars say that answering people's questions will make them dependent on you for assistance, which I think is bullshit. Apparently they're worried that the same people will come back and ask more and more and more questions. They seem to have forgotten that if that did happen (and I don't think it does) they could stop answering; problem solved.

The channel regulars also have this fantasy that saying perldoc perlre is somehow more helpful than simply answering the question, which I also think is bullshit. Something they apparently haven't figured out is that if you really want someone to look in the manual, saying perldoc perlre is not the way to do it. A much more effective way to get them to look in the manual is to answer the question first, and then, after they thank you, say "You could have found the answer to that in the such-and-so section of the manual." People are a lot more willing to take your advice once you have established that you are a helpful person. Saying perldoc perlre seems to me to be most effective as a way to get people to decide that Perl programmers are assholes and to quit Perl for some other language.

After I wrote the slides for this talk I found an old Usenet discussion in which I expressed many of the same views. One of the Usenet regulars went so far as to say that he didn't answer people's questions because he didn't want to insult their intelligence by suggesting that they would be unable to look in the documentation, and that if he came into a newsgroup with a question and received a straightforward answer to it, he would be offended. I told him that I thought if he really believed that he needed a vacation, because it was totally warped.

Mark Jason Dominus has been doing Perl forever. He is the author of Higher Order Perl which belongs on the shelf of every Perl programmer. Follow him on Twitter at @mjdominus.

There's only one useful way to handle your detractors

| 4 Comments

This is a repost from my main blog, but it applies to all of us working on Parrot and Perl 6. Keep on keeping on, ignore the trolls, and keep moving forward to completing the vision.

Here's a Reddit/Slashdot/whatever thread that never happened:

Internet crank on Reddit: "Hey, Steve Jobs, I guess that new iPad looks cool, but I think iPad is a stupid name, it makes me think of sanitary napkins."

Steve: "Yeah, well, here's why we called it that. (Long explanation justifying his choices)"

Crank #2: "Well, why didn't you call it the iTablet? I think that would have been a good name. What does everyone else think?"

Crank #3: "What does it have to be iAnything? I'm tired of the i- prefix."

Steve: "We thought about that, but ... (More explanation about his choices)"

Crank #1: "And really, isn't it just a bigger iPod Touch? I would never carry that around with me. And come on, you're just trying to redo the Newton anyway LOL"

Steve: "My logic behind the iPad is (vision, business plan, blah blah blah)"

Can you even imagine Steve Jobs in this sort of time-wasting and emotionally draining tit-for-tat in a thread on Slashdot? On reddit? In some blog's comment section? Of course not. Justification of his plans would take away from the amazing things that he needed to achieve.

Naysayers are part of every project. How many people do you think pissed on Jimmy Wales' little project to aggregate knowledge? Nobody's going to spend their time writing encyclopedia entries! And yet there it is. On a personal level, if I listened to everyone who thought I was wasting my time improving on find + grep you'd never have ack.

We all have to persevere in the face of adversity to ideas, but there's more than that. We need to ignore our detractors. Despite how silly and time-wasting it is to argue your motivations and reasons for undertaking a project, many of us feel compelled to argue with everyone who disagrees with us. I suggest you not waste your time.

On the Internet, the attitude is "Why wasn't I consulted?" Every anti-social child (measured by calendar or maturity) with a keyboard thinks it's his responsibility to piss on everything he doesn't like. They'll be there always. You can no more make them go away than you would by arguing with the rain.

What are you hoping to achieve by arguing with someone who doesn't like your project? Do you expect that he'll come around to your way of thinking? It won't happen through words.

Not only does arguing with your critics waste your precious time, but it tells them, and every other crank reading, that you're willing to engage in debate about what you're doing. Don't encourage them! Let them find a more receptive target.

I'm not saying that factual misstatements need to be ignored. If something is provably incorrect, go ahead and counter it with facts. However, most of the time these message thread pissing wars get down to "I would not be doing what you are doing, and therefore you are wrong for doing so."

The only thing that has a chance of silencing your critics is success at what you do. Arguing with the naysayers doesn't get you any closer to that.

Stand up for your communities and projects

| 5 Comments

In the flurry of commentary about Sunday's blog post, three themes have recurred:

  • Andy has done bad things, too!
  • You didn't give specifics!
  • Welcome to the Internet, that's just how people are.

Yes, I've done anti-social things before. I've been part of the problem. That fact doesn't change the validity of my points. We still need strong, human-based communities as the bedrock of any open source project, and those communities can only thrive when people are respected.

Second, I intentionally did not list specific grievances. I don't need to. It's not necessary to give an example of blatant disrespect for us to recognize it. I don't have to mention a time when someone disregarded the basic humanity of others. We've all seen it.

Third, I understand that anti-social behavior passes for normal on the Net, in open source, and among programmers. That doesn't mean we have to let it go unchallenged, or believe that nothing can be done. I accept that this is often the normal state, but I do not approve of it. We can be better than that.

Today's post from the always-insightful Seth Godin couldn't be more timely.

A bully acts up in a meeting or in an online forum. He gets called on it and chastised for his behavior.

The bully then calls out the person who cited their behavior in the first place. He twists their words, casts blame and becomes an aggrieved victim.

Often, members of the tribe then respond by backing off, by making amends, by giving the bully another chance.

And soon the cycle continues.

Brands do this, bosses do it and so do passers-by. Being a bully is a choice, and falling for this cycle, permitting it to continue, is a mistake.

This fits with something chromatic told me last night. He said, "I want people to know that they have permission to stand up to bad behavior." So here it is.

Every one of us has the permission to stand up to the bullies, to the anti-social behavior in our communities. In fact, we not only have permission; we have the responsibility.

Next time someone, for example, cusses out a newbie for asking a "stupid" question, let the offender know how much he or she is hurting the community. Don't accept the bully's excuses for being cruel and abusive to others. If moderators or persons of authority can't or won't intervene, don't be afraid to walk away.

Bullies are damage and need to be routed around. Start your own community if need be, and make sure the people from the original community know about it. Vote with your feet.

It's time to stop pretending this problem doesn't exist. It's time to stop accepting that it's just the way things are. It's time to stand up for your communities.

Slipping away from the Perl community

| 14 Comments

I'm 43 years old now. I've been in open source for about twenty years. I'm too old and burned out for much of what goes on in open source, and specifically Perl.

I'm tired of all the arguing.

I'm tired of the people who enjoy a back-and-forth debate about how communities should run, and want to spread that joy to people not involved in the original discussion.

I'm tired of seeing yet another clueless missive from someone claiming that we don't have to be nice to each other, because hey, we're all adults here. I'm tired of hearing that profanity in written communication doesn't matter because hey, it's just words, man.

I'm tired of those unable or unwilling to see outside their blinkered little world, and to think that others might think differently, and to think that their feelings might matter.

I'm tired of people who confuse being verbally abusive with "not getting along."

I'm tired of people who think that verbal abuse of another human is ever acceptable.

I'm tired of being made to witness verbal abuse as competition, where the abuser places more pride in his cleverness than any consideration of how the listener might hear it.

I'm tired of seeing cool new projects and realizing I will never use them, because I don't want to be associated with key members of the communities surrounding them.

I'm tired of having to delete comments on Perlbuzz because the commenters can't manage to make a point without slinging insults at those with whom they disagree.

I'm tired of having to walk away from sub-communities because of all of the above. The end result is I become more and more isolated from the rest of Perl.

That means less contribution, technical and otherwise, from me, and from the others who have shared the same concerns with me regarding their own contributions.

And it makes me sad that I feel my community slipping away. And it makes me sad that Perl loses because of it.

(Addendum: This is not a "screw you, I'm leaving." I'm certainly not leaving. Just describing what I see and how it affects me and other valuable members of the community who have been driven away. And to anyone asking "Give us specifics", they're besides the point. Discussion of specifics turns into a discussion of nothing but past specifics. The issues here are far larger than he-said-she-said. I also don't expect that individual people will change, but that we as community tolerate bad behavior less.)

Followup: Stand up for your communities and projects

What to respond to "Perl 6 isn't Perl any more"

| 23 Comments

Now that Rakudo Star is out, and people are able to easily install and work with an early implementation of Perl 6, the pundits and cranks have to put aside their tired Duke Nukem jokes and talk about how different Perl 6 is from Perl 5. They gripe that everything is different and scary, "it shouldn't be called Perl any more." I'm tired of it, and it makes no sense.

I bet none of those cranks remember Perl 4 and the shift to Perl 5.

  • Perl 4 didn't have lexical (my) variables
  • and there were no scalar filehandles
  • and you couldn't pass filehandles as parameters to functions except with typeglobs
  • and the package separator was ', not ::
  • and really nobody used packages anyway
  • and there was no object support whatsoever
  • and that meant no modules to speak of
  • and you couldn't pass around regexes as scalars (qr// operator)
  • and on and on.

Even with all those differences, we survived. In fact, we thrived.

The Pink Camel, first edition of Programming Perl, covering Perl 4, was only 450 small pages long, and a third of that was a section called "Real Perl Programs." (Imagine! Actual programs!) The Blue Camel, the 2nd edition, covering Perl 5, was over 600 bigger pages.

You know what I thought when I got my copy of the Blue Camel? It wasn't "Boy, this sure isn't Perl any more." No, I thought "Holy shit, look at all the stuff I can do." I couldn't even read the book straight through, because I kept skipping around, my mind amazed at the possibilities in front of me.

There are those who will read this and say "Yeah, but Perl 5 could still pretty much run any Perl 4 program, but Perl 6 won't be able to run Perl 5." And that's true. And it's irrelevant.

Perl 6 is still Perl, and is still called Perl, for many reasons, but only one that matters.

Larry Wall says that Perl 6 is still Perl.

Larry has his reasons. Some he's mentioned in past State of the Onion addresses. Maybe you don't agree with his reasons, or his decisions. But it doesn't matter one damn bit what you think. It's his decision. All arguments are a waste of time and brain cycles.

So when someone says "Perl 6 should have been named something else," I suggest a response of "OK, whatever you say. Now, isn't it cool that you can use list reduction to say my $sum = [+] @list;?"

White House releases open source code

| No Comments

I'm so happy that the White House has fed back to the open source community and, more importantly, advertised that fact.

Remember how fifteen or twenty years ago you'd see mentions of the Internet in popular culture and think "This is really picking up"? That's how this announcement makes me feel.

Free Software Foundation helps no one with name-calling

| 5 Comments

Discourse on the Net is tough enough without lowering yourself to pointless name calling. The Free Software Foundation ought to know better, especially when their work is so important.

Today John Sullivan posted a story about problems the FSF has with Amazon's release of the Kindle source code yesterday. Their three main issues are:

  • Not all the code is included.
  • Changes to Kindle code do users no good because users cannot legally update their devices
  • Important features remain secret.

The article is well-thought out, and clearly makes the three points. It would be a fine article if not for the insulting headline: No, Amazon did not release all of the Swindle's source code.

Why, FSF? Your article stands on its own, so why sling the mud? Why lower yourselves to juvenile name-calling? What do you hope to gain by calling the Kindle the Swindle? Are we to think "Ho, ho, those clever FSF folks!" I can't imagine.

Relatedly, please read Roger Ebert's article "The O'Reilly Procedure" on the lowering of the standards of debate in our society.

How to write an announcement for your software project

| 1 Comment

In my job as editor of Perlbuzz, I get email all the time asking me to run announcements about all sorts of Perl-related things. They're usually announcements of a new release of some module, or something about an upcoming conference. And usually I don't run them, because they violate the first rule of announcing something:

An announcement that says "PerlWhacker v1.5.3 has been released" is not interesting to anyone but a small handful of people. The most important part of being interesting is that your announcement has to have an angle.

Without an angle, there is no reason for the reader to read past the headline

The angle is the part of the story that says "This is why this is interesting to you, the reader." There has to be a reason that a story is interesting, not simply a recitation of facts. There has to be a hook, a reason for the potential reader to see a headline, or maybe the first paragraph, and say "Huh, I'd like to read that."

Here are some examples.

  • Bad: "Devel::NYTProf version 2.04 got released, here's the change log." No angle, very boring, unlikely the reader will pay any attention to the story, if she even clicks it in her feed reader.
  • OK: "Devel::NYTProf v2.04 got released, and it now uses 90% less disk space by using the Zlib compression library." Sort of interesting, because the reader can say "Huh, that sounds like a cool hack. Still, what's the effect on the reader?
  • Good: "Devel::NYTProf v2.04 got released, and it uses 90% less disk space, because Nicholas Clark was trying to run NYTProf on the entire Perl test suite and ran out of disk space, and he worked with Tim Bunce on a patch." That's an angle because it tells a story that the reader can relate to.
  • Great: "Devel::NYTProf v2.04, and it uses less space, because Nicholas Clark was running the Perl test suite against it, and here's a link to the findings from that research." Bingo!

Assume that the reader knows nothing about what you're announcing.

Finally, you must assume that the reader doesn't know what you're talking about. Most of the announcements I see are announcing to a small group of people who are aware of what is being announced, simply notifying that group that something has happened, excluding the readers not yet in the know.

I'm going to pick on the announcements for Summer of Code, both because they're excellent examples of how to exclude readers, and because I want the GSoC to succeed wildly. That's why I took the time to revamp the announcement when I ran it last night.

The original announcement that Eric Wilhelm ran is this:

The Perl Foundation has been officially accepted into the Google Summer of Code 2009 program as a mentor organization!

Hopefully some of you have identified some potential students already. Now we need your help getting them to submit their proposals.

http://leto.net/dukeleto.pl/2009/03/tpf-accepted-to-google-summer-of-code-2009.html

The student application period begins Monday, March 23rd and runs through April 3rd. (Students note: you can edit your proposal throughout that 11-day period -- getting it started early and talking to potential mentors greatly increases your chances vs throwing it over the wall at the deadline.) See this page for details:

http://code.google.com/soc/

Interested students and potential mentors, please read the GSoC info on the Perl wiki:

http://www.perlfoundation.org/perl5/index.cgi?gsoc http://www.perlfoundation.org/perl5/index.cgi?gsoc_2009_projects

If you're interested in mentoring or have a good project suggestion, now is the time to get your info up on the wiki so students will know about your code and where to find you.

Eric has done a ton of work for GSoC this year and last, and it's safe to say that the Perl involvement GSoC wouldn't be as great, in fact might not even exist, without Eric's work, so this is no knock on Eric. But this announcement has some huge failings, and it leaves questions in the mind of the reader who doesn't know what GSoC is.

  • What is Google Summer of Code?
  • Why is it interesting that TPF is a mentor organization?
  • Why do I care about it?
  • What's in it for me, the reader?
  • What is a student?
  • Why would a student want to join GSoC?
  • What is a mentor?
  • Why would someone want to be a mentor?

In short, Eric wrote the announcement for the people who already know what GSoC is, and excluded the other 90% who don't. Jonathan Leto's announcement has the same failings.

It makes sense why Eric and Jonathan wrote they way they did. They've been busting their asses for weeks (months?) working to set things up. They've been working inside the echo chamber of other people that are involved in the project. The parts of the project in the forefront of their minds are the details like how to sign up and how to write a proposal. However, to someone unfamiliar, it's noise until he knows the overview.

Get people to read your words

Whether it's an announcement of your software, or a resume, or a posting in your blog, you have to give the reader a reason to read what you've written. When writing, we tend to focus on the details of the text, expecting that the reader will consume our every word. Problem is, people aren't like that. We skim. We read titles. If it's not interesting we move on.

In my book on job hunting, I hammer home the idea that without a compelling summary at the top of your resume, the reader is not going to spend much time digging the good stuff out of your bullet points at the bottom. It's the same rule with announcements about your software project.

Next time you're going to announce something, show the announcement to someone who is not involved with the project, maybe a co-worker or your spouse. Ask him or her to explain what you're announcing. Try to understand how your article sounds to someone unfamiliar with it. Your project's success may rely on it.

« Interviews | Main Index | Archives | Parrot »