It’s a fun group, and I always enjoy going, even when I’m the speaker.

The nice people at Logitech have dropped the Squeezebox line to make a new cloud-based product.  Not my cup of tea.

Problem: The Logitech Media Server software is old and balky, and installing it is a pain on new systems, because it includes binary versions of Perl modules.

Solution: Install perlbrew for the squeezebox user, install a supported Perl version there, and tweak the #! lines to use that squeezebox user’s perl install.

The right perl works fine, and since it’s in ~squeezebox, it won’t get screwed up when SuSE upgrades.

WAY easier than trying to fix the idiosyncratic Logitech Media Server software!

It’s Invisible

The first reason is that I feel it changes the language a lot, and in ways that make it really hard for a new reader to follow. If you’re reading code that has no error checking in it, as a new or even mid-level Perl author, you’ll perhaps not realize that’s bad, or that it does have error checking. That checking being hidden in “use autodie” can be somewhat difficult to see.

As part of that difficulty, using autodie makes changes to all the Perl builtins.  When I need to use one, I look it up in perldoc.  perldoc tells me it returns false or undef or whatever in case of an error.  Except… that’s not true with autodie.  While I’m a good enough programmer to remember this about my own programs, it makes it a lot harder to tell what a particular piece of Perl code will do.

I’m really unhappy with the changes to the second edition of the Modern Perl book, because it’s assuming autodie everywhere.  I don’t want to give it to new Perl programmers any more because they’ll be confused, and the differences are subtle and almost entirely undocumented.  I can’t recommend the new version of this otherwise useful book to anyone who isn’t an expert Perl programmer and that’s a shame.

I don’t like making large-scale, undocumented changes to the language libraries any more.  At what point is it no longer Perl, but something new and different?

As an aside, I think a lot of expert Perl programmers forget that many people using Perl don’t know it has exceptions at all.  I often find people who are shocked to discover it does.  Some of them have even been using die for errors, and didn’t know how the whole thing works together.  Professional programmers, not script kiddies.  Happens all the time.

This concern of mine with autodie is actually a solvable problem.  The Perl core needs to incorporate autodie, and update al the perldocs to explain it.  If the perldoc for “unlink” said, “returns the number of files deleted. With autodie enabled, will die on error deleting files.” it would mean that a new author would have a chance to see what’s happening.  I don’t expect this to happen, but until it does, I consider autodie too sweeping a set of changes for a module to be making.

I probably wouldn’t use it anyway, because of this second reason:

I Don’t Like Exceptions

I’ve worked in a ton of languages that use exceptions.  I understand them, and I can use them.  I don’t like them.  I find it hard to write robust, resilient code with them.  Many people like them because you can put off or ignore error handling and capture it all in one place.  Your code is free of that distracting noise of error handling.

However, this means your code notices the errors in the wrong place to do anything about them, and has to pretty much fall over dead and crash.  It can’t try and fix things very well.  Or you can handle the exceptions very close to the place they might occur, littering your code with even more distracting and hard to read exception handling stanzas.

The most reliable and robust code I’ve ever written was about 70% error handling code.  In many cases it could recover from errors or try an alternative to keep running.  I find this much harder to do with exceptions, and exceptions in general much more difficult to manage.

If programmers were clamoring for a giant “ON ERROR GOTO” statement, while telling me that gotos were evil, I’d be really confused.  Yet, that’s what exceptions are.  Exceptions that many programmers never handle, and simply want the program to crash the first time something goes wrong.  I don’t want my program to crash every time something goes wrong; I want it to log the error and keep going, or ask again or try an alternative.

If “Go To Considered Harmful” is still valid – and it seems to me to be – why is ON ERROR GOTO allowed?  Isn’t that all an exception is?

I don’t know a way to change this preference of mine, and how to convince myself that it’s okay to just let things crash or to write horribly tangled code to pander to the needs of the exception handlers.  So, I don’t.

Here’s pseudo code of what I found at work today:

$ok = link("$src/$file", "$dst/$file");

unless($ok) {

    my $log = $!;

    log_error_in_database($log);

    send_error_in_email($!);

}

See the error?  The coder saved the error from $! in $log, and then passed it to the DB to store it.  The DB (which no one knew existed) had all the right errors.  Writing to the DB changed $! to a harmless non-error.  It wound up being “Resource temporarily unavailable” or whatever numeric value that is.  It’s meaningless, though, because it was set by calling some other stuff in the DB handling function.

Then, the code tries to e-mail it.  Clearly the DB was added later, as it didn’t use the copy they saved there, and used $!, sending the useless value to us in e-mail where we all looked at it.

(Edit: A sharp commenter suggested I actually show the fix, which is an excellent idea!)  Instead of storing your error, then forgetting to use it, use the stored error message in both places:

$ok = link("$src/$file", "$dst/$file");

unless($ok) {

    my $log = $!;

    log_error_in_database($log);

    send_error_in_email($log);

}

Another alternative would be to use local on $!, but that’s not as sound, because every function you call also has to do the same, and it is hard to tell what module or library you use might get it wrong.  Saving a copy of $! for your code to use later will be safer.

The good news is that I eventually found, and realized the values were in the DB and looked there so I know what was going on and can try and make progress.

This is actually cleaner and simpler than the real code.  The real code actually did check the results of link(), which is good!  It doesn’t check mkdir() or chdir() anywhere, though…  It’s not the worst Perl I’ve ever seen, but it’s on the list of contenders.

I really, really want to replace this code with something that is less painful.  I have a nice, new Modern Perl version well underway.  We’ll see if management lets me finish and deploy it!

Here’s how a C programmer might code up a particular algorithm in Perl:

for (my $i = 0; $i < @ary1; $i++) {
    for (my $j = 0; $j < @ary2; $j++) {
        if ($ary1[$i] > $ary2[$j]) {
            last; # can't go to outer :-(
        }
    $ary1[$i] += $ary2[$j];
    }
    # this is where that last takes me
}

Whereas here’s how a Perl programmer more comfortable with the idiom might do it:

OUTER: for my $wid (@ary1) {
INNER:     for my $jet (@ary2) {
               next OUTER if $wid > $jet;
               $wid += $jet;
           }
        }

See how much easier this is? It’s cleaner, safer, and faster. It’s cleaner because it’s less noisy. It’s safer because if code gets added between the inner and outer loops later on, the new code won’t be accidentally executed. The next explicitly iterates the other loop rather than merely terminating the inner one. And it’s faster because Perl executes a foreach statement more rapidly than it would the equivalentfor loop.

First, the smug, “See how much easier this is?” makes me want to slap someone.  No, I don’t.  I see equally bad code.  One has a goto in the middle, and one uses awkward loops.  Both have no documentation, no explanation of what they’re doing, and indecipherable yet different variable names.  I have little to no confidence these snippets do the same thing because I can not tell what either of are supposed to do.

The concerns about why the code is bad seem to be vague as well.  ”Cleaner because it’s less noisy.”  Really?  What does “noisy” mean?  I find the labels to be a fairly unusual construct that increase my cognitive load on reading the code pretty significantly.  Is that noisy?  I can almost see the argument for ‘safer’, but ‘safer’ code that’s unreadable isn’t a good trade-off in my mind.

If I’ve learned anything about Perl, I’ve learned that comments about speed are often wrong.  I think this is actually correct, but I don’t think it matters.  This isn’t an advantage of for or foreach, but is a comment about choosing a better algorithm.  That really shouldn’t be a surprise, nor should it be part of the discussion of the for loop!

Worst, this makes me feel stupid.  I don’t see how this is “easier”, and I can’t read it at all and the text, by assuming I will and that this is crystal clear to every reader, seems to say to me, “You aren’t smart enough to write Perl.  Go away.”

This section of perldoc has been unhelpful since Perl 5.8.8 – over six years – and damaging people’s opinion of Perl that entire time.  Why do we keep writing things like this?

Would people be interested in screencasts or videos?

Totally annoying.  A simple Perl script fixed it.  Don’t know why they didn’t put it in their samples, though.

#!/usr/bin/perl

use strict;
use warnings;

=head1 NAME p4_check_passwd

Called with the user name on the command line and the password on standard
input, this program returns a success or failure depending on that password's
correctness.

Uses getpwnam to do so, and must run as root on in shadow group to access
/etc/shadow and password data.

This should be configured in p4 triggers as an auth-check trigger:

Triggers:
unixpw auth-check auth "/home/perforce/bin/p4_check_passwd.pl %user%"

This uses the crypt system call, which should handle any variants of encryption
in your password file. It also uses the getpwnam() function to access
the password data, so should be able to access data from NIS or other
configured password system.

=cut

# Perforce wants all messages on stdout. Guarantee that.
open(STDERR, ">&STDOUT") or die "Can't redirect to stdout\n";

# Get the user name
my $username = shift;
die "Need user name on command line\n" unless $username;

# Get the password
my $password = <STDIN>;
chomp $password;

# Get username and password from the system
my ($name, $passwd) = getpwnam($username);

die "Can't log in as $username\n" unless ($name and $username eq $name);
die "Can't access encrypted passwords\n" if(not defined $passwd or $passwd eq ''
or $passwd eq 'x');

# Check password and return correct exit code or die.
if(crypt($password, $passwd) eq $passwd) {
	exit 0; # Silent, successful exit worked!
} else {
	die "Can't log in as $username\n";
}

Works for me, anyway.

We couldn’t do it.  After a second look, I still can’t do it.  Not for all cases, anyway.

perlsub says lists a prototype of (*;$) for open, and discusses being careful not to override open by accident.  It also suggests prototype can show the prototypes for overridable items.

prototype ‘CORE::open’ returns “*;$@”, which is interesting, but not a match for perlsub.  ”*;$@” lets the function get called, though, and matches all the things open has to do.

I wrote a really simple wrapper for open:

 use Data::Dumper;

sub open(*;$@) {

    say Dumper(\@_);

}

I wrote a function to call it a couple of ways:

say "test 1:";

open (FH, '>file.txt') or die "Can't >file.txt: $!";

close FH;

say "test 2:";

open (FH, '>', 'file.txt') or die "Can't > file.txt: $!";

close FH;

say "test 3:";

open (my $fh, '>', 'file.txt') or die "Can't my > file.txt: $!";

close $fh;

Now I can see what those look like:

test 1:

$VAR1 = [

     'FH',

     '>file.txt'

 ];

test 2:

$VAR1 = [

     'FH',

     '>',

     'file.txt'

 ];

test 3:

$VAR1 = [

     undef,

     '>',

     'file.txt'

 ];

Okay.  The two calls with typeglobs get the name of the glob.  I can work with that.

The call with a lexical, though, gets the value.  Where/how do I return the handle?

I messed around some more, and when using lexicals, a Perl open() function is called with the value of the lexical, not with any way to identify the variable itself.  I can’t figure out how to get the variable to pass to CORE::open, or to return something into it.

And there I’m stumped.  Is it possible that the docs in perlsub are from the 5.5 days and don’t work since Perl 5.6 introduced lexicals as file handles?  Or am I missing something?

I could go dig in to CPAN and see if any other modules do this right.  How does Safe.pm do it?  Can it be done in an XS module but not in Perl?

Back to useful work instead of banging my head against this.

I’d been looking for a way to manage having multiple Perl installations on my system.  Ruby has something called the Ruby Version Manager which makes this really straightforward, and I figured there had to be something like it for Perl.  I hadn’t looked much, but what I had didn’t get me anywhere.  The Preface for Modern Perl mentioned it in passing.  The tool is called App::perlbrew and allows you to easily switch from one Perl to another and can help manage those Perl installations.

Combine that with local::lib so you can have your own installed modules, and you’ve almost got rvm.  The ability to have named module sets and turn them on and off at will is missing.  If it’s important, the two could be combined into a complete Perl environment management tool… but I don’t know if it is important.  A per-project Perl with modules installed might be enough.

One useful tool mentioned in Modern Perl is the Perl module Modern::Perl, also by chromatic.  It’s a helper to take some of the boilerplate that a modern Perl program should put in every program and module and condense it to one easy to read, clearer line of code.  It isn’t a big deal, but is nice.  (CPAN, as usual was full of similar things, but I didn’t think they were as well thought.)  I had heard of Modern::Perl because I’d been following chromatic’s blog.

The module I thought was really neat but hadn’t heard of was Task::Kensho.  This is part of the work of a group of folks who are trying to build an “Enlightened Perl” and is mostly references to other modules.  The module list includes some big stuff I’d run into – Moose, DBIx::Class – but also included a lot of just generally useful stuff that I’m sure will be handy.  There was also some things that were not critical but neat, like Smart::Comments.  There’s a bunch of stuff on that list I’ve been Meaning To Look At but haven’t gotten around to yet, like Devel::REPL.

The secret is to use links like this:  http://search.cpan.org/perldoc?Task%3A%3AKensho

The %3A are the URI encoding of a : so this goes to http://search.cpan.org/perldoc and searches for the module name automatically.  Neat.