Perhaps I'm just in a pessimistic mood, but what makes you think we Perl use is growing, and not shrinking? Esp as a percentage, I think it's shrinking. People are moving away from perl solutions into PHP and Java, and even, alas and alack, VB.

I suspect the major problem is that people confuse Perl, the language, with all the things that have been associated with Perl over it's long history. (Yes, long, compared to PHP and Java.) Specificly, people get Perl and CGI confused (perl is slow compared to PHP!) and Perl5 and Perl4 confused (Perl isn't suited for large projects).

Even worse, there's the impression (correct and self-perpetuating) for busniesspeople that any random you pick up will know Java, PHP, and VB. For those just learning, there's the impression that busniesspeople want to hire people that know Java, PHP, and VB, and don't care about Perl.

What I want to know is if we know how to change these vicious cycles, or if I should just bite the bullet, and start branching out more into languages with more resume-power.

Perhaps I'm just in a pessimistic mood, but what makes you think we Perl use is growing, and not shrinking?

Well, one indicator is the number of modules contributed to the CPAN. I have the impression that there are more uploads per day today than there was even in the height of the dot-com bubble.

-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.

I'm not sure what that indicates about how much people are using vs how people are using. Perhaps there's an increase in lone hackers (more apt to upload modules) and a larger decrease in coporate use (less apt to).

Perhaps, as I said, I'm simply pessimistic. Looking for jobs (even for other people) does that to me.

---

Warning: Unless otherwise stated, code is untested. Do not use without understanding. Code is posted in the hopes it is useful, but without warranty. All copyrights are relinquished into the public domain unless otherwise stated. I am not an angel. I am capable of error, and err on a fairly regular basis. If I made a mistake, please let me know (such as by replying to this node).

Feel free to branch out, just keep Perl in the toolbox and bring it out to get the heavy lifting done wherever you go. That's how Perl has always subsisted — even Microsoft rely heavily on Perl “in this day and age,” whether their marketroids would admit to it or not. Perl isn't very visible, but it's very present.

Makeshifts last the longest.

I agree with Aristotle. My current job description makes no mention of Perl but I use it extensively to get real work done. Most of the time my employer does not know what tool I've used to do something that was formerly difficult or impossible.

In today's marketplace I don't think Perl will get you hired as much as keep you employed (assuming you know how to use it appropriately).

That's my experience, too.

With my employer, the nice, shiny frontends are concocted either in Java, VB or PHP.
The backends -- bulky scripts "interconnecting" data-streams -- are written in perl. Confessed, they are sprinkled with some tasty C.

Since December, 2004, PHP-development is stopped and the "web-applications" -- I hate that word -- are to be re-written in perl. Even our VB-programmer want to have a tutorial in perl

perl may or may not be an advantage in a resume, but down there in the machine room, with crying users, clueless PHBs and grumbling customers at the phone, there it is the kind of heavy gear you like to have around.

If you are concerned, don't be. More languages in your toolkit is always a good thing and if something else comes along, lessened learned from Perl still apply. Ruby and Python really exude much of what made Perl popular. PHP, well, I don't care for that one as much -- but it's slowly realizing that it needs to change.

Please do not modify this code and run it without thinking about the consequences. The sleep interval is likely not long enough if you are going to hammer jcwren's server for every single user. Another useful feature would be to have signal handling allowing persistency of data (DB) even when you abort early. Additionally, it should be modified to allow you to resume where it left off. This would make gathering the stats over time much more server friendly.

#!/usr/bin/perl
use strict;
use warnings;
use HTML::TableContentParser;
use WWW::Mechanize;

use constant DATE  =>  3;
use constant STATS =>  4;

my %opt = (
    url => 'http://tinymicros.com/pm/index.php?goto=monkstats&sortopt=
+13&sortlist=1,3&',
    end => 500,
    pos => 0,
);
my $mech = WWW::Mechanize->new( autocheck => 1 );

my %date;
while ( $opt{pos} <= $opt{end} ) {
    $mech->get( $opt{url} . '&start=' . $opt{pos} );

    my $table = HTML::TableContentParser->new()->parse( $mech->content
+() );
    for my $row ( @{ $table->[ STATS ]{rows} } ) {
        my $stamp = ${ $row->{cells} }[ DATE ]{data};
        next if ! $stamp;
        ($stamp) = $stamp =~ m|<NOBR>(.*)</NOBR>|;
        $date{ substr($stamp, 0, 10) }++;
    }
    $opt{pos} += 50;
    select(undef, undef, undef, 0.75);
}
print "$_,$date{$_}\n" for sort keys %date;
[download]