• The future of Perl 5

    Jesse Vincent, the pumpking for Perl 5, gave a talk at OSCON called "Perl 5.16 and beyond" where he lays out the future of Perl 5. The slides are up on slideshare, and they're well worth reading. I haven't read perl5-porters, the Perl 5 maintainers' mailing list, in a few years, and Jesse's slides are an eye-opener to the trials and tribulations of keeping Perl 5 usable in legacy situations but moving forward with new innovations.

    The pumpking is sort of the project leader for Perl 5, and arbiter of what gets committed into the source tree. The pumpking also used to be the person who created the releases, but as Jesse points out below, this responsibility has been delegated to others. The term "pumpking" comes from the holder of the patch pumpkin.

    Key points from the slides:

    • Perl 5 is now on a regular release schedule, where releases are made based on the calendar, not some critical mass of changes.
    • The dual track of odd numbers (5.13.x) for development releases and even numbers (5.14.x) for production releases continues.
    • Although Perl 5.14.1 is current production, 5.12.4 and 5.15.0 have recently been released as well.
    • Releases used to take three weeks for a single pumpking to do. Now it's a documented process that takes only a few hours. Releases are done by rotating volunteer release engineers. Per Larry, the time of hero pumpkings is over.
    • As Perl 5 changes much more quickly, we need to be able to recover from mistakes. Perl should have sane defaults. Perl 5 should run everywhere: Every OS, every browser, every phone.
    • Forward changes should not break older code. Programmers shouldn't have to build defensive code to protect against future changes to Perl 5.
    • The Perl runtime needs to slim down. Old modules are getting yanked from core and moved to CPAN. Not deprecating, but decoupling. We need to release a version of the Perl core that contains all the stuff we've yanked out of the "slim" core distribution.
    • The test suite needs to be split into three types of tests: language, bug-fix and implementation.
    • Jesse wants saner defaults in the future, to make Perl 5 cleaner, simpler and easier to work with:
      • warnings on
      • autodie-esque behavior
      • throwing exceptions rather than returning on failure
      • 1-arg and 2-arg open gone
      • Latin-1 autopromote off
      • utf-8 autopromote on
      • Basic classes and methods
      • No indirect object syntax
    • How to make this happen faster? Donate to the Perl 5 Core Maintenance Fund.

    I couldn't attend Jesse's talk because I was speaking about community and project management with Github in the same time slot, so if video exists I'd love to see it. And thanks very much to Jesse and the rest of p5p for keeping Perl 5 so amazing.

  • YAPC::NA 2012 gets away from RTFM marketing

    Reposted from my main blog.

    Too many times I've seen a conference announced once, and then never heard about it again. It's what I call the RTFM method of marketing: Either you happen to know about the event, or you lose out. This year for YAPC::NA, the annual North American grassroots Perl conference, lead organizer JT Smith isn't going to let that happen.

    No sooner had the 2011 conference wrapped up when JT started daily postings about 2012's event to the YAPC::NA blog. He plans to keep that pace going for the next year, until June 13th, 2012 when 2012's event start. The goal is to keep people thinking about YAPC::NA in the next eleven months, and to keep everyone's expectations high. "Everyone at YAPC 2011 laughed at me when I said I was going to do a blog post a day," JT told me on Sunday, "but I've got the next 300 postings planned out."

    It's not just frequency that's different this time. JT's writing about the details of the conference, and why you'd want to attend. His posts give tips about the best way to travel to Madison, and attract potential attendees with views of the conference location on the lake. A "spouse program" for the non-hacker members of the family is also high on his publicity list.

    As JT and I ate lunch at the bar where he hopes to have a YAPC beer night, we discussed the mechanics of this ongoing communication campaign. JT has the next thirty postings written and posted to Tumblr with future publication dates, letting him create postings in batches, rather than every day. "I chose Tumblr for the blog because it has the best posting scheduling system," he told me.

    You can follow the YAPC::NA Twitter stream at @yapcna, or the blog itself at blog.yapcna.org.


    I give "RTFM marketing" that name because it's an extension of the geek notion of RTFM. "RTFM" comes from the rude geek response of "RTFM", or "Read the F-ing Manual". It's used as a reply to a question that the geek thinks should not have been asked, because the information exists somewhere that the querent could have looked himself. It's as if the rude geek is saying "The information exists in at least one place that I know of, and therefore you should know that information, too."

    The idea that one should just have known about a given piece of information applies to this sort of undermarketing as well. Project leaders seem to think that when information has been published once, everyone will know about it. The RTFM marketers expect that everyone know what they do, read the blogs they do, travel in the same online circles as they do. This is a recipe for failure.

    This mindset can be crippling when it comes to publicizing projects and events. Organizers do their projects a disservice when they market their endeavors with the expectation that everyone will automatically know about something simply because they're written one blog post about it.

    RTFM marketers also don't spread their messages wide enough. They advertise to the echo chamber of the circles in which they normally run. They'll post to the standard blogs, post to the mailing lists they read, or discuss it in the IRC channels they frequent. This limits the potential audience for the project to the one with which the project leader is already familiar.

    Tips for doing open source project marketing right:

    • Write & post frequently.
    • Write & post in many disparate locations.
    • Explain the benefits. Explicitly tell the reader why they would want to attend your event or use your software.
    • Change your messages. Don't post the same thing twice.
    • Never assume that someone will have read your previous message. It's OK to repeat something stated in a previous message.
    • You don't know your potential audience as well as you think you do. Think big.

    I'd love to hear stories and ideas about how you got the word out about your project.

  • Perl 5.14 is now available

    From the Perl Foundation blog

    A new version of Perl, 5.14, was officially released on 14th May following the successful test period, including the testing of release candidates. This is the first release of Perl 5 using the new annual schedule.

    There are a number of enhancements and alterations in this version, a full list of changes can be found at (http://perl5.git.perl.org/perl.git/blob/HEAD:/pod/perldelta.pod), a summary of some of the changes:

    • Unicode 6.0 support, along with many, many improvements to our Unicode-related features
    • Improved support for IPv6
    • Significantly easier autoconfiguration of the CPAN client
    • A new /r flag which makes s/// substitutions non-destructive
    • New regular expression flags to control whether matched strings should be treated as ASCII or Unicode
    • New "package Foo { }" syntax
    • Uses less memory and CPU than previous releases
    • A swathe of bug fixes, a large number associated with the work of Dave Mitchell (http://news.perlfoundation.org/2011/05/fixing-perl5-core-bugs-report-11.html) who has been fixing some deep bugs thanks to a TPF grant;

    It is important to note that this version marks the official end of support for Perl 5.10.

    This work is just one year of development since the release of Perl 5.12.0. It contains nearly 550,000 lines of changes from close to 3,000 files, this work was done by 150 authors and committers. The documentation, as always, pays tribute to those people who worked hard on this new version, "Many of the changes included in this version originated in the CPAN modules included in Perl's core. We're grateful to the entire CPAN community for helping Perl to flourish." The success of this version is dependent on the great work of the whole community, a particular note of thanks should go to Jesse Vincent for his coordination skills as release manager for 5.14.

  • Stand up for your communities and projects

    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.

  • Develop sensible coding habits on the path to true Laziness

    Whenever I walk in my front door, I walk straight to the kitchen, open the first drawer, put in my keys and wallet and cell phone, and close the drawer. Always, without fail, no matter how bad I might have to take a leak. It is no less convenient for me to do this than to drop my stuff any old place. It is a habit that I have maintained for close to 30 years now. And I never ever ever have to wonder where I put my keys, or my phone, or my wallet. Ever. Having to do so would be extremely inconvenient. In fact, it would be EXTRA brain cycles on my part to put them where they do not belong. When the phone rings, I know where it is. I don't run around wondering "Where's my phone?" trying to triangulate position. It's always there in the kitchen drawer. Always. I also always put on my seat belt in the car. I never wonder if it's "necessary". I just do. Thinking about if it is "necessary" is also inconvenient. It takes brain cycles that I don't need to spend. I also know that the one time I need my seat belt and I don't have it on, I'm screwed. Trying to decide to save three seconds by not buckling my seat belt is false laziness. And so is worrying about when you can leave out `warnings` and `strict` from your Perl programs. Yesterday in IRC, someone was lamenting that Perl 6 effectively has `warnings` and `strict` on by default. All variables must declared before use. This person was one of those programmers who tried for the premature optimization of saving some typing. He forgot that typing is the least of our concerns when programming. He forgot that programmer thinking time costs many orders of magnitude more than programmer typing time, and that the time spent debugging can dwarf the amount of time spent creating code. He also forgot that he's a human. Checks like `warnings` and `strict` are there because we are fallible humans. We type `$totl` instead of `$total`, and we want Perl to tell us that. We try to dereference scalars and since we're no longer using Perl 4, we want Perl to tell us about that, too. We want Perl, which is a program and doesn't get sloppy and forget things, to catch us when we are humans and get sloppy and forget things. Buy and read *The Pragmatic Programmer* and *Code Complete* and develop a solid set of programming habits from them. Sensible habits that are followed even when you might be able to get away without them are the true Laziness.