Sign In/My Account | View Cart  
advertisement


Listen Print

Perl 6 : Not Just For Damians

by Piers Cawley
October 23, 2001

London.pm technical meetings are always inspiring events with top notch speakers. At our most recent gathering Richard Clamp and Mark Fowler gave us "Wax::On, Wax::Off -- how to become a Perl sensei"; Paul Mison showed us how to make an infobot read the BBC news; Richard Clamp and Michael Stevens explained "Pod::Coverage", their contribution to Kwalitee assurance; and, for the first time ever, Leon Brocard didn't talk about Graphing Perl.

However, the highlight of the evening was Simon Cozens's first public demonstration of Parrot, the new virtual computer that will one day run Perl 6.

After he'd finished the talk we expected, he pulled a crumpled piece of paper from a secret pocket. This, he whispered, was an early draft of Apocalypse 3 which he'd smuggled out at great personal risk from under the very noses of the Design Team. An expectant hush fell as he proceeded to reveal the highlights.

Related Reading

Programming Perl, 3rd Edition

Programming Perl, 3rd Edition
By Larry Wall, Tom Christiansen, Jon Orwant

The reception his heroic effort received was... low key. Everyone was pleased to get an early peek at what Larry was thinking, but there were widespread mutterings about "all this needless complexity" and "mere syntactic sugar". Almost everyone grumbled about the use of '.' for dereferencing. Almost everyone groused about using '_' for concatenation. And the reassurance that "It's only syntax" didn't seem to appease the doubters.

And then we all went for beer and/or Chinese food.

Fast forward to last weekend. The Apocalypse was up on the website and Damian had just published his Exegesis when Simon Wistow (London.pm's official scapegoat) warned the mailing list that he had:

... an impending sense of doom about Perl 6. The latest Apocalypse/Exegesis fill me with fear rather than wonder. I've got a horrible feeling that Perl 6 is trying to do too much at once.

This provoked a firestorm of agreement. The general consensus was that the latest Apocalypse was:

reinventing wheels which we already have in abundance. And those new wheels have syntax that is only going to confuse those who are already experienced perl5 users

It seems that what we have here is a failure to communicate.

Yes, Damian's efforts have been superb in providing examples of code based on the Apocalypses, and I don't think anyone denies the sterling work that Dan and his team are doing with Parrot. But people do seem to be worried about Perl 6 being a rewrite for the Damians of this world, not for the ordinary Joe.

Well, I'm here to tell you that this ordinary Piers doesn't have a problem with Perl 6. In fact I'm excited and inspired by most of the work that's been done so far, and I hope to convince you too.

"Perl 6 doesn't look like Perl"

Well, up to a point. The thing that you have to remember when reading the sample code that Damian provides in his Exegeses is that he is deliberately exercising all the new features in a condensed example. The most recent code sample is initially scary because there's so much stuff in Apocalypse 3. Admittedly, $self.method() looks weird now, but then, $self->method() looked weird when Perl 5 was introduced. And, on rereading Damian's example with an eye to what hasn't changed, the whole thing still looks like Perl.

"Perl 6 just gives us syntax for stuff we can already do"

That's a mighty big 'just' there, partner. Consider the currying syntax. Before this came along, currying was possible, but required an unreasonable amount of manual work to implement. Just consider the following, 'simple' example:

In perl 6 we have:

    $^_ + $^_

In perl 5, if you didn't worry about currying you'd write:

    sub { $_[0] + $_[1] }

If you do worry about currying, you'll have to write:

    do { 
        my $self;
        $self = sub {
            my ($arg1, $arg2) = @_;
            return $arg1 + $arg2             if @_==2;
            return sub { $self->($arg1,@_) } if @_==1;
            return $self;
        }
    }

And I don't want to think about the hoops I'd have to jump through in the case of a curried function with three arguments, or if I wanted named arguments. Now, you could very well argue that you don't use anonymous functions much anyway, so you're certainly not going to be doing tricks with currying, and you may be right. But then, of course, if you don't want to use them you don't have to.

However, I'm betting that before long it will be just another spanner in your toolbox along with all the other gadgets and goodies that Larry's shown us so far. Tools that you use without a second thought.

If you've ever done any academic computer science, you might have come across Functional Programming, in which case an awful lot of what's new in Perl 6 so far will be looking surprisingly familiar. The thing is, until now, Functional Programming has been seen as only of concern to academics and the kind of weirdoes who are daft enough to write Emacs extensions and, dammit, Perl doesn't need it. There is even an RFC to this effect.

I remember saying almost exactly the same thing about another language feature of 'purely academic interest' that got introduced with perl 5; the closure.

I don't know about you, but closures are old friends now; another tool that gets pulled out and used where appropriate, with hardly a second thought.

"Perl 6 doesn't give us anything that Perl 5 doesn't."

Yeah, and Perl 5 doesn't give us anything that a Universal Turing Machine, Intercal, or Python don't. We use it because it 'fits our brains'. The Perl 6 redesign is all about improving that fit.

Pages: 1, 2, 3, 4

Next Pagearrow