It looks like a couple of my big ticket items are coming soon:

• wiki style links and
• syntax highlighting

Once these are available, I’ll start writing up the articles I’m interested in. I hope others will jump in too.

I was going to say something pithy, like blogging can make a difference, but that’s not right at all. I made a couple of observations and some folks stepped up to the plate. I’m cautiously optimistic about this.

I’ve been spending a bit of time hunting spam which, as with most wikis, is pretty easy. First of all, I check the What’s new link. Then anything that has been edited recently by someone I don’t recognise, I check and revert to a previous revision if necessary.

On the downside, I’ve missed the ironman schedule, dang it.

Note To Self

• Investigate wikirad and wikedit

A number of people pointed me at the official perl wiki which I came across when I originally searched for perl wiki. The first couple of links I clicked on led me to believe that it was mostly abandoned.

On a second viewing, it is more actively updated than I first believed. In the "What’s New" tab there are 20 updates by various folks since the 20th of December. That’s not a big number, but it is much better than expected. And it is more than the total number of editors of my (non-existent) wiki.

Looking back to 2007, Schwern’s announcement was pretty inspiring. Why didn’t it take off in the same way as the emacswiki?

Some of my Current Issues with Perl Wiki

• www.socialtext.org isn’t a perl url. wiki.perl.org as suggested by Phaylon (or www.perlwiki.something) would be better.
• I couldn’t see a way to get syntax highlighting
• it doesn’t have pretty wikipedia-style links. By that I mean URLs are of the form blah/blah/blah/index.cgi?page_name rather than blah/blah/blah/page_name.

Still, when I weigh that against the fact that there are already other active editors and material which has been indexed by the search engines, it is clearly a better use of my time to become an editor than to try to get yet another perl wiki off the ground.

• Ask your local guru
• Post your question in one of hundreds of forums
• Search for the answer using your favourite search engine. and, for semi-completeness…
• …give up

Of these options, using a search engine is the most popular. Many developers aren’t fortunate enough to have an accessible guru and formulating a question that is good enough for a forum is a lot harder than typing a few words into a search engine textbox. In addition, it opens you up to ridicule and/or RTFM responses that you just don’t get with search.

What do Programmers Search for?

Brian d Foy reasonably points out that the perl documentation ranks highly for "perl documentation". But it’s not important. No-one is searching for that anyway.

Google provide some tools to check the approximate volume for a particular search. There are 80 – 90 thousand global searches for perl documentation per month, mainly in the form of "perldoc" or "perl doc".

Compare that against the number of monthly searches for "tcpserver" which is approximately 30,000. And that is just one problem out of tens or hundreds of thousands¹.

Many more people are looking for the answer to a specific problem than for perl documentation. This makes perfect sense.

What type of person is searching for "perl documentation" ?

• People in the process of learning perl
• People considering learning perl (probably as one of a number of options) and wondering if there is good online documentation

In neither of those cases do we need to improve things. They will find the excellent perl documentation and realise that perl is a great choice of language.

People looking to solve a particular problem are obviously not searching for "perl documentation". Aside from research for this article, as an experienced perl developer I haven’t needed to search for "perl documentation" for many years. Having said that, I do search for "perldoc [specific term]" several times a month.

1. "Read File" gets 673,000 searches a month. "PHP Read File" gets 40,500. In comparison the number of searches specifically for the perl documentation is vanishingly small.

Perl is my preferred language for getting things done. Why? Firstly because I already know it and secondly because I know where to look for answers.

When I started learning Perl, there was only one obvious choice of scripting language. Now finally there is some real competition¹, but with a modern object system, fantastic (and free) books and great libraries such as Plack, Perl is still the king.

Gabor Szabo asks how we can reach the 400,000 perl developers who are not yet part of the community. His proposal is to frequent programming forums and answer newbie perl questions.

Answering questions one at a time on a forum by forum basis a lot of hard work. If we’re already doing the work, it would be better to put it into making a centralized, authoritative resource – a wiki. Programmers already know how to find out the answers to questions. They use their favourite search engine.

The wiki would be maintained by the community. It would only contain high quality modern perl code and would have plenty of inbound links. When anyone searches for a reasonable perl question that doesn’t already have a good answer on a perl expert’s blog, a link to the wiki should appear at the top of the search engine results.

Talk is cheap so let me go a step further. I’m happy to set something up if folks think this a good idea. If a leading member of the community wants to head this up instead, then that is fine by me too.

Let me know in the comments.

1. From Ruby obviously. Python was never a contender

Soon, themes based on Hybrid Core will be parent themes and it will be easy to adapt them to your own requirements by creating a child theme. If you choose to use Prototype, a parent theme that already uses the latest version of Hybrid Core, you can do this already.

However, there are some excellent child themes based on the old Theme Hybrid way of doing things. Justin agrees that these are not straightforward to update.

my_functions.php

When I need to modify a complex (e.g. theme hybrid based) child theme I load a new file called my_functions.php at the end of functions.php. I borrowed this idea from Ian Stewart’s Travailler, although I’m sure it’s been used many times before.

/** my_functions.php **/

function add_my_functions() {

    $my_functions_path = STYLESHEETPATH . '/my_functions.php';
    if (file_exists($my_functions_path)) {
        require_once($my_functions_path);
    }
}

add_action('wp_head', 'add_my_functions');

Then you can adapt the child theme from a clean starting point using my-functions.php. For example:

<?php

function my_byline($byline = '') {
    global $post;

    $byline = "[Empty Byline]";
    return $byline;
}

add_filter('hybrid_byline', 'my_byline');

?>

I’m pretty sure I understand scope well and I consider myself a dynamic scope survivor due to my use of emacs lisp. I’ve never liked it though. So, for those of us who don’t remember Perl 4, what is dynamic scope?

You know those "global" variables that perl provides, such as $/ ? When you do this:

{
    local $/ = undef;
    # code
}

you’re introducing a dynamic scope. $/ is set to its previous value after the scope finishes.

Emacs Lisp and Dynamic Scope

Emacs lisp has loads of global variables all over the place that you can override. One I use a lot is inhibit-read-only. Dynamically scope that to non-nil and it is possible to write into read-only buffers.

(let ((inhibit-read-only t))
  (insert "hello"))

Back to Perl.

Under the covers, the <> operator is probably implemented a bit like this (only much more efficiently).

open my $fh, '<', $ARGV[0];
printf '^^^%s$$$' . "\n", get_input($fh);
{
    local $GLOBAL::delimiter = undef;
    printf '^^^%s$$$' . "\n", get_input($fh);
}

sub get_input
{
    my $fh = shift;
    my $buffer = '';
    my $c;
    while (!defined($GLOBAL::delimiter) or $buffer !~ /$GLOBAL::delimiter$/) {
        my $read = read $fh, $c, 1;
        if (!defined($read)) {
            die $!;
        } elsif (!$read) {
            last;
        }
        # printf "C is[%s]\n", (ord($c) < 32) ? ord($c) : $c;
        $buffer .= $c;
    }
    return $buffer;
}

If you’re not a dynamic scope aficionado, you’re probably thinking, why doesn’t get_input just have another parameter called delimiter which is defaulted to "\n" or whatever.

The dynamic scope guys will probably respond that what about if you need to override the behaviour from the top of a deep deep call stack ?

I have a bunch of superior ways of doing this using O-O and dynamic scope doesn’t play nicely with my [mostly] lexical variables in any case.

And Finally…

I was under the impression that dynamic scope was pretty much non-existent in modern languages. Perl and Common Lisp have it, but lexical scope is, at least culturally, the default. Python doesn’t really have proper scoping at all. Dunno about Ruby, did those guys inherit it?

I was surprised to see Stevan mention in the comments that F# has it.

I often need to process a constantly updating resource. Sometimes the resource is a complex database backed application with a current state and a list of updates.

Generally in these cases the procedure is as follows:

• subscribe to the updates and place them on a queue
• process the current state
• process the updates, beginning with the ones which were queued while processing the current state

If you start by processing the current state and then subscribe to the updates, you’ll miss everything that happened while you were processing the current state.

POE

For Perl users, POE handles this nicely. The subscriber and the current state processor can be started in different sessions which trigger each-other at the important checkpoints. For example, the current state processor shouldn’t start until the subscriber has successfully subscribed.

POE::Wheel::FollowTail

Other times, the resource is something much simpler – a logfile

POE includes POE::Wheel::FollowTail which is able to follow logfiles. It isn’t necessary to subscribe to updates before processing the file as POE::Wheel::FollowTail->new() takes a Seek parameter which allows you to start from the beginning.

$_[HEAP]{followtail} = POE::Wheel::FollowTail->new(
    Filename => $logfile,
    InputEvent => "got_log_line",
    ResetEvent => "got_log_rollover",
    Seek => 0,
);

When FollowTail Isn’t an Option

In some circumstances, it isn’t possible to use FollowTail. For example, the server where the logfile is, may only allow simple commands to be run, not scripts. In this case, the solution could be POE::Wheel::Run.

tail(1) usually takes a parameter that will allow you to start processing the logfile from the start.

ssh servername 'tail -n+0 -f /full/path/here/logfile.txt'

Most well-written perl modules use croak or carp instead of die or warn so that you can see which line in the calling code resulted in the error message. When debugging it can be helpful to see a full stacktrace instead.

The easiest option is to add a perl argument -MCarp=verbose.

perl -MCarp=verbose script.pl

Alternatively you can either:

• Add $Carp::Verbose = 1 in your script or
• Add -MCarp=verbose to the PERL5OPT environment variable

Carp.pm documentation