LAMP technologies traditionally include Linux, Apache, MySQL, and, by happy coincidence, one of three “P” languages: PHP, Python or Perl. Of course, this is changing a bit. Many folks have long preferred PostgreSQL over MySQL because prior to MySQL 4.1 (or 5, depending upon your point of view), MySQL was pretty much a sophisticated toy, but LAPP probably doesn’t sound as cool. Others prefer Ruby to Python, PHP and Perl, but prior to Rails, many folks assumed that switching to Ruby wouldn’t be a good career move.

But the question that some folks wonder about is whether or not Perl6 will take its place along the “P” languages. The loudest objection I hear today are that Perl6 is taking too long and that it’s too complicated. Well, as anyone who’s programmed C++ can tell you, complexity is not a guaranteed barrier to language adoption. However, while Perl6 is very feature-rich, the common usage of the language is easier to learn than Perl5. As for “taking too long”, were I a betting man, I’d be willing to bet that we’ll have an alpha in 2007, and probably in the first half rather than the second. Given that I’ve been paying attention to Perl6’s development and I know some of the designers and implementors, I feel very comfortable with this prediction. But if Perl6 really is everything the designers hope it will be, why should we bother? Admittedly, I love Perl and its quirks, but I readily concede that those quirks are something of a liability. Not so with Perl6.

What changes will most notice? The dot operator is the biggest change that many will notice:

my $customer = Customer.new;   # instead of Customer->new
say $customer.name;   # instead of Customer->name

Many Perl programmers are unhappy with this change, but let’s face it: the dot operator is the common choice here and that’s because it’s a good choice. Proper Huffman encoding dictates that common things should be shorter and in this case, it’s readily understood by most programmers.

Another big change fixes one of the greatest sources of bugs in Perl5 programs: proper argument lists. Instead of passing everything in the @_ array (”at underscore”? What’s that?), you can do this:

sub foo ($bar, $baz) { ... }

That’s going to save a lot of headaches. Of course, there’s a named argument version:

sub foo ( bar => $bar, baz => $baz ) { ... }

Now many programmers looking at those things might think those amount to little more than bug fixes, but there’s more! Java and C++ programmers sometimes shake their heads in dismay at “dynamically” typed languages. Well, fine. If you want strong typing, you can have it. We’ll even give you multisub and multimethod dispatch. And guess what? You’re also get macros! Real, honest to goodness macros like LISP programmers enjoy, not the broken string substitution thingies which C programmers use. Oh, and you’ll get try/catch blocks, too.

Of course, since we’ll be using the dot operator in OO programming, this begs the question “what’s an object”? Ruby and Smalltalk managed to get this right when they decided that everything should be an object (edit: and that’s how it is in Perl6). Even constants are objects. Something as simply as 7.say will print “7″. Raw lists are even objects:

say ( 1, 2, 4 ).sum; # prints "7"
say <1 2 4>.sum; # same thing
( 1, 2, 4 ).sum.say; # this works too

Anyone who’s been programming Java before autoboxing was introduced knows the frustration of working with primitives sprinkled in an OO language (regrettably, the Perl5 autoboxing patch worked wonderfully, but was rejected). Anyone who’s worked with Ruby and Smalltalk long enough knows the joy of the “everything is an object” approach.

Junctions are one feature of Perl6 which I’m sure is going to be snatched up by other languages. Want to know if there are any intersections between two lists?

if any(@first_list) == any(@second_list) { ... }

Or just check to see what a person’s title is:

if $title ne any <manager programmer accountant> { ... }

Traits are another big feature which are slowly gaining traction, but Perl6 will be the first mainstream language to have them included in the core. The simplest way to think of them is like Ruby’s mixins, but method conflicts are usually compile-time failures and have to be explicitly resolved. No more ordering problems!

There’s a heck of a lot more, but those are the major features I’m looking forward to right now. Perl6, which after years of development is probably going to be out within a year or so, not only fixes many Perl5 issues, adds many features that other languages offer and has brand-new features that will just make programmer’s lives more easy. On top of that, from what I’ve seen with the language, it’s even easier to learn than Perl5! It’s definitely going to be a powerful addition to the LAMP toolkit.

Disclaimer: despite being on the Perl Foundation Steering Committee, my Perl6 predictions are strictly my own and not an official statement of TPF or anyone else.