Perl 6 isn't Perl, version 6 article

p6_isnt_pv6.pod6

=begin pod

=TITLE Perl 6 is not Perl, version 6

=AUTHOR Matthew Niemeyer (lue)
<L<rnddim@gmail.com|mailto:rnddim@gmail.com>>

=COPYRIGHT Copyright © 2011 Matthew Niemeyer. Licensed under the
Creative Commons Attribution-ShareAlike 3.0 Unported License.

Many times before I have given my opinion on how Perl 6, or P6 for
short, should work. I feel that it's high time I completely and
explicitly told my opinion on P6. How I perceive it, where I see
things now, and how I feel P6 should move forward. So now, just days
before I head back to $school, I write here my view of everything Perl
6, so that you may know who you're dealing with :)

=head1 Warnings

B<CAUTION!> This is purely an opinion piece. An I<opinion> piece. This
article in no way, shape, or form represents any official views,
actions, or plans of the people who matter and make decisions about
Perl and Perl 6. I stress this only because I predict this article
will generate a lot of false perceptions about Perl and Perl 6, and I
want to remind you this is an I<opinion>, not a statement of facts. I
do I<use> facts to get my point across, but my main message of B<Perl
6 is not Perl, version 6> is an opinion.

B<DOUBLE CAUTION!> I have never used Perl 5 (except for a little; see
How I Came to Perl 6), so I am completely unversed in the ways of
P5. There is definitely going to be some bias here. I have tried to
garner help from the folks at #perl6 who know Perl 5, but that can't
make up for experience I don't have, and admittedly, don't feel the
need to gain.N<You may feel asking those on #perl6 just generated more
bias, but I only ever asked about how things are done in Perl 5, not
people's opinions on P5.>

=head1 A Quick History of Perl 6

It's the year 2000. Perl is in a slump. Use of it has been
lacking. So, Larry Wall, in his State of the Onion address for the
year, calls for a new version of Perl, Perl 6. This time it's
different. He starts by collecting RFCs (Requests For Comments) from
the community about changes to the Perl language. Everything can be
suggested, from changing fundamentals of the language (e.g. the
particulars of sigils), all the way down to the logo. It was "The
Community's Perl".

The RFCs came in, they came in by the hundreds. When that was
finished, Larry took all the RFCs, made an observation of language
design ("Everybody wants the colon"), and created the Apocalypses, the
original documents specifying the new Perl 6. Damian Conway later
created the Exegeses, explanations of the Apocalypses.

What's notable about this version of Perl is that there is no such
thing as "one official implementation". Anything that follows the spec
completely, which means passing the test suite, can call itself "Perl
6".

Originally, Perl 6 was meant to be the next version of Perl, successor
to Perl 5 (hence the number 6). However, after a few years, the
community around Perl 5 exploded, went on an upward trend, and since
then has been a community busy improving P5, and not being so
concerned with that Perl 6 thing. In fact, the "split" between the
revived Perl 5 community and the new Perl 6 community is enough to
have affected how the relationship between 5 and 6 is viewed. When
Perl 5 was in a slump, P6 was the obvious successor. Once P5 got a
much stronger community around it, P6 ended up being more of an
offshoot rather than an improvement. It's from this current perception
that my perception and opinion arise.

=head1 How I Came to Perl 6

This is an interesting story, one where my initial perception of Perl
5 formed, just a tiny bit.

Sometime in 2009 (it's so long back I can't remember, and the
associated files to help me remember are gone), I had gotten
interested in Lunar Magic, a romhack tool for the game Super Mario
World. Namely, I was interested in creating a FOSS tool that did the
same thing. In order to do that, I reasoned, I need to learn about the
SNES and make an SNES emulator to test my knowledge [and to test those
romhacks I'd make :) ] . In order to do I<that>, it'd be good for me
to start with a simpler system first, the NES.

So I did. I set out with my favorite language at the time, Python 3
(which broke compatibility with Python 2), and started programming the
6502 interpreter. To cut this story shorter, there were two things I
was sorely missing: pointers (what's called binding in P6) and switch
(given/when in P6) statements. The NES uses "address mirroring", or
address in the memory map that point to a different part of
memory. (e.g. you might have an area of memory, 0x0800--0x0A00, that
actually points to 0x0000--0x0200 .) Now, this is a perfect chance to
use action-at-a-distance, but since Python didn't have that (w/o going
into using C things), I needed to create a function that compensates
for mirroring. In the previous example, any address call in the
0x0800--0x0A00 area would have 0x800 subtracted before being used
(non-mirrored addresses were unaffected).

That was painful enough, but when I needed to write the op-code
handler, the part that actually took the op-code and called the right
functions, I was bit by the lack of a switch statement. That was
it. I'm not writing 255 else-if's when a switch statement would cut
down the repetitive typing to almost nothing.

So I searched for a new language. One of my silly requirements was
that it had to be a "scripting" language, like Python or
Perl. Considering a disturbing amount of NES emulators (read: all of
them) use x86 assembler in their C/C++ code, when the source was
available for me to see, it erroneously gave me the idea that C/C++
was somehow at fault, and I wanted to write an emulator in a scripting
language to prove you can write a portable emulator, and one that
isn't C/C++. (Using a PPC machine, you'll find yourself cursing at
anybody who claims a program with hard-coded x86 assembler is "FOSS")

I settled on Perl. Problem was, which one? I could go with Perl 5,
which is here, complete, and with a bunch of modules (including,
importantly, GUI modules). Or I could go with Perl 6, which isn't
quite here yet, with no GUI modules of any kind, but is supposedly
more like other programming languages. I decided to try Perl 5, by
writing a sample program using Qt4. I gave up five minutes in at the
stupid C«->» method call syntax.

So, I decided to use Perl 6, because as much as I wanted to write an
NES emulator (remember, I was too bone-dead stupid to realize C/C++
wasn't the issue, but how people used it. I also somehow didn't grok
the concept of using more than one language at once.), I decided a
language that fixes a lot of old problems (like using a more common
C<.> for method calls, instead of C«->».) was better than suffering
through a language with some uncommon oddities, even though it meant
holding off on that NES emulator. Besides, I might even help out a
little with this incomplete thing called Perl 6.

Easily the best decision I ever made.

=head1 Big Changes from Perl 5 to Perl 6

Now, this last bit of boring fact-telling lists some of the
compatibility-breaking changes from Perl 5 to Perl 6, which I will
later use to argue that Perl 6 is not Perl, version 6. These changes
are both major as well as minor. They include:

=item Unicode Operators
=item Sigil Invariance
=item Operator Clarification
=item A Clear, Defined Specification
=item No One, Official Implementation

=head2 Unicode Operators

One very big change in Perl 6 is the use of Unicode operators, and
more care for Unicode in the first place. Really, the main Unicode
operators are the hyperops, C<«> and C<»>. There are ASCII equivalents
however, C«<<» and C«>>». The big deal about Unicode ops though is
that you can use any Unicode character as your own operator. Yes, you
have all 0x110000 Unicode characters at your disposal.

=head2 Sigil Invariance

Anybody who's used Perl 5 has likely encountered this (which means I
didn't). You have an array, and you want to access an element of the
array. In Perl 5, this is how you do it:

    my @array = 1,2,3;
    say $array[5];

In Perl 6 however, this need to change the sigil based on how you're
using the variable is I<gone>. So now, you can do this instead:

    my @array = 1,2,3;
    say @array[5];

Using C<say $array[5];> only works if you put an array (or similar
type) in the variable C<$array> (yes, that is possible).

=head2 Operator Clarification

One of my favorite things about Perl 6 is what I'm about to
detail. Say, for example, you want to XOR a number with 42. If you've
used Perl 5, you'd likely try this:

    my $number = 63;
    say $number ^ 42;

Well, wrong! Now, instead of one XOR operator C<^>, we now have three:
one for numbers (C<+^>), one for strings (C<~^>), and one for booleans
(C<?^>). So this is how the code would be in Perl 6:

    my $number = 63;
    say $number +^ 42;

I like this trend of operator clarification for a couple of reasons.

=item It's easier to see what you mean
=item It looks cooler C<:)>

=head2 A Clear, Well Defined Specification

Perl 5 has no specification. There are two competing standards: the
official C<perl> program, and "The Perl Book". Things specified in one
may not be in the other. This is usually resolved by declaring which
one is right, and then fixing the other. Not so in Perl 6.

Perl 6 started out as a bunch of RFCs (see "A Quick History" above),
and that became a specification. This would be what defined Perl 6. Is
it allowed in Perl 6? Check the spec.

=head2 No One, Official Implementation

One of the many dividing factors of Perl 6 is the simple fact that
there is no official implementation. Everyone is free to create their
own implementations, and as long as it passes the test suite (which
tests for spec compliance), it can be considered "Perl 6". In fact,
right now there are zero implementations of "Perl 6" by that rule. For
most people though, there are a couple of implementations (rakudo and
niecza mainly) that are good enough right now that you can use them,
and hopefully get around the NYI (Not Yet Implemented) stuff.

=head1 Why I Feel Perl 6 is not Perl, version 6

In my personal opinion, Perl 6 is another branch of the Perl family,
not the eventual successor to Perl 5. I feel this way because of the
many differences between Perl and Perl 6 (the above section is the tip
of the iceberg), and also because the Perl 5 community now is chugging
along on its own merry path, working to improve P5.

To put this in code, when I see "Perl 6", I I<don't> see:

    module Perl:ver<6>;

Rather, when I see "Perl 6", I think more like:

    module Perl6;

I see 6 as an indicator of another branch of the family, not as a
version number. I'm honestly finding it difficult to explain the
reason for my opinion. I suppose it's because I came to the P6 world
with it being wildly different and compatibility breaking with Perl
5. Also, there's a general air of "not the successor, the spunky
little sister!" in Perl 6. I can't envision Perl 5 ever being
"deprecated", it's not going to happen. The best way to explain this
would be to tell you about what I think is a similar example in the
programming world: C and C++.

=head2 The SUPERBRIEF Story of C and C++

In the late 60's and early 70's, C was developed at the AT&T Bell
Labs. It became very well used, and known for being fast and
portable. Then in the 80's, when Bjarne Stroustrup needed to analyze
the UNIX kernel. So, he created a new version of C with Classes, at
the time called I<C with Classes>, later changed to I<C++>. C++ became
widely used as well.

Nowadays, it's common to see C and C++ code mixed together in large
projects. To say C++ is somehow the successor to C is wrong. C++ is
merely another branch in the family of C style code. Sure, C++ was
created after C, and features several improvements, but sometimes you
either have legacy code, a programmer who prefers C, or just no good
reason to stick your neck out for C++. They both coexist peacefully.

=head2 How C applies to Perl

To analogize, Perl 5 is C and Perl 6 is C++. Perl 5 doesn't have
classes (well, not like what you'd expect, unless you use Moose) while
Perl 6 does, which is an entirely chance parallel between C and C++. I
believe 10, 20, heck, even 30 years from now, we'll see Perl 5 and
Perl 6 side by side in one project, coexisting peacefully. Perl 6 will
never replace Perl 5, and I'd be sad if it did.

=head1 Conclusion

In short, this is my opinion. Perl 6 is not Perl, version 6. In my
eyes, Perl 5 is that old language that may not have as many cool
features as Perl 6, but gosh darn it it get the job done. Perl 6 is
that snazzy new offshoot with a bunch of new features and a depth
that'll amaze anyone and everyone. If you don't want to use the snazzy
new features in Perl 6, you can code like you did in Perl 5. Most of
the time.

The camel (or onion, if you prefer), has been traversing the world for
around 20 years, delivering the best results a camel (or onion)
can. The camel/onion has been worshiped for decades, and it will for
many more decades to come. Camelia the butterfly, in my eyes, is just
arrived, ready for action, "that hoopy frood who knows where her towel
is".N<I wonder, what's the feminine form of "frood"?>

Camelia the butterfly will always be friends with the camel, but I
don't see her ever becoming that camel.

=end pod