• The horrible bug your command line Perl program probably has

    Most programmers know you have to check return values from system functions. Unless you're just starting out as a programmer, you know that this is bad:
    open( my $fh, '<', 'something.txt' );
    while ( my $line =  ) {
    # do something with the input
    }
    
    If that open fails the program continues on. The call to readline will fail, return undef as if we're at the end of the file, and the user will be none the wiser. If you have use warnings on, you'll get a "readline() on closed filehandle", but that's not much help when you should be dying. Instead, you should be opening your file like this:
    my $filename = 'something.txt';
    open( my $fh, '<', $filename ) or die "Can't open $filename: $!";
    
    This way, your user gets a useful error message if something goes wrong, but more importantly, the program doesn't continue as if nothing is wrong, potentially doing what it should not. h2. GetOptions needs checking, too Unfortunately, I see programs where otherwise-sensible programmers ignore the return code of GetOptions.
    use Getopt::Long;
    GetOptions(
    'n=i' => my $count,
    );
    # Do something that uses $count
    print "Processing complete!n";
    
    There are any number of ways the user can call this program incorrectly:
    $ perl foo -n
    Option n requires an argument
    Processing complete!
    $ perl foo -n=five
    Value "five" invalid for option n (number expected)
    Processing complete!
    $ perl foo -m=12
    Unknown option: m
    Processing complete!
    
    In all three of these cases, the user made a mistake, but the program lets it slide without a mention. The user's going to be disappointed with the results. The solution is simple: Always check the results of GetOptions(). The easiest way is to task && exit(1) after the call:
    use Getopt::Long;
    GetOptions(
    'n=i' => my $count,
    ) or exit(1);
    
    It's simple, effective, and prevents unexpected sorrow.
  • What editor/IDE do you use for Perl development?

    Gabor Szabo is running a survey about Perl development:

    I have set up a simple five-second poll to find out what editor(s) or IDE(s) people use for Perl development. I'd appreciate very much if you clicked on the link and answered the question. You can mark up to 3 answers.

    Please also forward this mail in the company you are working and to people in your previous company so we can get a large and diverse set of responses.

    The poll will be closed within a week or after we reached 1000 voters. Whichever comes first.

  • ack 1.90 released

    I just released ack version 1.90 to CPAN. If you don't know about ack, it's a text searching tool for programmers aimed specifically at searching large trees of code. Find out more at betterthangrep.com.

    Here's the changelog for this version:

    1.90        Mon Sep  7 23:24:24 CDT 2009
    [ENHANCEMENTS]
    Added Ada support.  Thanks to Shaun Patterson.
    Added -r, -R and --recurse options as in grep.  They have no
    effect because directory recursion is on by default.  Also added
    --no-recurse for orthoganality. Thanks to Mark Stosberg and
    Ryan Niebur.
    Version in --version is prettier.  Thanks, Ori Avtalion.
    Added an updated ack.bash_completion.sh from Adam James.
    [FIXES]
    Expanded --files-without-match to --files-without-matches.
    Removed all the hi-bit characters, so we don't have any encoding
    problems.  It's all entities now.
    Fixed capture-stderr to localize some globals that were obscuring
    errors.  Thanks very much to Christopher Madsen.
    Fixed uninitialized errors in tickets #138 and #159.
    [DOCUMENTATION]
    Fixed an incorrect command line in the docs for -f.
    Added notes on --pager.  Thanks to Mike Morearty.
    [BUILD]
    Made the squash program more robust when handling POD.  Thanks
    to Kent Fredric.
    1.89_02     Wed May 13 16:20:21 CDT 2009
    [DISTRIBUTION]
    Updated Makefile.PL to use new ExtUtils::MakeMaker features.
    Thanks, Schwern.
    [FEATURES]
    --version now shows the version of Perl that ack is running
    under, and the full path to the Perl executable.
    Added new switches --color-match and --color-filename, which
    let you define ACK_COLOR_MATCH and ACK_COLOR_FILENAME from the
    command line.
    Added new switch --column to display the column of the first
    hit on the row.  Thanks to Eric Van Dewoestine.
    Added .ss to --scheme.
    [FIXES]
    No longer die if you have a .tar.gz file in your tree.
    More tweaks to get the detection of input and output pipes
    working.
    Fixed an amazingly bad call to cmp_ok() in t/ack-passthru.t.
    [DOCUMENTATION]
    Started an ack FAQ.
    
  • Don't optimize for yourself in communities

    It drives me nuts every time I connect to an IRC channel, Perl-related or not, and the first thing I’m greeted with is “Don’t ask to ask, just ask!” (Over in #perl on freenode, the greeting is “No pasting, at all”. BAD USER!)

    Read on →

  • Perl 6 development does not detract from Perl 5

    A recent thread on use.perl.org brought up one of the worst myths of Perl 6: That Perl 6 is harming Perl 5. Andrés N. Kievsky commented in "a thread on use.perl.org":http://use.perl.org/comments.pl?sid=43716&cid=70320 bq. drop this insane perl 6 thing immediately. Give us good, stablethreading in perl 5 instead of self-hosting grammars in perl 6. Later he said: bq. proper OO syntax, multithreading, better speed ... are major issues in perl 5 that should have priority over perl 6 work. You can't expect me to believe that the perl 6 team can't work on that. There's so much misunderstanding here about how open source works, I'm going to ignore the ways that Perl 5 has benefited from the process of creating Perl 6. The problem with Kievsky's assessment is that it assumes that: * contributors are finite * contributors are interchangeable * contributors can be directed. All three are wrong. First, there is a *vast, unbounded talent pool*. The set of people available to work on Perl 6 is not limited to those who would otherwise be working on Perl 5. It's not as if there's a box of people that cannot grow or be added to. There are many contributors who have joined the Perl 6 project without having ever worked on Perl 5. In this instance, Perl 6 has actually brought people into Perl under the Perl 6 banner. Second, *not everyone can work on the same parts of different projects*. The tasks on Perl 6 may well be very different than the Perl 5 improvements that Kievsky would like to see. I have been contributing to Perl 5 for years, but I'm not at all available to help on the Perl 5 tasks he wants, because they're not in my area of expertise. However, I can help a lot with Perl 6 tasks, and not just programming. Parrot and Perl 6 are a better fit for me. Finally, and most disturbing, Kievsky seems to think that by wanting something badly enough, people will work on those tasks. Unfortunately for this idea, *there is no one directing Perl 5 development tasks*, and nor can there be. Open source contributors are volunteers. They work on what they want to work on. Even if I was clamoring for those Perl 5 improvements, I'd rather keep a great programmer working in the Perl community working on Perl 6 rather than leaving Perl entirely because there was no work she felt like doing. The only way to get a feature added to Perl 5, or any open source project, is to write it yourself, or to encourage others to work with you on it. It's the way of open source. Perl 6 and Perl 5 development work are not mutually exclusive. Work will continue on Perl 5 long after Perl 6 has hit prime time.