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

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

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

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”](http://justatheory.com/computers/databases/celko-at-yapc.html)
> 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](http://yapc10.org/) this summer. Famed SQL expert [Joe Celko](http://www.celko.com/), author of [numerous volumes on SQL](http://www.amazon.com/Joe-Celko/e/B000ARBFVQ/) syntax and techniques, will be offering two classes on SQL at YAPC:
> – [Introduction to RDBMS and SQL for the Totally Ignorant](http://yapc10.org/yn2009/talk/2050). Well, okay, the name of the course is a bit unfortunate, but the material covered is not. If you know little or nothing about SQL, this course should be a terrific introduction.
> – [The New Stuff in SQL You Don’t Know About](http://yapc10.org/yn2009/talk/2051). So much great stuff has been added to SQL over the years, and ORMs know virtually none of it. Learn how to put that stuff to work in your apps!
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*](http://www.pragprog.com/titles/cfcar2) in preparation for [our webcast “Radical Career Success in a Down Economy”](http://www.oreillynet.com/pub/e/1360) 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](http://betterthangrep.com)? 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](http://perlbuzz.com/how-to-contribute.html) 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](http://www.fsf.org/blogs/community/kindle-swindle-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”](http://blogs.suntimes.com/ebert/2009/06/the_oreilly_procedure.html) on the lowering of the standards of debate in our society.

PHP’s overly compliant subclassing

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
<?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->set_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](http://use.perl.org/~masak/journal/39090), called “How can we scale kindness?”, boils down my frustration with anti-helpful behaviors like geek pissing contests, [telling newbies “RTFM”](http://perl.plover.com/yak/12views/samples/notes.html#sl-33) and [calling people “fuckhead”](http://petdance.com/perl/geek-culture/).
> 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

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](http://github.com/petdance/vim-perl/tree/master) 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](http://github.com/petdance/vim-perl/issues), and I created a [Google group for vim-perl](http://groups.google.com/group/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

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