Note: Beware of the instructions in the link below. It has you do far more work than is necessary. See this follow-up article for details.

Here's the first big blog post I've seen about Strawberry Perl: How to install and set up Strawberry Perl

I am writing this article with much joy and glee.... Active State no longer has a monopoly on the issue of Perl on the Windows platform

I haven't read the Strawberry Perl docs, since I'm Windows-free. The blog post gives details about what tools are necessary to make the install, with links to the tools. Now, I thought that part of Strawberry Perl was that you wouldn't need any external tools, but maybe they're just for building CPAN modules.

Working on my Big Dirty PHP Project at work, I've found this bit of code in many places.

$categories = "";
$categories = Array();

Why is $categories set to an empty string, and then an array? It's not necessary to pre-initialize a variable before setting it to another value. So why is the code there? It's not just one case. It's throughout the codebase, where I delete the first line whenever I find it.

The original programmer is (thankfully) no longer around to ask, but I'm guessing it's superstition. Perhaps he had some problem that went away for an unrelated reason when he added the first line of the code. The problem is that he never considered why.

Here's another coding horror to avoid in Perl. Ever seen a regular expression by someone who wasn't entirely familiar with regexes and quoted everything whether it needed it or not?

if ( $name =~ /Marcus Holland-Moritz/ )

The hyphen in Marcus's name isn't a metacharacter, but the unsure, superstitious programmer will quote it anyway. "Eh, it doesn't hurt anything," he may reply, but it also demonstrates his non-mastery of regexes.

If you ever find a piece of your code where you can't understand exactly why it works, why every single statement exists, stop and rework it until you do.

Michael Schwern has written a column for Andy Oram's Beautiful Code blog called LWP::Simple - Simple Goal, Simple Interface. In it, he talks about minimizing the "gulf of execution" with a two-line easy-to-understand Perl program:

use LWP::Simple;
my $page = get("http://www.google.com");

Bravo to Schwern to getting the words "Perl" and "beautiful code" together. I can't wait to see part two.

The news about Perl 5.10 is everywhere, and it didn't take that much emailing of news editors on my part. However, I have one regret.

I should have made it more clear in the announcement that Perl 5.10 is the first major change in the Perl language in five years. What I wrote was "Today the Perl Foundation announces the release of Perl 5.10, the first major upgrade to the wildly popular dynamic programming language in over five years." Unfortunately, that got shortened in headlines to the incorrect "first release of Perl in five years", which ignores 5.8.1 through 5.8.8, and has since been spread far and wide.

I'm glad the news is getting out there, but wish it were more accurate.

Dean Wilson reveals My Favourite Three Features in a recent blog post, but doesn't discuss my #1 feature of Perl 5.10: The say command.

Why love say so much? It's just the same as print with a "n" at the end, right? Yup, but that "n" causes heartache for me in life. See, I've been working on removing interpolation from my life wherever possible. For instance, we've probably all seen beginners do something like:

some_func( "$str" );

where the quotes around $str are unnecessary. (Yes, I know there could be overloaded stringification, but I'm ignoring that possibility here.) That function call should be done as:

some_func( $str );

By the same token, I don't use double quotes any more than necessary. Rather than creating a string as:

my $x = "Bloofga";

do it as

my $x = 'Bloofga';

It's not about speedups. It's about not making the code do anything more than it has to, so that the next programmer does not have to ask "why is this work getting done?" If the code doesn't need the double-quoting, then don't use the double-quoting.

I started down this road when I read this rule in Perl Best Practices, but ignored it. "Eh, no biggie," I thought. Then I started using Perl::Critic, and it complained about everywhere I was using double quotes. As I examined those complaints, I came around to realize that if you're having the computer do work, the next programmer has to wonder why.

So now we get the say command, and I get to eliminate at least 50% of my necessary string interpolation. Instead of:

print "Your results are:n";

I can now use:

say 'Your results are:';

So much cleaner. In a color-coding editor like vim, the distinction is even clearer, and as MJD likes to point out, "It's easier to see than to think."

Start using say. Even if you're not on 5.10 yet, you can use Perl6::Say for most of the places that say works in 5.10. Even better, stop using unnecessary interpolation altogether.

Liz Cortell writes in with important updates to your time modules:

Whether travelling, calling overseas or maintaining software, time zones are always a headache. DateTime::TimeZone has seen a couple of changes this month.

0.70, released December 3, was changed to incorporate Hugo Chavez's declaration of a new time zone for Venezuela.

0.71, released today, "Fixes a major bug in the generation of time zone data. This bug affected any time zone that has more than one rule (most of them) and currently has no DST changes (many of them). An example would be America/Caracas. The symptom would either be mistakes about the current time zone or bogus exceptions when trying to create a local date."

Andy Armstrong graciously provides his take on Perl 6. I've even left those crazy Brit spellings. -- Andy

Perl needs Perl 6 and the wider Perl community needs to understand why.

When I first got into computers I worried, briefly, that everything I learnt would inevitably be outmoded. I don't want to scare anyone unduly but there will come a time when Perl 5 is outdated. Slow, ugly, verbose, arbitrary: it will become all of those and worse.

That is the fate of all languages. At least I hope that's the fate of all current languages. These days if I really want to scare myself I need only imagine that the current state of the art is is a good as it ever gets. If that doesn't worry you try to imagine a parallel universe in which our understanding of computers hit a glass ceiling any time in the past fifty years. Imagine COBOL as pinnacle of language design, 64k as a generous helping of memory, punched cards baby! Happy days, certainly, but I'm glad we were able to leave them behind.

As more of the world depends on computers there's a growing force that slows change. The enemy of evolution in language design is the installed user base. In the case of a successful language like Perl millions of people may now be affected by an incompatible language change. The Perl 5 Porters must always balance the needs of the future with those of the past and that places an upper limit of the rate at which Perl 5 can mutate.

What to do? How do you move forward if you're constantly looking over your shoulder? You take advantage of a fortunate property of software: that it is possible to simultaneously care for and conservatively develop the current active branch of a language and forge into the future with a clean new version. Two siblings: the elder healthy, but constrained by responsibilities, the younger relatively free and able to learn from the elder's mistakes without repeating them. Perl 5 and Perl 6.

"But Perl 6 is taking too long..."

But Perl 6 is taking too long to mature. More than seven years is embarrassing, right? Not really. Perl wasn't really the Perl we know and love until Perl 5. For the first ten or so years Perl was a lesser language. Sure, the step from Perl 5 to Perl 6 will be bigger than the step from 4 to 5. The jump from 4 to 5 was in its time the biggest seismic shift the Perl world had seen. There's a trend there; the steps are getting bigger all the time. There was no significant dynamic language movement when Perl 1 entered the world. Perl 6 is gestating in a rather different environment.

Perl 5 is not yet decrepit. Rumours of its death greatly exaggerated (or imagined). Perl 6 doesn't yet need to come of age so it makes sense for it to continue to mature in a relatively protected environment. As long as Perl 5 remains viable it's sensible to give Perl 6 the space it needs to grow because when its time comes it's going to face stiff competition from its elder and from Ruby, Python and others.

Rather than impatient foot tapping, Perl 6 needs the help and nurture of the Perl community. The Perl 6 development process is transparent and open. Anyone with something useful to contribute will be welcomed. If you self-identify as a Perl person then Perl 6 is in part your responsibility. And if you can't usefully contribute then, please, quietly reflect on the debt of gratitude you owe to those who do. They're working to guarantee your future.

Perl 6 is not a liability

Perl 6 is not a liability. There's no need to be defensive about it. Paul Cory would like to rebrand Perl 6 into the shadows. That's the kind of Stalinist revisionism favoured by corporations that realise that their "next big thing" has become an embarrassing albatross. It's a response to Perl 6 that the circumstances do not require.

Here are his reasons:

1) It emphasises the "inadequacies" of Perl 5.

All languages have inadequacies, imperfections, miss-features, cruft. Perl 5 is no different. Fortunately, instead of brushing them under the rug, the Perl 6 team is actively seeking to right those wrongs. A question: would you rather use a language that's maintained by people who are a) in denial about its inadequacies or b) actively developing a new language based on recognised shortcomings? I hope that's a rhetorical question.

2) It makes the development community look unorganized, at best. People comparing at the development pace of Python, Ruby and PHP to Perl 6 are likely to come to harsher conclusions about the community's focus, viability and competence, based on Perl 6's seven-year, and counting, gestation period.

Those hypothetical people are wrong and I don't want to be part of a community that panders to their views. The Perl 5 Porters are doing a great job of continuously improving Perl 5 within the constraints that popularity brings. The Perl 6 team are laying the foundations for the next generation of Perl. Perl 5 and Perl 6 have a mutually beneficial relationship: features, tools and ideas are traded freely between the two groups. It's healthy, responsible and creative.

Python and Ruby have, to their credit, somewhat similar splits between far sighted strategic development and tactical improvements to the current language generation. PHP is a bizarre bazaar that does not provide a model other language communities should emulate.

3) It creates uncertainty: what happens to Perl 5 when Perl 6 finally drops? How much new stuff will I have to learn? How will my existing code work, or not, if I upgrade? Why should I invest time in Perl 5 if Perl 6 is just around the corner, and will be far superior?

Learning to deal with an uncertain future comes with the territory of computing. Continual improvement necessarily means that things will change.

Perl 6 is visible proof that we have vision. Perl 5 is visible proof that we can maintain an extremely high quality programming language. These facts combined should give observers confidence about the health of Perl. As a community we certainly need to work to allay fears and calibrate expectations. But let's not start by hiding one of our greatest assets, ok?

4) It creates frustration inside the community. Perl 6 has been "coming soon" for 7.5 years now. It's hard to remain excited about something that long with no payoff.

Welcome to the world of free software. Instead of waiting for Godot we can go and meet him half way; help him carry his load. Let's be explicit here: if Perl is part of your life or career and you're tired of waiting for Perl 6 help make it happen.

You don't have to contribute code to help. Learn more about Perl 6 so you can explain it to others. If you find it hard to learn make it easier for others: write an article that explains some of the important points, give talks, learn so you can teach.

5) The story is confusing: Pugs? Haskell? Parrot? Two development tracks? I thought this was about Perl? Yes, I have an idea of what those things are, but most folks outside the community (and a fair few inside, I'd wager) don't know, don't care, and shouldn't have to.

If the story is confusing we need to tell it more clearly. That doesn't justify changing the underlying technical narrative.

In a commodified world criticism and spending discretion are the consumer's only levers. We crave influence over the things we consume. In the absence of direct influence over a product's design we use criticism as a proxy for control. We hope that they'll make the next version better as a result.

Criticism is still valid in the free software world but it's importance is de-emphasised. You can criticise or you can help. In fact you can criticise and help.

It's important that Perl 6 is not immune from scrutiny but if you're frustrated that it's taking a while then volunteer. The Perl 6 team is small at the moment; small enough that a few well placed contributions can make a real difference. Let's not default to bitching about it when we have the opportunity of contributing to its success.

Why not make 2008 the year you do something for Perl 6?

Andy Armstrong has been developing Perl programs and following the language's progress since Perl 4.036. He has released more than thirty CPAN modules and is currently working to help both the Perl 5 and the Perl 6 teams to implement parallelised execution of their test suites

Patrick Michaud provides us with this brief recap of Perl 6. Patrick and I are going to be working on the Perl 6 development dashboard in the next few days to try to get a what's done and what's needed to release story to tell. -- Andy

Andy Lester asked:

Is there any way we can say "Here's what we've done and here's what's left?" At least that's a story I can tell. At least that kind of leaves us with "See, you can see the shape of the house and the roof is on, and we're working on the wiring and the plumbing."

I probably can't tell the full story of "Here's what we've done", but I think I can give an outline for one. Apologies in advance for any factual errors or omissions here -- many parts of the "story" occurred before I became an active participant of Perl 6 development. Also, this shouldn't be taken as an official story of the Perl 6 community or development team, it's just my answer to the question that Andy posed.

First, we have a Perl 6 language specification, as given by the synopses. People who have looked and played with the language given by that specification seem to really like it. We can't say that the specification is complete or frozen, because as we work on implementing the language we're finding places where the spec needs improvement. Some people express that the answer is to freeze the specification so we can get at least one implementation working; I entirely disagree with that. It's important that we retain flexibility to continue to improve the specification in response to things learned from the implementation(s).

We have at least one substantial Perl 6 implementation, known as Pugs. In fact, it's the experience of writing and using Pugs that has prompted important changes to the language specification. Pugs is available from pugscode.org.

There's is another implementation of Perl 6 being done for Parrot, called "perl6". Parrot is a virtual machine intended to support Perl 6 and other dynamic languages, such as Python, Ruby, PHP, and the like. Some people may feel that Parrot is an unnecessary distraction from Perl 6, but it's clear that Perl 6 will need some sort of virtual machine under it, just like Perl 5 has. Early in the Perl 6 development, the available virtual machine options were basically: reuse the Perl 5 VM somehow, try to use another VM, or build a new one. Early efforts at writing Perl 6 on top of Perl 5 didn't appear to be working out so well, thus when I started development in 2004 I was advised by the design team to start afresh with Parrot, and that's the approach that perl6 has taken.

Having a virtual machine isn't sufficient -- we also need tools for building programs for that virtual machine. For a couple of years we've had a grammar engine to build parsers in Parrot, and that seems to be working well. Within the past few months we've also completed a code generator for abstract syntax trees (part of the "Parrot Compiler Toolkit") and a simple transformation language ("Not Quite Perl"). The completion of these tools appears to have boosted development speed on Parrot languages, including Perl 6, PHP, Python, etc., by at least an order of magnitude. The tools are also dramatically widening the scope of people who can productively participate in compiler development. We still need work on documentation and tutorials for the new tools so that we can increase the pace of development even further, and that's a primary focus for me at the moment.

We have an implementation of Perl 6 on Parrot called "perl6". There has been an implementation of Perl 6 on Parrot for over a year now, but progress on it had stalled because we needed improvements to Parrot and to the compiler tools. As of mid-December those improvements are now complete, and within the past two weeks the perl6 compiler has been completely rewritten to make use of the new Parrot compiler tools. Even though the new implementation is only a couple of weeks old, we already see huge gains in the quality and extensibility of the compiler, and in the ability for others to participate in its development. Because the current implementation is so new, I'm reluctant to hazard a guess as to an anticipated pace of development going forward, other than to say it should be much faster than what has been. I do tend to think that we'll be reaching the "workable implementation" stage in a matter of weeks instead of months or years.

Lastly, there is a substantial suite of tests written for Perl 6 language features, currently held in the Pugs repository. These tests are about to undergo substantial review and revision for correctness, completeness, and cross-compatibility among the implementations that are in various stages of development.

Looking to the future

Looking to the future and what I expect to see happen in January 2008:

• some sort of working (perhaps primitive) perl6 installation where a person can download a tarball, build perl6, and type something like "perl6 foo.pl" to execute a Perl 6 program.
• documents and publications describing the architecture of the perl6 compiler and how the various Parrot compiler tools fit together
• substantial progress on reorganization and development of the official test suite
• implementation of more Perl 6 language features

As for me, my primary focus has always been on getting a working Perl 6 implementation on Parrot. To me, Perl 6 is not just an interesting research project -- it has a clear deliverable. If we complete a usable implementation of Perl 6, we succeed; if we don't, we fail. It's that straightforward to me.

However, it's also important to have Perl 6 in a reasonable timeframe, and I agree with others that we're certainly pushing our luck there. Many people say that the long development time for Perl 6 has caused it to miss its window of opportunity. Time will tell if this is true, but personally I don't think this will be the case. Yes, Perl 6 has taken far longer than any of us imagined, but Perl 6 and Parrot are also poised to do things that many of us hadn't even dreamed about when we first started. And that's what keeps me working on Perl 6 even when it seems to be taking so long to get to the goal. I find Perl 6 to be such a profound and fundamental improvement in programming that I think the extra time we're all spending at the front end will have an impact and reap rewards measured in terms of decades. So while the delays are hard to take, the end result is worth it to me.

Patrick Michaud is the pumpking for the Perl 6 compiler. He holds a Ph.D. in Computer Science and was formerly a Professor of Computer Science at Texas A&M University-Corpus Christi. He is currently a software developer and consultant focused on open source development and applications, including Perl, PmWiki, and Linux.

Paul Cory has contributed what I hope is the first of many guest editorials on Perlbuzz. -- Andy

Recently, Andy Lester wrote about the zombie question that haunts Perl: Where is Perl 6? One of the questions he posed was:

"And to everyone else, who is willing to help in this task, to help keep the fires of anticipation burning in the public?"

My advice would be to not keep the fires of anticipation burning in the public. For the good of the language, Perl 6 needs to be deemphasized in public, and, in addition, renamed.

How Keeping Perl 6 Front-of-Mind Hurts

1) It emphasizes the "inadequacies" of Perl 5.

2) It makes the development community look unorganized, at best. People comparing at the development pace of Python, Ruby and PHP to Perl 6 are likely to come to harsher conclusions about the community's focus, viability and competence, based on Perl 6's seven-year, and counting, gestation period.

3) It creates uncertainty: what happens to Perl 5 when Perl 6 finally drops? How much new stuff will I have to learn? How will my existing code work, or not, if I upgrade? Why should I invest time in Perl 5 if Perl 6 is just around the corner, and will be far superior?

4) It creates frustration inside the community. Perl 6 has been "coming soon" for 7.5 years now. It's hard to remain excited about something that long with no payoff.

5) The story is confusing: Pugs? Haskell? Parrot? Two development tracks? I thought this was about Perl? Yes, I have an idea of what those things are, but most folks outside the community (and a fair few inside, I'd wager) don't know, don't care, and shouldn't have to.

Basically, the more we push Perl 6, the more we Osborne ourselves.

How Keeping Perl 6 Front of Mind Helps

I got nothing. Honestly, I can't think of a single positive for trying to keep public anticipation burning.

How Deemphasizing Perl 6/Changing its Name Helps

1) Allows us to focus on the strengths and successes of Perl 5.

2) Allows us to tell the development and improvement success story of Perl 5, which is as good as that of any other scripting language.

3) Removes uncertainty that can be used against Perl when companies and developers make decisions about which language to use.

4) Finally, by changing Perl 6's name, to something like PerlNG or PerlFG, we can get away from the "It's just a 1 point upgrade," problem and have a basis for which to talk about it as a "research project." That allows us to both avoid talking about delivery dates, and allows to talk about how cool stuff from PerlNG is finding its way back into Perl 5.

5) Gets us away from all the negatives listed above.

How Deemphasizing Perl 6/Changing its Name Hurts

1) It might be harder to get folks to work on PerlNG if it's not "just around the corner." I happen to think that can be overcome with inside-the-community marketing.

For the record, I greatly appreciate all the work that folks have put into Perl 5 and Perl 6. Nothing here should be taken as a criticism of how the actual development gets done, nor of the talent or the commitment of the developers.

I don't question the desirability of Perl 6 either. I can see how, when it's finally finished, it will be an improvement over any language available.

However, from a Communications standpoint, it's obvious that there are significant problems in communicating about perl to the world at large. Perl 6 has been a Public Relations disaster, one that has made it harder to attract developers, other contributors, users and companies.

Again, from a Communications/PR standpoint, our goal should be to stop shooting ourselves. And that means taking the public focus off Perl 6 as much as possible.

Paul Cory is the Webmaster for the Wake County Public School System in Raleigh, North Carolina. He started using Perl nine years ago to automate some particularly tedious Website updates, and has progressed to the point where Perl glues the entire system website together.

The new say function isn't supported by the perl.vim file that ships with vim. Nick Hibma, the maintainer, tells me it will be updated in the next version of vim. In the meantime, you can hack your local vim files by adding the following line to your ~/.vim/syntax/perl.vim file:

syn keyword perlStatementFiledesc
 binmode close closedir eof fileno getc
 lstat print printf readdir readline readpipe rewinddir
 say select stat tell telldir write
 nextgroup=perlFiledescStatementNocomma skipwhite

Even if you haven't upgraded to Perl 5.10, you can use Jim Keenan's Perl6::Say module to add the say function.

Every so often I get asked that dreaded question "When is Perl 6 coming out?" Sometimes it's a local Perl Mongers meeting, and sometimes it's an email like below, from a reporter at cnet.com, in response to my Perl 5.10 announcement:

What's up with Perl 6/Parrot? I've never covered the issue terribly closely, but it seemed that there was one school of thought that argued for some universal virtual machine and another that wanted to keep Perl more with its duct-tape-of-the-Internet roots. Please feel free to set me straight in this area--I have only passing familiarity.

Is Perl going to stay on a dual 5.x and 6.x track? When is 6 due? How about 5.12?

Stephen Shankland
reporter, CNET News.com
blog: http://www.news.com/underexposed

This is not at all uncommon as a perception. People just don't know about Perl 6, don't know about Parrot, and certainly have never heard of Pugs. Here's what I replied:

Perl 6 is a rewrite of the Perl language. It will feel Perly, and yet become more modern as it pulls in influences from languages like Ruby and Haskell.

Technically, Perl 6 is just a language specification, and there are at least two implementations underway. One of the Perl 6 implementations is named Pugs, and is written in Haskell, on a project led by Audrey Tang. The other Perl 6 implementation is being written to run on top of Parrot. Parrot is a virtual machine for running modern dynamic languages like Perl, PHP and Ruby, among others. The intent is to have Parrot bytecode generated by one system, say, Perl 6, easily interact with any other language's Parrot bytecode.

Yes, Perl 5 and Perl 6 will stay in dual development. Perl 5 has such a huge installed base, it won't be going away any time soon after Perl 6 exists.

There is no due date on Perl 6, and never has been. At this point it's still sort of a big research project. Fortunately, some of the development in Perl 6 has found its way into Perl 5.10, such as the "say" keyword and some regular expression improvements.

I don't think the Perl 5 Porters have even started thinking about a timeline or feature set for 5.12 yet, since 5.10 has only been out for eight days now. From my monitoring of the perl5-porters list, we're just trying to make sure that problems people are reporting with 5.10 are not actually problems with 5.10 itself.

Let me know if you have any other questions.

I've published this open response for two reasons. First, I wanted the core Perl community to get an idea of what outside perception of us is like. People know bits and pieces of what we here in the Perl core echo chamber know.

Second, I wanted to raise the flag again of how outsiders want to know more about Perl 6, and that the first, and in many cases only, thing that they want to know is "Where is it and when will it be out." I've never felt that the Perl 6 development team has ever been interested in addressing the concerns of those who ask.

Note that I'm not talking about giving a timeline, or a schedule, because of course Perl 6 is being created by volunteers, and there's no point in giving a schedule if the project can't realistically hit it. What I did say was "address the concerns." Maybe the project can't give the people want they want, but is there something they can give to help satisfy the hunger, and keep people interested?

For that matter, I've never felt that anyone on the Perl 6 development team even saw it as a reasonable question to ask. I've always seen the question answered with angry, defensive replies. Such a problem to have! People clamoring to use your project!

It's amazing to me that we have any goodwill left, any interest, that Perl 6 hasn't been written off as permanent vaporware. To the Perl 6 community, I ask, what can we as the rest of the community do to help keep people interested in Perl 6? Do you see that as a reasonable goal? And to everyone else, who is willing to help in this task, to help keep the fires of anticipation burning in the public?

Here's a collection of articles about the release of Perl 5.10.

First, since I'm still wearing the PR hat for the Perl Foundation, I mailed off notifications to many different big news sources. Both Dr. Dobbs Journal and Infoworld published articles about the release. Alas, the Infoworld article has some inaccuracies, but I'm glad to have Perl's name on such a widely-read site.

macnn, a big Mac news site, has good coverage of ActivePerl's release of both Perl 5.10 and ActiveTcl.

Kai 'Oswald' Seidler at apachefriends.org declares "we didn't update Perl because the new 5.10.0 seems to be a development version, and in XAMPP we only support 'stable' versions." Apparently XAMPP is an all-in-one bundle of web tools that you can slap onto your machine. If anyone has more info on Seidler's perceptions of 5.10 as being a development version, which it most certainly isn't, I'd be interested.

LinuxDevices.com has a nice write-up and summary. I wonder how many Linux devices Perl lives in.

HiveMinds Magazine mentions Perl 5.10, and then asks about Perl 6. "I just wish someone would write some insider info on Perl 6 before the new year," says author ahamilton. Hey, I'm working on it. (Also interesting that it's HiveMinds magazine, similar to Hiveminder, a web application run by Jesse Vincent, the Perl 6 project manager.)

The announcement at osnews.com spawned a 20+ message thread about Perl's continued relevance and where Perl 6 is. Thanks to Juerd for fighting some FUD.

That's the roundup of Perl 5.10 postings that I've seen so far. One downside of releasing Perl 5.10 a week before Christmas is that people are interested in other things than talking about programming. I'm hoping news outlets notice the articles I've sent after the holiday break. Please let me know about other Perl 5.10 postings you may find.

Graham Barr has put out some new features on search.cpan.org, both related to the META.yml file that comes with most distributions. The META.yml provides information in an easy-to-handle format on things like the author, version, license, what modules a distribution requires, and so on.

First, a few weeks ago, Graham added the ability to specify project home pages, source code repositories and alternate bug queues via the META.yml file. Now, if you go look at ack's page on search.cpan.org, you'll see that there are links for all of those. Note that the bug queue would normally point to rt.cpan.org, but since I'm using the Google Code issue tracker for ack, I need to point users to it.

Second, today Michael Schwern worked with Graham to make the META.yml more accessible by creating a JSON format, and to create META.yml files on-the-fly for distributions that don't ship with one. JSON is a very common format for structured information distribution, so JSON support at search.cpan.org will make it easy for applications that may not know YAML to work with CPAN meta-information.

Thanks to Graham for some important updates to the site that is effectively the face of CPAN, and for his work on what is often a thankless job.

Adam Kennedy has released his Strawberry Perl for Perl 5.10.0. Strawberry Perl is the Windows Perl distribution that's an alternative to ActiveState's distribution, and it includes tools for building CPAN modules natively, so you're not tied to ActiveState's PPM repository, which may not include the module you want to install, or may be behind a few versions.

chromatic is looking for stories of Perl over the last 20 years

As you may know, Perl is now 20 years old. In lieu of buying her a beer and waiting around for a year, I'm looking for interesting stories and memories to collect and post on a Perl-related website with a very nice and short domain name in the next couple of days. Please send them to chromatic@oreilly.com, along with a one sentence biography.

I don't have any that come to mind, but I do remember getting turned on to Awk and its associative arrays, now called hashes in Perl. To a C programmer in the late 80s, the ability to index an array BY A STRING blew my mind.

My baby, ack, broke under Perl 5.10.0, because of a fix in regex behavior that I had been using unknowingly. See, I had always used my regex objects like this:

my $re = qr/^blah blah/;
if ( $string =~ /$re/sm )...

when I should have been using it like this:

my $re = qr/^blah blah/sm;
if ( $string =~ /$re/ )...

The bug in 5.8.x is that the /$re/sm would incorrectly apply the /sm modifiers to $re. This made the code happen to work, but for the wrong reason. What was especially tricky about finding my bug was that in 5.10.0, the call to /$re/sm ignores the /sm, but doesn't tell you that.

After some back and forth on p5p, a patch was submitted that gave the warning about the ignored /sm flags, but alas, Perl 5.10 was already out. It wouldn't have been so bad if it hadn't been the day AFTER it was released.

So, lesson learned: Test your code against new release candidates of Perl, both for your code's sake, AND for Perl's sake.

And y'know, now that I think of it, this is probably a great policy for Perl::Critic just waiting to happen. I wonder how many other people are doing their regexes the wrong way, too.

Richard Dice writes to tell:

The Toronto Perl Mongers meet monthly for a combined technical and social meeting -- except in December, when the meeting is purely social. To celebrate the 20th birthday of Perl we scheduled our December 2007 meeting for the 18th. Richard Dice brought a special cake. (It was chocolate, not onion-flavoured as some people feared.) Rough 20 Mongers came out to the event. Fun - and cake! - was had by all. We hope Mongers world-wide enjoy some of the photos taken of the event.

And on the other side of North America, Andy Sweger writes about the Seattle Perl Mongers' celebration:

At the regular monthly SPUG meeting on December 18th, 2007, we had a little celebration for Perl's 20^th birthday which just happened to be on the same day. We had a lovely cake and we sang happy birthday to Perl for Larry. (Don't mind the bit about Perl 6, Larry. That guy just had too much cake.)

Today the Perl Foundation announces the release of Perl 5.10, the first major upgrade to the wildly popular dynamic programming language in over five years. This latest version builds on the successful 5.8.x series by adding powerful new language features and improving the Perl interpreter itself. The Perl development team, called the Perl Porters, has taken features and inspiration from the ambitious Perl 6 project, as well as from chiefly academic languages and blended them with Perl's pragmatic view to practicality and usefulness.

Significant new language features

The most exciting change is the new smart match operator. It implements a new kind of comparison, the specifics of which are contextual based on the inputs to the operator. For example, to find if scalar $needle is in array @haystack, simply use the new ~~ operator:

if ( $needle ~~ @haystack ) ...

The result is that all comparisons now just Do The Right Thing, a hallmark of Perl programming. Building on the smart-match operator, Perl finally gets a switch statement, and it goes far beyond the kind of traditional switch statement found in languages like C, C++ and Java.

Regular expressions are now far more powerful. Programmers can now use named captures in regular expressions, rather than counting parentheses for positional captures. Perl 5.10 also supports recursive patterns, making many useful constructs, especially in parsing, now possible. Even with these new features, the regular expression engine has been tweaked, tuned and sped up in many cases.

Other improvements include state variables that allow variables to persist between calls to subroutines; user defined pragmata that allow users to write modules to influence the way Perl behaves; a defined-or operator; field hashes for inside-out objects and better error messages.

Interpreter improvements

It's not just language changes. The Perl interpreter itself is faster with a smaller memory footprint, and has several UTF-8 and threading improvements. The Perl installation is now relocatable, a blessing for systems administrators and operating system packagers. The source code is more portable, and of course many small bugs have been fixed along the way. It all adds up to the best Perl yet.

For a list of all changes in Perl 5.10, see Perl 5.10's perldelta document included with the source distribution. For a gentler introduction of just the high points, the slides for Ricardo Signes' Perl 5.10 For People Who Aren't Totally Insane talk are well worth reading.

Don't think that the Perl Porters are resting on their laurels. As Rafael Garcia-Suarez, the release manager for Perl 5.10, said: "I would like to thank every one of the Perl Porters for their efforts. I hope we'll all be proud of what Perl is becoming, and ready to get back to the keyboard for 5.12."

Where to get Perl

Perl is a standard feature in almost every operating system today except Windows. Users who don't want to wait for their operating system vendor to release a package can dig into Perl 5.10 by downloading it from CPAN, the Comprehensive Perl Archive Network, at http://search.cpan.org/dist/perl/, or from the Perl home page at www.perl.org.

Windows users can also take advantage of the power of Perl by compiling a source distribution from CPAN, or downloading one of two easily installed binary distributions. Strawberry Perl is a community-built binary distribution for Windows, and ActiveState's distribution is free but commercially-maintained.

Editor's notes

For questions, contact Perl Foundation Public Relations at pr@perlfoundation.org.

Perl:
perl.org
Perl is a dynamic programming language created by Larry Wall and first released in 1987. Perl borrows features from a variety of other languages including C, shell scripting (sh), AWK, sed and Lisp. It is distributed with practically every version of Unix available and runs on a huge number of platforms, as diverse as Windows, Mac OS X, Solaris, z/OS, os400, QNX and Symbian.

Rafael Garcia-Suarez
email: rgarciasuarez@gmail.com
Rafael Garcia-Suarez is a French software engineer who lives in Paris, France, and who is currently employed by Booking.com. He has been a contributor to Perl for many years and has stewarded the birth of Perl 5.10 for the last few.

The Perl Foundation
perlfoundation.org
The Perl Foundation is dedicated to the advancement of the Perl programming language through open discussion, collaboration, design, and code. It is a non-profit, 501(c)(3) organization incorporated in Holland, Michigan, USA in 2000.

This is a copy of the official announcement about Perl 5.10.

ActiveState already has their Perl for Windows available for binary download. I'm sure Strawberry Perl won't be far behind.

From the PostgreSQL date functions reference:

The first century starts at 0001-01-01 00:00:00 AD, although they did not know it at the time. This definition applies to all Gregorian calendar countries. There is no century number 0, you go from -1 to 1. If you disagree with this, please write your complaint to: Pope, Cathedral Saint-Peter of Roma, Vatican.