June 2009 Archives

Promote Perl 6 by saying "Perl 5"


Perl 6 is hurtling toward completion. The specification is nearly complete, and Rakudo now passes 68% of the specification tests. Applications like November are being written in Perl 6. Perl 6 is no vaporware, and the day when Perl 6 is ready for widespread use is coming quickly.

Perl 6 has been in development since 2000, and in that time many people may have forgotten about the plans we've had for Perl 6. There may be those who have never even heard about the plans for Perl 6. Those of us who live in the Perl world are aware of the great changes afoot, but there are plenty of people who are not.

I think that the time is right to help make those people aware of Perl 6, and to remind them constantly of what's coming. My proposed technique is simple and it takes advantage of the key elements of time and repetition to help remind everyone about Perl 6.

We need to stop referring to Perl 5 as "Perl" and start calling it "Perl 5."

Specifying the "5" in "Perl 5" calls attention to the fact that there is more than one Perl. It makes the listener or reader who is unaware of Perl 6 wonder why the 5 is specified. For the reader who knows about Perl 6, hearing "Perl 5" reminds her that Perl 6 also exists.

I don't think it will be too tough. All I ask is that, at the very least, when writing about Perl 5 in your blogs or mailing lists that you specify the version you're talking about. It doesn't even need to be every instance. I'm guessing we'll find that repeatedly saying "Perl 5" in a long message will get tedious both for writer and reader.

I think the way to look at it is that "Perl 5" is the formal name for the language, and later references can refer to it as "Perl," almost like a nickname. Just that first reminder of "Perl 5" will be enough to help lodge in the reader's brain.

With enough time & repetition, it will get to be habit in our minds. With enough time & repetition, the computing world will be reminded of Perl 6 coming soon.

Movable Type fork Melody is an opportunity to harness CPAN

| No Comments

Reposted from a blog entry by Mark Stosberg

Today Melody was announced as a fork of the Perl-based Movable Type platform. I helped the Melody project as it prepared to launch, in part advising on how to best to relate to the Perl community.  One of the stated interests of Melody is to refactor the project to use CGI::Application, which I maintain. Tim Appnel has already spelled out a vision of what a "CPANization" of Movable Type might look like, and I've looked in depth at what the initial steps towards using CGI::Application could be.

My own vision for Melody is a code base that's very focused on publishing and content management, with all the infrastructure outsourced to CPAN modules that are well-written, well-documented, and well-tested.  The collaboration between Melody and CPAN would be a two-way code flow. While there are more CPAN modules that Melody could make use of, there are number of pieces of Melody which should be packaged as independent modules on their own and released to CPAN.

One example is the great "dirification" that already exists in Movable Type. This is the functionality that turns any given string of words into a reasonable representation in URLs. It seems like an easy problem on the surface, but Movable Type has a sophisticated solution that takes into account what it means to do this well across many different languages. I also couldn't find any existing CPAN module which already takes on this problem space, so I started to extract this out of Movable Type myself and published a draft of String::Dirify. For that initial release, I ripped out all the fancy multi-language support, and there is still more significant work to be done to untangle this layer from from Movable Type. (If you want to pick up that project and work on it, there's also some discussion of testing String::Dirify).

While Movable Type already had an open source release, I expect Melody to have  a more adventurous evolution, and I look forward to it becoming a shining star in the Perl community, not just for the exterior functionality, but also because internals have an opportunity to become an example of best practices.

Mark Stosberg has been using programming Perl for the web for over a decade. He is the Principal Developer at Summersault and maintains several CPAN modules including Titanium and Data::FormValidator.

Perlbuzz news roundup for 2009-06-24

| No Comments

How to announce an event, or, awesome is not always self-evident


Which of these two events sounds more interesting?

Joe Celko is going to be giving talks at YAPC this summer.

Or, in an announcement entitled "Learn Mad Database Skillz at YAPC::NA 2009"

It really, truly pays to learn the ins and outs of SQL, just like any other language. And if you’re a Perl hacker, you have a great opportunity to do just that at YAPC::NA 10 this summer. Famed SQL expert Joe Celko, author of numerous volumes on SQL syntax and techniques, will be offering two classes on SQL at YAPC:

That first announcement is usually what I get when people ask me to announce something in Perlbuzz. "Hey, we're having the East Podunk Perlapalooza next week." Yeah, so? Who cares? Why will Perlbuzz readers care?

David Wheeler, author of the latter text, understands what most geeks seem not to grasp: The mere existence of your Foo is not enough for people to be interested. Look at all the topics that David covers, to encourage interest from as wide a range of people as possible.

  • What YAPC is.
  • Who Joe Celko is.
  • Joe Celko's body of work.
  • Why we still need to know SQL in the age of ORMs.

I was reminded of this while going through Chad Fowler's excellent The Passionate Programmer in preparation for our webcast "Radical Career Success in a Down Economy" next week. One of Chad's big points is "Your skills are not self-evident." It's not enough to do great work at work, but you must also let people know about what you've done, specifically your boss. The same is true of your open source projects.

Why do people use ack? It's useful, but how do people know about it? I talk about it, and I tell people why they should use it on its home page, in a section called "Top 10 reasons you should use ack."

If someone asks you about your project, can you explain its awesomeness, and why he should use it? If not, why are you bothering? And if you can, are telling everyone you can about it? If not, why are you bothering?

For more on writing interesting announcements, please see the Perlbuzz How to contribute page.

Free Software Foundation helps no one with name-calling


Discourse on the Net is tough enough without lowering yourself to pointless name calling. The Free Software Foundation ought to know better, especially when their work is so important.

Today John Sullivan posted a story about problems the FSF has with Amazon's release of the Kindle source code yesterday. Their three main issues are:

  • Not all the code is included.
  • Changes to Kindle code do users no good because users cannot legally update their devices
  • Important features remain secret.

The article is well-thought out, and clearly makes the three points. It would be a fine article if not for the insulting headline: No, Amazon did not release all of the Swindle's source code.

Why, FSF? Your article stands on its own, so why sling the mud? Why lower yourselves to juvenile name-calling? What do you hope to gain by calling the Kindle the Swindle? Are we to think "Ho, ho, those clever FSF folks!" I can't imagine.

Relatedly, please read Roger Ebert's article "The O'Reilly Procedure" on the lowering of the standards of debate in our society.

PHP's overly compliant subclassing

| 1 Comment

Please shake your head in sympathy at this bit of terrible design in PHP's class handling. The code below is a simplified sample version of some real code I was working on last night.

$ cat foo.php

error_reporting( E_ALL ^ E_STRICT );

class Dog {
    protected $_bark;

    function __construct() {
        $this->_bark = 'Generic woof';

    function speak() {
        print $this->_bark . "\n";

class Chihuahua extends Dog {
    function set_bark() {
        $this->_bark = 'Yip yip';

$doggie = new Chihuahua();
$doggie->speak(); // Generic bark
$doggie->speak(); // Specialized bark

$ php foo.php
Generic woof
Yip yip

That's about what you'd expect, right? Call a method in the subclass to modify something in the parent class, and then print it out. Nothing goofy, right?

Last night, I spent at least an hour figuring out why my code was still printing "Generic woof" instead of "Yip yip." Finally, I tried printing out my $doggie object with print_r, PHP's dumper mechanism, and it all became clear.

$ php foo.php
Generic woof
Generic woof
Chihuahua Object
    [_bark:private] => Generic woof
    [_bark] => Yip yip

It turns out that at some point I had made $_bark private in the Dog base class, thus breaking the ->set_bark() method. What is so infuriating is that instead of telling me that I was trying to modify a private class member, PHP decided to make a separate class member that Chihuahua could see, different from the member in the base class. It created a class member that I did not declare myself.

I'd love to know the logic behind this design decision. Best I can figure, it was to allow future modifications of base classes without causing name conflicts, but as far as I'm concerned, silently letting people do The Wrong Thing, even with warnings maximized is exactly the wrong behavior. PHP's tendency to silently ignore problems has always frustrated me.

As programmers, we should optimize for telling other programmers that something is wrong, rather than sweeping it under the carpet. Naked Perl doesn't do this, of course, but that's why we have warnings and strict.

Every day, we contribute to shaping our community


Masak's recent post on use.perl.org, called "How can we scale kindness?", boils down my frustration with anti-helpful behaviors like geek pissing contests, telling newbies "RTFM" and calling people "fuckhead".

Every day, we contribute to shaping our community.

By extension, I think it's fair to say that allowing anti-helpfulness to stand unanswered is part of shaping our community. I might even expand it to say:

Every day, through action and inaction, we contribute to shaping our community.

I understand that every community will have jerks, and the Perl community is no different. However, it's possible to balance the bad signal with good. Answering hostile behavior doesn't have to be, and in fact shouldn't be, a flame war. Instead, bypass the damage of the hostile participants and address the topics as they should be.

If a newbie in IRC asks a "dumb" question, and is beaten down by the regulars in the channel, go ahead and answer the question for him. It's a far better response than ragging on the beaters.

How do you handle the negative in the Perl community?

Perlbuzz news roundup for 2009-06-07

| No Comments

These links are collected from the Perlbuzz Twitter feed. If you have suggestions for news bits, please mail me at andy@perlbuzz.com.

Attention all Vim-using Perl programmers


If you use Vim for your Perl programming, here's a new project and mailing list you might be interested in.

A few months ago I became the maintainer of the syntax/perl.vim file that comes with vim. I started a github project for it for maintaining the perl.vim file, and for starting to get a perl6.vim file together that could be put into the vim core as well. There are a couple of versions of perl6.vim and I need to make sure we get the latest/greatest to Bram for inclusion.

Now that github added capability for issue tracking, there's now a vim-perl issue tracker, and I created a Google group for vim-perl as well.

This project + group are not intended to be just about the .vim files. I want to discuss all aspects of using Perl and Vim together, so join in and share your tips and ideas.

If there are any Emacs, Eclipse, etc equivalents, let me know so I can post about those, too.

Perlbuzz news roundup 2009-06-02

| No Comments
« May 2009 | Main Index | Archives | July 2009 »