• Mechanix, the new Perlbuzz section

    When I asked if you wanted more technical articles in Perlbuzz, there were two answers: a resounding "Yes!" and a less resounding but no less emphatic "No!" The path was clear: More technical articles for the people that want them, and sequestered in their own section for those that don't.

    We've now started the Mechanix column at http://perlbuzz.com/mechanix. The main Perlbuzz feed will continue to be mostly news & opinion about Perl in general, while articles relating to coding and programming specifically will wind up in Mechanix. I suspect that most of what winds up in Mechanix will be pointers to other technical articles, as with the current Mechanix articles, "80% Programmers" and Mark Dominus on undefined behavior. I also suspect that at some point that someone will complain that "This should have been in that section," but such is the nature of arrangements like these.

    Please also note that Mechanix is specifically vague.* I picked the name because it evokes a sort of code jockey feel to it, without tying down to anything in particular. For example, an article I have in my "to be written" folder is about my foray into the PHP 5.3 source code and the horrors that I've found.

    I hope you'll give Mechanix a try in your newsreader, and as always tell us what you think, either in comments on this entry, or emailing us at the "editors" mailbox for perlbuzz.com.

    * I bet that the Ruby guys pick up on my idea but call it "Four Horsemen".

  • 80% programmers

    Ben Collins-Susmann writes about the 80/20 split of programmers and how the 20% of programmers who are "alpha programmers" have to account for the 80% who are not, and how they use their tools.

    Although the post talks about Subversion and distributed VCSes, the lessons hold for those who use Perl, too. How many programmers have we worked with who don't know about CPAN, or are afraid to use code from CPAN? How about programmers who don't understand the internals workings of "standard" Perl objects (i.e. blessed hashes), who don't realize that a {} is an anonymous hash constructor, not a "class" or "object" constructor? Or who are afraid to use the map and grep constructs?

    On the flip side, you don't want to dumb down your code to the lowest common denominator. Although both Mark Dominus and chromatic have written about it recently, I like Randal Schwartz's phrasing best: "Sooner or later you're going to have to write in Perl." I'm dealing with PHP code at work where the original programmer did not use keyed lookups (PHP arrays are effectively ordered versions of Perl hashes) to check to see if a given string was in a list of special strings. I'm assuming that he was unaware of the ability to look up array elements by key, but I think it would be even worse if he specifically didn't use the feature out of fear, or worrying about future programmers not knowing what the code did.

    Assuming that you're a 20% programmer (and that you're reading a programming blog suggests that you are), how do you deal with 80% programmers? Any tricks for the rest of us?

    Addendum: Not five minutes after I posted this, I found this article "What if powerful languages and idioms only work for small teams?", with most of the value in the comments from readers.

  • Mark Dominus on undefined behavior

    MJD's recent blog post on undefined behavior takes you into some nitty-gritty of Perl internals and bizarre little behaviors you may not have seen before, plus side trips into Haskell and XML.

  • One step closer: Perl 5.10.0 RC2 is out

    Rafael has put out the second release candidate for Perl 5.10.0. Please download, build and test on your own specific machines and let's get Perl 5.10.0 out live.
  • Perl in the comics

    I think by now we've all seen the comic from xkcd.com that gives Perl its proper respect and place in the history of the universe.

    Some comics are a little less respectful, but I'll cut the guy some slack because he wrote a text adventure version of Pac-Man.