Saying something nice about programming languages

Saying something nice about programming languages

I recently saw several instances of an interesting proto-meme from a couple years ago: can you find something nice to say about every programming language you’ve used? Here’s my try (limited mostly to languages I’ve used at work or for extended periods), organized chronologically:
[Read more...]

Naming the parts of a URL

Naming the parts of a URL

Tantek Çelik has an interesting summary of how different programming languages and libraries break down the parts of a URL. He’d left Perl off his list, so I pointed him to the URI module on CPAN, which he’s added to his table.

One inter-language discrepancy Tantek found has resulted in the silliest bug-report debate I’ve seen in a while. It’s remarkable how upset people seem to get when arguing over whether the “protocol” part of the URL should include the colon or not!

DomainSponsor’s distributed server architecture

DomainSponsor’s distributed server architecture

DomainSponsor is Oversee’s domain parking division. When people have domain names that they’re not ready to use yet, we show ads on them. DomainSponsor gets around a billion visits per month.

To serve ads on millions of pages per day, we used to use a fairly traditional LAMP stack. We used Apache with mod_perl to run a fairly complicated tangle of Perl code which queried several back-end MySQL databases and other back-end servers, in order to choose what to put on each page. One of the biggest problems we had was that we wanted to be able to easily add new (possibly buggy) features for A/B testing, knowing that many of those features would fail and be discarded. The old way we did this was to have a separate cluster of servers running the test version of the code. The trouble was that the test cluster was never 100% identical to the main production cluster, and the redirect needed to send a sample of requests to the test cluster introduced a delay, so we had problems with test results not being reproducible when we later launched the same feature in the main production cluster. [Read more...]

Modernizing Perl

Modernizing Perl

At Oversee, we use a lot of Perl.  There are many web developers who think that Perl is obsolete.  The current “cool” languages for server-side web development seem to be Ruby, Python, or even Javascript.  The scornful developers base this opinion on the undeniable fact that Perl’s been around a long time, and there’s a lot of really crappy unreadable old Perl code floating around the Web.  What those critics often don’t realize is that Perl has been evolving quite a bit over the last few years.  This evolution is taking place on 3 fronts: language, libraries, and usage.

The language itself is changing, and new major versions of Perl are being released more frequently than in the past.  Perl 5.8 was the only major release for 5 years; since then, Perl development has moved to a roughly annual schedule of major releases, and there’s been a lot of conversations about just how much backwards compatibility these new versions need.  Perl 5.10 is bundled with most newer Linux distros, Perl 5.12 was released last spring, and Perl 5.14 is coming next spring.

Perl libraries are able to change faster than the core language, because new, incompatible libraries can be created alongside old libraries.  Because of Perl’s “There’s More Than One Way To Do It” philosophy, it’s possible to create libraries that provide major changes in the language, while still running on the same underlying core interpreter.  The most substantial example of this is Moose, a “post-modern object system” for Perl.  Moose takes ideas from Perl 6, Smalltalk, CLOS, Java, Ruby, and other more obscure object-oriented languages, and combines them into a very flexible and succinct way of creating and using objects in Perl.  In a sense, Moose creates a new OO dialect (related to both Perl 5 and Perl 6) on top of Perl 5.

Perhaps the biggest change in Perl is not what the language or the libraries provide, but what sophisticated developers are taking from it.  Starting with the publication of Damien Conway’s “Perl Best Practices” in 2005, there’s been a growing recognition that “There’s More Than One Way To Do It, But Some Ways Are Better And Some Are Worse”.  Many of Conway’s recommendations are still widely accepted, and there’s now even a tool (perlcritic) to automatically check Perl source for compliance.  However, some of his suggestions are now seen as outdated; in particular, the OO approaches he recommends have been obsoleted by Moose.  More recently, several prominent Perl authors have written about the latest consensus on how best to code in Perl. The 2nd edition of “Effective Perl Programming” by Hall, McAdams and foy came out last spring, and Chromatic’s “Modern Perl” was just released last week.

Many of the usage changes are simply a matter of encouraging programmers to more consistently use features that have been available for a while.  For example, in a recent blog post a Perl programmer talks about getting his colleagues to adopt the 3-argument form of the open() function and lexically-scoped filehandles (instead of global filehandles), both features introduced in Perl 5.6.0 in 2000.  The trouble is, there are lots of Perl examples which have been copied from older Perl examples, which might do things in ways that are more error-prone than necessary.

To summarize, Perl has changed as much as any other part of the world in the last 10 years.  If you rejected Perl based on old stereotypes, it might be time to take another look.  If you know and love Perl, it still might be time to go back and learn some new ways of using it.