What Is Perl 6
Perl 6 will likely also use its test suite as its primary specification, but as Larry Wall puts it, “We’re just trying to
start with the right tests this time.”
Even if the Perl 5 codebase did follow a specification, its design is inelegant in many places. It’s also very difficult to
expand. Many good ideas that would make code easier to write and maintain are too impractical to support. It’s a good
prototype, but it’s not code that you would want to keep if you had the option to do something different.
From the language level, there are a few inconsistencies, as well. For example, why should sigils change depending on how you
access internal data? (The canonical answer is “To specify context of the access,” but there are other ways to mark the
same.) When is a block a block, and when is it a hash reference? Why does SUPER method redispatch not respect the currently
dispatched class of the invocant, but only the compiled class? How can you tell the indirect object notation’s method name
barewords from bareword class or function names?
It can be difficult to decide whether the problem with a certain feature is in the design or the implementation. Consider the
desire to replace a built-in data structure with a user-defined object. Perl 5 requires you to use tie and overload to do so.
To make this work, the internals check special flags on every data structure in every opcode to see if the current item has
any magical behavior. This is ugly, slow, inflexible, and difficult to understand.
The Perl 6 solution is to allow multi-method dispatch, which not only removes conceptual complexity (at least, MMD is easier
to explain than tie) but also provides the possibility of a cleaner implementation.
Perl’s flexibility sometimes makes life difficult. In particular, there being multiple more-or-less equivalent ways to create
objects gives people plenty of opportunities to do clever things they need to do, but it also means that people tend to
choose the easiest (or sometimes cleverest) way to do something, not necessarily the best way to do something. It’s not
Perlish to allow only one way to perform a task, but there’s no reason not to provide one really good and easy way to do
something while providing the proper hooks and safety outlets to customize the solution cleanly.
Also, there are plenty of language optimizations that turned out to be wrong in the long term. Many of them were
conventions–from pre-existing awk, shell, Unix, and regular expression cultures–that gave early Perl a familiarity and
aided its initial growth. Yet now that Perl stands on its own, they can seem counter-productive.
Redesigning Perl means asking a lot of questions. Why is the method call operator two characters (one shifted), not a single
dot? Why are strictures disabled by default in programs, not one-liners? Why does dereferencing a reference take so many
characters? (Perl 5 overloaded curly braces in six different ways. If you can list four, you’re doing well.) Why is
evaluating a non-scalar container in scalar context so much less useful than it could be?
Once you accept that backwards compatibility is standing in the way of progress and resolve to change things for the better,
you have a lot of opportunities to fix design and implementation decisions that turn out to have been bad–or at least, not
completely correct.
Advantages of Perl 6
In exchange for breaking backwards compatibility, at least at the language level, Perl 6 offers plenty of high-powered
language concepts that Perl 5 didn’t support, including:
* Multimethods
* Coroutines
* Continuations
* Useful threading
* Junctions
* Roles
* Hyperoperators
* Macros
* An overridable and reusable grammar
* Garbage collection
* Improved foreign function interface
* Module aliasing and versioning
* Improved introspection
* Extensible and overridable primitives