
Differences Between Perl 5 and Perl 6 - vezzy-fnord
http://design.perl6.org/Differences.html
======
acqq
To reuse the recent slogan, the only thing that changed is everything.

It's a new language with its own internal logic.

I used (and still use) Perl 5 because it made some specific things easy to
make (various processing of data). I still don't know for which kind of tasks
Perl 6 is the best choice. But maybe the language is simply too young for it
to be obvious?

~~~
Diederich
Perl6 is really a strict supserset of Perl5 in this way.

Perl6 is _at least_ as good as Perl5 for everything Perl5 is good at.

But Perl6 is way, way more than that.

~~~
btilly
_Perl6 is at least as good as Perl5 for everything Perl5 is good at._

No. It is not. Don't believe me? Here is a short list of classic selling
points for Perl 5 that Perl 6 clearly loses on.

1\. Performance. Back in the 1990s, Perl hit a sweet spot of being quick for
development while still being fast enough for a wide variety of tasks. It
still performs reasonably well versus other scripting language. Every time I
looked at Perl 6 it failed to be fast enough for anything interesting to me.

2\. Library support. Any argument for Perl quickly lists CPAN. It is a large
part of why people adopted it in the first place. Perl 6 loses to every major
language, including Perl 5, on this. If you need to do anything from connect
to a database to sending email, Perl 6 loses.

3\. Backwards compatibility. Perl has a history of being careful with
backwards compatibility, starting with Perl 1's unit test suite back in the
mid-80s. (It would be decades until other language communities caught up.)
Most organizations currently using Perl 5 use it because they already have
existing code in Perl 5. Their primary motivation for staying on Perl is that
they don't want to rewrite their code. Perl 6 requires a rewrite of their
code.

~~~
kbenson
1\. Can't argue with this.

2\. With Inline::Perl5[1] this should be a non-issue. The short code snippet
in the README at the github repo referenced should give you the idea.

3\. Having not been released yet, Perl 6 has zero history on backwards
compatibility, so there's no way to assess whether it's relatively better or
worse than Perl 5.

That said, I don't necessarily support the original statement that Perl 6 is a
superset and at least as good as Perl 5 at everything. I just wanted to
address your specific statement regarding library support.

1: [https://github.com/niner/Inline-Perl5](https://github.com/niner/Inline-
Perl5)

~~~
cwyers
> Having not been released yet, Perl 6 has zero history on backwards
> compatibility, so there's no way to assess whether it's relatively better or
> worse than Perl 5.

Well, uh, it's not backwards-compatible with Perl 5. Yes, yes, I know, "It's a
different language." So why is it called "Perl 6?" The name is very much
designed to tell us "this is the one after Perl 5." Insisting that everyone
evaluate it as a greenfield language is an incredible insistence upon
cognitive dissonance.

~~~
mst
Meh. Read it as "This is the 6th perl Larry's designed".

It is the one after 5, in that sense.

The naming is not perfect but it is, at this point, a little late to do
anything about that.

~~~
cwyers
But the other five aren't different languages, they're different versions of
the same language. (And if it weren't for the Perl 6 debacle I think what we
currently call Perl 5.22 would be something like Perl 6 or even Perl 8 or 9.)

------
nandhp
Do the changes to the regular expression syntax seem woefully under-publicized
here?

    
    
        Was:    $str =~ m/^\d{2,5}\s/i
        Now:    $str ~~ m:P5:i/^\d{2,5}\s/ # :P5 indicates Perl5-compatibile regex syntax
    
        Was:    $str =~ s/(a)/$1/e;
        Now:    $str ~~ s:P5/(a)/{$0}/;    # $1 is now $0
    

I actually find the change from $1 to $0 particularly disturbing, since that
is well standardized and group 0 normally refers to the whole matched pattern
(though Perl had to give it a different name and for some reason has always
discouraged its use).

They also provide no information here on the non-"Perl5-compatible" regexes,
but they do talk about it a bit in Specification 5:
[http://design.perl6.org/S05.html](http://design.perl6.org/S05.html) There are
some really interesting changes there, and we'll see what comes of this --
PCRE has become a de-facto standard, so I'm curious to see what happens as
Perl moves away from "PCRE-compatible" syntax.

~~~
acqq
It seems "disturbing" is the good word here, as the kind of changes in the
semantics or notation between Perl 5 and Perl 6 almost guarantees that most
potential users would have to decide if they are going to reject using one or
another: The need to "read differently" on the distant look similar code
demands too much from the people who'd just like to "get the job done."

What's that $1? Well it's the first match if it's Perl 5 but it's a second
match if it's Perl 6. But don't worry, the other things in expressions also
have sometimes other meanings.

~~~
singingfish
don't use $1, use named captures or list assignment. qr/\$\d+/ is a oneliner
thing or a code smell.

~~~
nikatwork
It's not a smell if you are doing an asston of text munging. Rather than write
one ginormo regex I prefer a sequence of short actions. It's easier to debug
and reason with.

~~~
bmn_
Use named captures or list assignment. $1 $2 etc are already a code smell in
Perl 5. Action-at-a-distance is the enemy.

~~~
nikatwork
That's needlessly verbose if I am descoping $1 within a line or two. I agree
one must be careful.

------
Someone

      Was:    my $len = length($string);
      Now:    my $len = $string.chars;
    

My intuitive interpretation of that syntax would be "given a string, return a
sequence containing its characters, in order".

Or is that overlading on return type, and do you get the behavior I would find
intuitive if one assigns to an array?

Even if that is true, I find that ugly. I would prefer more explicit code, for
example

    
    
       my $len = $string.chars.#;
    

Similarly:

    
    
      Was:    $#array+1 or scalar(@array)
      Now:    @array.elems
    

(All IMHO)

~~~
rihegher
this is a typo error actually: Now: my $len = $string.length;

[http://doc.perl6.org/type/Str#method_length](http://doc.perl6.org/type/Str#method_length)

EDIT: I don't see any contact section on their page to let them know

~~~
nemo
length is gone. See:

[http://design.perl6.org/S29.html#Obsolete_Functions](http://design.perl6.org/S29.html#Obsolete_Functions)

"length()

This word is banned in Perl 6. You must specify units. In practice, this
probably means you want Str.chars(), although it could be Str.bytes(), or even
something else. See S32-setting-library/String for details."

~~~
rcthompson
That's an interesting design decision, and I suppose it solves the Python
problem of "I want to operate on any iterable, except for strings which are
technically iterables but I want to treat them as atomic elements."

(Incidentally, does Python 3 have a solution to this problem?)

------
VLM
Note that its more or less "how to write perl 5 in perl 6"

Sorta like the old F2C, Fortran to C, converter. You don't get idiomatic C,
but you do get a fortran program that compiles and runs as a C program, more
or less.

Some parts of perl6 are annoyingly urbit-y, come on, you guys just had to
rename ARGV and rename scalar and the for-foreach transition is ridiculous. I
suspect at least a decade of people pointing at items and verbally calling
them scalars and so on. Urbit is cool but is most famous for feeling the need
to rename everything.

Here's a slide stack for going from MOOSE (more or less the most popular
"real" perl5 OO implementation, technically an "add on" for perl5 although
many people will only program perl5 with MOOSE) to perl6 OO. At least toward
the middle there are adjacent slides of "this is how you do it in MOOSE" "this
is how you do it in perl6"

[http://www.slideshare.net/lichtkind/p6-oo-vs-moose-
moo](http://www.slideshare.net/lichtkind/p6-oo-vs-moose-moo)

I'd like to read a book titled something like "Modern Perl; For Perl 6.0"

The transition will be such fun; I have some business logic libraries where
I'll have to replicate behavior and test suites simultaneously for awhile in
MOOSE/5.0 and in 6.0.

(response to unfortunately hellbanned berntb question about replication, the
codebase is huge and interrelated and can't be forklift upgraded all at once;
its already non-trivial to do stuff in both perl and scala, and now it would
be perl5 perl6 and scala all more or less interoperating)

~~~
berntb
It might be too much stress or too little coffee, but I don't understand the
last part. Why would you need to replicate behaviour and tests?

You mean it will take time before you trust the "use Perl 5 code in Perl 6"
bridge that is worked on, so it isn't enough to run the Perl 5 tests and then
use that code in Perl 6?

(Or you think there will be bad interactions with Moose and Perl 6 OO?)

Edit: Huh, I was shortly un-hellbanned and am Hellbanned again since the
previous comment didn't live up to some interesting-level standard? :-)

~~~
amyjess
> Edit: Huh, I was shortly un-hellbanned and am Hellbanned again since the
> previous comment didn't live up to some interesting-level standard? :-)

Maybe your comment got rescued by someone using the new vouch feature?

------
makecheck
In multiple organizations I have primarily seen Perl applied to very large,
complex and established code bases that also make significant use of things
like reading/writing Perl data structures.

Simply put, there will _not_ be any grand push to re-sigil every stored data
structure and make massive, sweeping changes to nearly every line to end up
with the same program that looks, if anything, arguably less intuitive.

This shows a profound unawareness of how Perl 5 was actually used in practice.

~~~
perlgeek
Perl 6 developer here.

Perl 6 is not an automatic upgrade path from Perl 5. We don't expect anybody
to rewrite huge amounts of Perl 5 code in Perl 6. Perl 5 is going to be
maintained separately.

We do provide tools to augment Perl 5 code with Perl 6 code, and the other way
around. There's Inline::Perl5 for Perl 6, and Inline::Perl6 for Perl 5.

~~~
a3n
Is there a Perl 5 EOL being discussed?

Or, if Perl 5 and Perl 6 really are two completely separate languages
separated by a similar syntax, then what comes after Perl 5 in the Perl 5
language? Will it forever be 5.N, 5.N+1, ...? (And, I guess, will there
forever be 6.N, 6.N+1, ...?)

~~~
kamaal
Its ridiculous to imagine any EOL for Perl 5, given how large that ecosystem
is. Co existence is the way forward.

I think a good deal of Perl 6 features will seep into Perl 5 over time, while
maintaining backwards compatibility.

~~~
systems
i think if Perl6 becomes popular enough, most perl5 devs and shops will just
move to perl6

while perl6 is truely a new languages not an upgrade to perl5

perl5 devs for a while have been under pressure to make perl5 more popular,
using a popular language adds a padding of security, a cushion, perl5 devs are
surely hungry for this

and if you like perl5 you will love perl6 as they seem to share the same
values both languages that are syntax heavy, and languages that work the way
you do, instead of forcing you to think a certain way .. like say functional
languages

Perl6 is probably the complete opposite of say .. Haskell, but I believe in a
good way ... it will be popular, i think it will be an agile language .. and
many devs will love the flexibility

------
alricb
So what you're telling me is that perl no longer automatically applies
_flatten_ to nested lists? Yay!

~~~
SapphireSun
That was never a problem you just used:

$x = [ [1], [2], [3] ];

Instead of:

@x = ( (1,), (2,), (3,) );

I always found it quite convenient to be honest.

------
Diederich
I really like how the various try related constructs, for instance, CATCH, are
lexically scoped inside the overall try block. This is a very logical and
useful simplification I think.

------
perlgeek
See also
[http://doc.perl6.org/language/5to6](http://doc.perl6.org/language/5to6)
(which is well maintained).

------
manuu
Everything is a reference! Nice!

~~~
whyever
Not really if you car about efficiency.

~~~
baudehlo
The opposite is true. In Perl 5 passing a hash to a function requires
mallocing a new shallow copy of that hash. In Perl 6 this would be the
equivalent of passing a reference to the hash, which would only require
mallocing a scalar.

------
rurban
Please see also cperl, a perl11 (=5+6), which is an extended perl5 variant
with many perl6 features and syntax extensions. Only the perl6 syntax which
violates perl5 cannot be supported.

[http://perl11.org/cperl/STATUS.html](http://perl11.org/cperl/STATUS.html)

------
Paul_S
One thing that bugs is that perl5 code could potentially run with perl6. Is
there any mitigation for that?

~~~
jayvanguard
It was explicitly not a design goal to be backwards compatible.

"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..."

[http://www.perl.com/pub/2006/01/12/what_is_perl_6.html](http://www.perl.com/pub/2006/01/12/what_is_perl_6.html)

~~~
maw
That's not what I read the GP post as saying though. Rather, that the perl 6
interpreter could run code written as perl 5 (and never ported). With their
different semantics, the results would be unpredictable and often undesired.

~~~
kylebgorman
From this document, the chance that a perl 5 script is syntactically valid
(but semantically different) perl 6 is awfully low. Now if the errors that
arose said that you might be trying to execute perl 5 as perl 6, that'd be
cool ;)

~~~
donaldihunter
There are numerous error messages that highlight perl 5 isms

e.g.

    
    
      > say $#array;
      ===SORRY!=== Error while compiling <unknown file>
      Unsupported use of $#variable; in Perl 6 please use @variable.end
    

and

    
    
      package foo;
      ===SORRY!=== Error while compiling <unknown file>
      This appears to be Perl 5 code. If you intended it to be Perl 6 code, please use a Perl 6 style declaration like "unit package Foo;" or "unit module Foo;", or use the block form instead of the semicolon form.

~~~
amyjess
Yes, these suggestions are among my favorite things about Rakudo.

There are a lot more, too. Another example:

    
    
        > 1 == 1 ? "sane" : "insane"
        ===SORRY!=== Error while compiling <unknown file>
        Unsupported use of ? and : for the ternary conditional operator; in Perl 6 please use ?? and !!
        at <unknown file>:1
    

Or:

    
    
        > loop(my $i = 0; $i < 10; $i++) { say $i }
        ===SORRY!===
        Word 'loop' interpreted as 'loop()' function call; please use whitespace around the parens
        at <unknown file>:1
    

Easily the nicest error reporting I've seen in a compiler.

------
Redoubts
>any two valid identifiers may be joined with a single ' to form a longer
identifier

Oh no.

~~~
kstrauser
It gets worse. "Hey, let's double down on weak typing!":
[http://examples.perl6.org/categories/cookbook/01strings/01-0...](http://examples.perl6.org/categories/cookbook/01strings/01-00introduction.html#Strings_as_numbers)

    
    
      print  +""     ; # a num-ified empty string evaluates as 0
      print  "1" + 1 ; # 2
    

The opportunity for insidious bugs (for the benefit of not having to type
'int("1") + 1' those times when you really need to do that) is a terrible
tradeoff, in my opinion.

In before "but Python...!". Python is strongly typed.

    
    
      >>> "1" + 1
      Traceback (most recent call last):
        File "<stdin>", line 1, in <module>
      TypeError: cannot concatenate 'str' and 'int' objects
      >>> 1 + "1"
      Traceback (most recent call last):
        File "<stdin>", line 1, in <module>
      TypeError: unsupported operand type(s) for +: 'int' and 'str'

~~~
kbenson
This is not weak typing. Perl (both 5 and 6) use operators to define type
context. It's entirely unambiguous whether you want to add something or
concatenate strings because _they are different operators_.

    
    
      "1" + "1" # 2
      "1" . "1" # 11 (~ to concatenate in Perl 6)
      1 + 1 # 2
      1 . 1 # 11
    

When you perform a string operation on a numeric type, it stringifies the
number, when you do a numeric operation on a string, it numerifies the string
(and warns if it can't be cleanly done).

This isn't a typing problem, this is a commenting on language without actually
knowing how it works problem. But that's nothing new, people have been doing
that to Perl for a long time now.

~~~
kstrauser
Ah, sorry. Despite having used Perl for years, I'd forgotten how much emphasis
it puts on concepts that invoke a high cognitive load.

~~~
kbenson
On the contrary, I think there is a higher cognitive load in having to reason
about the behavior that results from using the + operator between two types
when their types may differ. e.g., the Wat talk[1].

To be clear, there is a cognitive load to both. One is based on keeping
correct type of the variables you are using with the + operator, the other is
knowing that numeric addition and string concatenation are not the same thing,
and have different operators. Since string concatenation and numeric addition
_really aren 't the same thing_, and don't share the same properties, I prefer
the different operators.

1:
[https://www.destroyallsoftware.com/talks/wat](https://www.destroyallsoftware.com/talks/wat)

~~~
btilly
_On the contrary, I think there is a higher cognitive load in having to reason
about the behavior that results from using the + operator between two types
when their types may differ. e.g., the Wat talk[1]._

The simple fact that you run out of operators limits how many types can
usefully exist. In Python you use + quite reasonably for integers, floats,
strings, and arrays. By contrast raw Perl has equivalents only for numbers and
strings, and is unable to distinguish between integers and floats. That is why
Perl doesn't do exact arithmetic with large integers.

But, you say, Perl allows you to use bigint? Well, yes. And that is internally
implemented with the magic of overload. Using that you can have any number of
types which overload + to do what they want, and you have all of the same
issues as arose in the Wat talk.

It took a long time for me to be convinced, but I am now convinced that typed
variables and untyped operators (like Ruby and Python do) is strictly better
in practice than untyped variables and typed operators (like Perl does by
default). And as for the complexity, it is just something you have to live
with.

Want evidence? [https://mitpress.mit.edu/sicp/full-
text/sicp/book/node48.htm...](https://mitpress.mit.edu/sicp/full-
text/sicp/book/node48.html) discussed this exact problem some 30 years ago. I
do not believe that the intrinsic problem is being solved any better today
than then.

------
waynecochran
For someone using Perl 5 as a replacement for bash scripting, is it worth
making the jump to Perl 6?

P.S. Why not name this language something new? -- Nicklaus Wirth didn't name
Modula-2 Pascal 2.

~~~
MaysonL
_Nicklaus Wirth didn 't name Modula-2 Pascal 2_

And that was a big marketing mistake. Do you think C++ would have been
anywhere near as successful if it had been called Z?

~~~
waynecochran
So its a marketing decision? That's depressing.

------
tedchs
And Perl6 has now invented its own word, "twigil"? Sigil was already a bad
enough word. I used Per5 for a ton of production code years ago, and I've met
Larry Wall and he is a brilliant and friendly person, but I am sad to say
there is absolutely zero chance of Perl6 being adopted for a serious
production software project, probably ever. It doesn't bring new capabilities,
it's just different, and in a mostly-worse way.

