Perlbuzz news roundup for 2012-06-04

June 4, 2012 CPAN, Opinion, Perl 5 No comments

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

  • 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

February 20, 2012 CPAN, Opinion, Perl 5 No comments

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

Mark Jason Dominus on giving fish

November 2, 2011 Community, Opinion 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

October 6, 2011 Advocacy, Community, Opinion 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

April 26, 2011 Advocacy, Community, Opinion 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.

What to respond to “Perl 6 isn’t Perl any more”

August 5, 2010 Opinion, Perl 6 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](http://www.perlfoundation.org/perl6/index.cgi?state_of_the_onion). 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

April 22, 2010 Advocacy, Opinion No comments

I’m so happy that the [White House has fed back to the open source community](http://www.whitehouse.gov/tech) 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

June 17, 2009 Opinion 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](http://www.fsf.org/blogs/community/kindle-swindle-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”](http://blogs.suntimes.com/ebert/2009/06/the_oreilly_procedure.html) on the lowering of the standards of debate in our society.

How to write an announcement for your software project

March 22, 2009 Advocacy, Opinion 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](http://perlbuzz.com/2009/03/get-paid-for-working-on-perl-projects-in-google-summer-of-code-2009.html) 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.


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:


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


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](http://leto.net/dukeleto.pl/2009/03/tpf-accepted-to-google-summer-of-code-2009.html) 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](http://www.pragprog.com/titles/algh/land-the-tech-job-you-love), 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.

There is no “best” in software

December 1, 2008 CPAN, Opinion 4 comments

Dave Rolsky wrote a [fantastic article](http://blog.urth.org/2008/12/the-many-axes-of-software-development.html) on the many different criteria on which you can choose your software to use. For example:
> # Easy to integrate – Some libraries are designed to be integrated with other modules (Catalyst), some want you to embrace their world (Jifty).
> # Complete – Some libraries come with a complete solution (Jifty) and some require you to put together a bunch of pieces into a whole (Catalyst).
Which is better? The answer, of course, is “it depends.” Is the project for in-house use, or will it be distributed? Is it a one-off, where the base install will do most of what you want? Or are you likely to want to extend beyond those constraints?
Most importantly, Dave points out:
> I’d like to see people state their priorities up front, and explain why it’s important for the work they do. Often this gets left out of the discussion. Without this information, we often end up just talking past each other.
The extension of that is that many people may not even have thought about what their priorities are. Consider how often you’ll see a question, such as at Stack Overflow, that asks [“What’s the fastest way to do X?”](http://www.google.com/search?q=site%3Astackoverflow.com+fastest+way) Most of the time, the querist hasn’t even thought about that “fastest” part; it’s just assumed. (For that matter, that’s like assuming that the most important part of a new job is how much it pays, but that’s a topic for [another blog](http://theworkinggeek.com/).)
Make sure you know what your priorities are. Question your assumptions. Your project will thank you for it.