Differences Between Perl 5 and Perl 6 | Hacker News Reader

Differences Between Perl 5 and Perl 6

design.perl6.org

180 pointsvezzy-fnord122 comments

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?

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.

I'll probably be trouted by a Perl monk for saying it, but sometimes less is more.

Ha, what happens when one is 'trouted'??

It's been a number of years, and I can't check right now, but I believe that the amount of code in Perl6 is actually less than in Perl5. The amazing power that is Perl6 naturally falls out of a whole lot of experience and fantastic design decisions. Not to mention several great implementations.

I'm a big fan of 'less is more' as well. In this case, you're literally correct: Perl6 delivers a LOT MORE than Perl5 even though there's 'less to it'!

I expect it's based on the /slap emote in IRC.

Wikipedia [0] has a page on it, from which I swipe the follwing:

`When someone does something inadvisable that they had the experience and intelligence to avoid, you may likely see the suggestion that they be "trouted"`

Trout slapping originated in 1995 with internet relay chat (IRC). While in an IRC chat room, the IRC client mIRC would allow users to enter the command:

  /slap Sam
  - Steve slaps Sam around a bit with a large trout

0: https://en.wikipedia.org/wiki/Wikipedia:Whacking_with_a_wet_...

Wow, that's a blast from the past. Did it really originate in mIRC? Somehow I feel like it predated that, but maybe just because I didn't run Windows.

It sounded Monty Python-ish to me, and it looks plausible[1].

1: https://www.youtube.com/watch?v=WsfiD78Cy0s

I first encountered it in the mid-to-late '90s, and it was definitely considered an IRCism back then (in that IRC was the only place you saw trouting), but I had no idea it originated as an mIRC builtin.

Depends on the problem on hand. You can't really replace lifts with thousands of ladders, when you are building a sky scraper.

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

How? And can you cite any sources that I can read? Thanks.

Well, I made a pretty grand statement there, which means it will be demonstrably wrong in at least some cases.

I don't have time to find supporting sources right now, but I'll just say a couple of things, regarding Perl6 and string manipulation.

Less concretely, Perl6 is still Perl. What does 'Perl' mean? "manipulexity and whipuptitude" :) To me, those things are about being highly pragmatic in as many real-life situations as possible.

More concretely, even though Perl6 has an amazing type system, it's almost all optional. Use it incrementally, as it becomes more useful.

Also, the tight and powerful integration between language and regex still exists.

So, again, regarding string processing, these elements, to me, show that Perl6 is a 'strict supserset' of Perl5.

And, without any citations, I feel like that 'strict superset' is mostly true for things other than string processing!

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.

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

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

But with Inline::Perl5, it is, which I keep trying to point out. I think Inline::Perl5 may be a bad name for what is essentially "Interop with all your Perl 5 code and modules seamlessly in Perl 6, including XS".

> is an incredible insistence upon cognitive dissonance.

It seems like one more (maybe even initially unintentional, I don't know) gag of many of them. Python was named after Monty Python, but Perl 6 lives a Monty Python life. Remember the "Parrot"? The support for it in Rakudo was suspended only some months ago:

http://pmthium.com/2015/02/suspending-rakudo-parrot/

The Parrot was of course named after the most famous "Dead Parrot Sketch."

Reading about the "announcement" on the Pigdog site was of course completely fitting. An another site covered the beginning of the presentation:

http://www.10zenmonkeys.com/2015/10/06/the-night-larry-wall-...

"At 7:30 the room grew quiet, and the small throng of geeks migrated into the "Kanbar Forum" room." "There was already a browser on the screen that was displaying the Perl6 home page at Perl6.org, and two more tabs appeared to be IRC logs "for #p..." The quiet chatter turned to applause when Larry Wall finally walked out onto the stage. Then he made shadow puppets on the screen with his fingers — and left."

Once you accept the spirit, it's clear that nothing should remain "sacred." Not even the consistent naming of the language.

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.

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

On #1 we agree.

We don't agree on #2. Inline::Perl5 is better than I would expect, but there is still an issue. For example, Perl 6 uses garbage collection instead of reference counting so modules like http://search.cpan.org/dist/ReleaseAction/lib/ReleaseAction.... no longer work like they did in Perl 5. (Yes, that module is used in production code. And I happen to know of several independent re-creations of the same functionality that are used in the same ways in other production code.) I am sure there are other examples.

Granted, this a module that depends on a quirk of Perl 5 behavior. But even if only 5% of CPAN modules hit such a nasty quirk, dependency chains are long enough that most non-trivial applications will have some dependency that breaks somewhere. If I have a library that uses DBIx::Class, Moose, and Catalyst with some interesting plugins, would you care to bet money that it will work with no issues under Inline::Perl5?

On #3, what backwards compatibility means is "compatible with what you already have". Perl 6 immediately loses on that to Perl 5 because nobody has Perl 6 legacy code bases. Ideally this wouldn't be an important fact. But it is an important use case. Many organizations today are only staying on Perl because they do not want to rewrite their code. If they hit the point where they would be willing to do a Perl 5 to Perl 6 migration, there is no reason why they wouldn't consider a Perl 5 to Python 3 migration instead.

While I grant you there are probably modules with problems, I will state for the record that I don't consider any module that relies on specific undefined behavior that could stop functioning as expected due to a regular Perl 5 point release to be the problem of Perl 6. If Perl 5 could break or change its functionality by changing exactly when they deal with reference counting and destroy objects, then it's a time bomb in production anyway.

That said, your complaint in #2 was about Perl 6 losing to every other language in library support, but I think we've established it's nowhere near as bad as that. It's not perfect, but it's definitely not barren. There's a few tens of thousands of modules Perl 6 can try to use, and there's a fairly good way of knowing if they will work or not, since most have good tests.

Your original complaint for #3 was also about companies needing to rewrite all their code. I think Inline::Perl5 goes a long way towards addressing that as well. It's not perfect, but when considering "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." I think it affects that point of view.

I think you have somewhat valid points, I just don't think they are nearly as solid as initially presented.

...module that relies on specific undefined behavior...

You call Perl 5's use of reference counting "undefined behavior"?

It has been documented behavior for as long as Perl 5 has existed. The resulting destruction mechanics have been relied on by the core module http://perldoc.perl.org/SelectSaver.html for the same time. Furthermore any interesting XS program is likely to make use of the relevant macros SVREFCNT_int and SVREFCNT_dec.

Therefore this is NOT something that can be changed in a point release. It is a fundamental part of how Perl 5 works. And the fact that it is a fundamental incompatibility with Perl 6 plans is something that people have been aware of for a decade.

> You call Perl 5's use of reference counting "undefined behavior"?

No, I call counting on the fact that items with no references will be reclaimed (triggering DESTROY) immediately when they go out of scope undefined behavior. The fact that it happens very fast in most cases because it's reference counted and not garbage collected is not something that should be counted on. In fact, I'm pretty sure there are cases where in very tight loops, DESTROY isn't called immediately on scope end. I vaguely recall having to deal with that problem (but it could just as likely been a bug of mine that appeared to indicate that until I found it).

Followup, since it's too long since my reply to edit:

How are you assuming Inline::Perl5 works? Did you look into it and these are issues you found, or are these from how you assume it works?

Inline::Perl5 spins up an embedded perl5 interpreter (libperl I assume), and handles the data marshaling transparently. I assume (having not looked too closely at it's implementation), that it's sort of like a reverse XS. It looks into the perl5 guts, runs perl5 code, and exposes variables and functions to Perl 6. I see no reason to assume it wouldn't be using SVREFCNT_int and SVREFCNT_dec or equivalents as needed on scope changes to handle this.

In fact, looking at the Inline::perl5 repo now, it appears they are doing quite a bit with the refcnt functions[1].

1: https://github.com/niner/Inline-Perl5/search?utf8=%E2%9C%93&...

But Perl 5 was (and still is) backwards compatible with Perl 4.

This is a whole new language, and should probably be called Larry, or something.

Not quite true!

A good faith effort was made for compatibility. But it was not perfect. Hence http://www.perl.com/doc/FMTEYEWTK/perl425.html was created to let people know where the problems were.

Well sure and even in Perl 5's lifetime there have been depracations. But you're nit-picking. The majority of Perl 4 code ran under Perl 5.

Most did. But enough didn't to make it a major migration.

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

Yeah, performance sucks for Perl 6. Simple reason - first make it work, then make it fast. It's just been announced like yesterday that there's gonna be beta releases before the first stable release.

My money is performance will get better between now and Perl 6, v1.

It will be an extraordinarily long time before Perl6 becomes a better choice than Perl5 for the places I use Perl: Scripting on minimal OS installs, where there's nothing else installed.

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

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.

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

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.

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

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

I remember reading about the Perl 6 reinvention of regular expressions in 2009 and being really excited about it, as the syntax changes seemed really grounded in the actual experience of using regular expressions (such as my own).

  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)

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

http://doc.perl6.org/type/Str#method_length

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

method length

Perl 6 does not have a length function. See chars or elems.

length is gone. See:

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

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?)

Sorry about that, I've jumped a bit too fast on that one

I agree with you. I think a chars functions isn't the best name in the sense that it returns the length of the string instead of a list of its individual characters.

It makes me wonder if this will be the case for other methods in the language.

Every Perl expression has a context, and context is as central to Perl as types are to some other languages. It's first chapter material in any Perl book. It's not "overloading on return type" strictly speaking, but that's what the syntax looks like.

An array (of characters in your example) in a scalar context is the length of the array. I don't know if that's whats happening here, but that's how you do it everywhere else in Perl so it would make sense to do it on strings too.

Perl6 doesn't do this. A function doesn't know if it's being called in scalar or list context.

(I think there might be some movement towards letting a function detect sink (void) context. Then functions with both side effects and return values don't need to calculate the return values when they aren't needed.)

There's a specific reason why length was deprecated, and the error, which gives alternatives, may give some insight:

    # perl6 -e 'my $string = "foo"; say length $string;'
    ===SORRY!=== Error while compiling -e
    Undeclared routine:
        length used at line 1. Did you mean 'elems', 'chars', 'graphs', 'codes'?

Perl 6 tries to get unicode right. In doing so, it makes a distinction between characters, elements, codepoints and graphemes. At certain points, you may want one or the other of these.

When asking for the length of a string, what are you really asking for? The number of characters? Visible characters, or unicode combining characters? What if it's really the number of bytes in the string you need? Perl 6 makes it easy to determine all of these things in a clear manner. In doing so, it becomes obvious that "length" is ambiguous due to both its common specific role in other languages, and it's meaning when viewed in the context of these different needs.

If you want individual characters, you split the string, if you want access to the underlying data, you call .encode to get the encoding you expect, or you stick it into a Buf or Blob type if you don't actually need string semantics.

(Corrections welcome, I could be wrong at any number of points above).

That does shed some insight into why a generic Length is missing, but I agree with the sentiment that it is counter intuitive. It does not read right on a quick scan, and I think this is especially important in softly typed languages.

If I see string.chars I expect to see a bucket of char, and not the count of chars. That name needs to be more explicit.

It's terse which is another curse or benefit of Perl. The less terse method name would be string.numchars or string.charcount.

I think you are speaking from unfamiliarity with the language and possibly bringing baggage from other languages. In Perl 6, chars is the number of characters in a string, and elems, which is inherited from the Any role, exists on many objects and means the number of elements, as that makes sense for that object.

Perl 6 is not softly typed, it's gradually typed. It's as hard as you want to make it.

> If I see string.chars I expect to see a bucket of char

Why? Is that an expectation that comes from some other language? There's only so much you can expect a language to follow the semantics of other languages. Perl 6 will have it's own quirks, expecting it to conform to some malleable standard based on what some percentage of other languages do is not something I think is entirely fair to expect.

I think it's a poor selection.

<noun>s always has denoted some sort of collection to me and I'm sure you'll see many people have the same confusion.

> Why? Is that an expectation that comes from some other language?

No, the convention that (thing that can be viewed as a collection of subelements in several different ways).(plural name for one kind of subelement) is a property/method providing a collection of the subelements of the named type is not only common in other languages, it is also quite common in Perl 6 -- and even followed (aside from chars) in the Str class specifically; examples include (from Str): univals, lines, words, ords

chars is the odd man out here: charcount or something similar would have been a lot cleaner. (Yes, its consistent with elems, but that seems to be poorly chosen for the same reason; its a plural name, but it provides a single numeric value.)

I don't necessarily disagree with your reasoning, but I vaguely recall there was quite a bit of debate about the naming of these methods when they changed, and I don't recall the arguments. I have a feeling it's too late to change them now, so it may just have to live on as a quirk of the language.

> I have a feeling it's too late to change them now, so it may just have to live on as a quirk of the language.

I can see that, and I don't think its all that bad, just suboptimal, and confusing based on more than just expectations shaped by other languages.

In the code I'd make I'd always call these nchars and nelems and it would be intuitively clear (to me too one year after I wrote the code), but Perl 6 seems to like to mess with the accustomed minds. Renaming "for ( ; ; )" which was structurally identical to the C one to the "loop" is easy. Somebody also mentioned renamed ARGV to *ARGS. Examples aplenty.

It seems this and a lot of other details were intentionally made to clash with our habits, as I write in my other comment.

If I had been part of the effort, I would have suggested nchars, nelems, etc. chars and elems sounds to me also like I'm going to get a collection of some kind.

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

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)

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? :-)

> 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?

Because you cannot trust the 5-to-6 translators yet, so you have to test the translated perl6 code in perl6. It's a completely new VM, with new syntax, compiler and run-time.

Even with Inline::Perl5 you need to test the implicit 5<->6 casts with the perl6 vm (which might be rakudo or some other engine).

Moose contains only a small subset of the Perl6 OO, and has also different syntax. E.g. in perl6 types lead to optimizations, in Moose to pessimizations. Rewriting in Perl6 is always preferred, as Perl6 is a much nicer language.

Just keep that codebase in Perl 5? Perl 6 isn't a replacement for Perl 5. It's a whole new language. Perl 5 is still actively maintained and used.

> Perl 6 isn't a replacement for Perl 5. It's a whole new language.

...with an exceedingly poorly chosen name.

(Which is not to diminish how good it is as a language.)

I don't think anyone disagrees with that at this point, but hindsight is 20/20.

I personally wouldn't mind if there was a slow shift towards using the current main implementation's name (Rakudo) or some other (NG Perl?) for the language down the line, but I think doing so before release would just make every problem worse, including Perl 5's ("Oh, Perl 6 is no more? It failed? I knew it would... Perl is a dead end.")

In Perl 5, for and foreach have been aliases for eachover for a very, very long time.

    # perl -E 'foreach (my $i=0; $i<3; $i++) { say $i }'
    0
    1
    2
    # perl -E 'for my $i (0..2) { say $i }'
    0
    1
    2

I never use foreach in Perl 5, and that's what I'm paid to write in. This is just a reaffirming that "for" is the preferred syntax (and this isn't a TMTOWTDI thing, this is two reserved words for the exact same code construct thing).

Moose, interestingly enough, is based on backporting the then-proposed Perl 6 object system, so a lot of the concept sand terminology will be the same.

But it sounds like you are talking about transitioning from Perl 5 to Perl 6. Why? The naming is confusing, but most people are not expected to convert codebases to Perl 6. It's not an upgrade, it an also. If you want both, use Inline::Perl5[1] and just call back and forth between the interpreters.

1: https://github.com/niner/Inline-Perl5

Though to be fair, for the last year or so, every time I've needed to hack on a p5 script for $work, my first step has been to convert it to p6. It usually is pretty quick for 50-100 line scripts, and generally it's a lot easier to reason about changing the code once it's in p6.

With apologies for the blizzard of questions:

Do you have/write test suites? In P5? P6?

Have you seriously tried any of the p5-to-p6 translators with your scripts?

Was the usage message typically much-improved, about-the-same, or needs-work after your first successful compile?

Same question for command line argument binding?

Any speed stories? Scripts that started unacceptably slow but eventually got there? Ones that beat their Perl 5 originals? Ones that didn't really make it yet?

Have you converted any of your Perl 6 conversions back in to Perl 5 code (to retain the clarity developed in the conversion to 6 but regain the speed that Perl 5 has)?

Do any of your conversions use Perl 5 modules?

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.

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.

IMHO Perl 6 will not catch on / be even mildly successful without a clear upgrade path from Perl 5.

The ask for people to use Perl6 is a huge one given it's basically a completely different beast that just resembles Perl5.

Without pointing out where Perl6 excels (in comparison to Python/Ruby not Perl5) this will probably be a non-starter for most people.

(this is from somebody who did his fair share of Perl5 in the old days and would not go back to Perl5 / try Perl6 unless there would be an extremely clear differentiator that would make it worth it.

Did you actually look at Inline::Perl5[1] and Inline::Perl6? If may not be what you assume, and may change your opinion on whether an upgrade path is required. In short, Inline::Perl5 it's a way to interop cleanly with Perl 5 modules from Perl 6 using native Perl 6 syntax, and supports XS modules as well. I'm not sure I can imagine a more painless transition than what that allows.

1: https://github.com/niner/Inline-Perl5

This is entirely a naming problem. Calling it "Perl 6" implies that it's a linear descendent of Perl 5, which it most certainly is not. Perl 6 is something else entirely. Which would be fine, if the name indicated that. But it doesn't, which is perverse. The name implies something different than what the product actually delivers.

It's the "New Coke" (see https://en.wikipedia.org/wiki/New_Coke) situation all over again. When Coca-Cola rolled out New Coke back in the '80s, lots of people actually preferred the taste of the new formulation to the original, "classic" Coke. But it failed anyway, because it came in a can labeled "Coke" but tasted very different than what people thought the contents of a can labeled "Coke" would taste like. Their brains never made it to the "hey, this tastes better!" part, because they were too busy raging over thinking they were getting one thing when they were actually getting another.

It's been clear for more than a decade now that Perl 6 was going to be a big, discontinuous change instead of an incremental step up from Perl 5, so why they've persisted with calling it "Perl 6" all this time is beyond me. Just call it something other than Perl and 90% of the gripes about it will vanish overnight.

I think it's entirely possible it may shift in naming slowly after released. To do so beforehand would be to doom it to obscurity through even more confusion. People might start referring to it by the implementation (Rakudo), which I would be fine with. Maybe a year or two after release it would be possible to do officially do something like this. Prior to that and I think there's far more downsides than upsides (and even after that time who knows what would happen if the name actually changed?)

yep. As a Perl 5 dev, it always frustrated me that Perl 6 was around. It made it real easy for people to throw rocks at. "Oh look, Perl is dead because Perl 6 is not released." Never mind the fact that Perl 5 continued to be updated, has features some languages only wish they had (superior Unicode support, CPAN, etc.), and is probably the most stable language we have ever seen, thanks to a decade of mostly maintenance releases.

Turbo Pascal/Object Pascal was able to become "Delphi". Delphi was still Pascal, as Perl 6 is still a "Perl". Maybe it's still possible to rename it? It will be a hell of a PR battle now.

Perl++?

I don't think this is just a naming problem, and the implications can be significant--Python 3 has been around for almost a decade at this point and is still struggling to gain share against Python 2, and it is a less radical syntactic departure (IMO) than Perl 5 to Perl 6. If Perl 6 saps energy from Perl 5 but can't actually take off on its own the whole ecosystem will suffer. I don't fault Wall for wanting to fix some of the enduring pain points in Perl but I think C to C++, where C++ was a superset, and could thus use existing C code, and the JavaScript ES5 to ES6 transition where almost every change is pure sugar are much better examples of how to do this sort of thing.

Sorry I don't get it. Why would I rewrite an entire ecosystem in a new language, especially when Perl 5 is very well supported. Perl 5 code will remain as is.

Perl 6 is for new projects. And if I'm familiar with Perl 5, it makes all the more sense to use it for my new projects. For non Perl programmers it makes a nice new language to learn.

I'm curious, because I haven't seen much discussion on this point: Ignoring that it is called Perl 6 and has it's lineage in a well-known language called Perl 5, what are some of its advantages over some of the other languages it will be considered alongside?

If I'm starting a new project, and I'm familiar with a bunch of other languages (including, but not limited to, Perl 5), what should draw me to Perl 6?

At this point Perl 6 is new enough that the use cases is excels at may not be well defined.

If you want to learn something new, and not be hampered by a feature in some other language not being supported (at this point the main feature is that it basically has all the features of all the languages), then trying out Perl 6 may be worth while. If nothing else, you've prototyped your project, found out what programming paradigms make sense and work well for your use case, and can switch to another language that offers that which achieves some other unmet goal of yours.

So, I guess that's a possible use case. Prototyping where you aren't sure what language features would be really useful and provide benefit later. Channels? Threads? Async? Promises? Lazy lists? Operator overloading? Roles? Grammars?

> IMHO Perl 6 will not catch on / be even mildly successful without a clear upgrade path from Perl 5.

Why can't it be successful based on its own merits?

Go didn't have a clear upgrade path from anywhere. Rust doesn't, nor do Julia and all the other new, hip languages that I just forgot about.

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, ...?)

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.

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

Pretty much. Perl 5 and Perl 6 have different maintainers and will continue on separately for the foreseeable future. Some in the Perl 5 community wouldn't mind a name change just so the Perl 5 v.s 6 naming scheme isn't an issue but it's not likely to happen.

In my opinion, no, an EOL is not being discussed.

What is being discussed is the excitement brewing from the all the work that has transpired via the Modern Perl movement.

We have modern web frameworks (Mojolicious, Dancer, PSGI/Plack); YEARLY releases of Perl 5; CPAN has never been easier to work with (cpanm, cpanfile, carton); a healthy and supportive community; and modern infrastructure to work with OO (e.g. Moose).

There are several of other things I haven't mentioned.

For example, if you want to try a web app with one of the latest perls:

  $ curl https://raw.githubusercontent.com/tokuhirom/Perl-Build/master/perl-build | perl - 5.20.3 /opt/perl-5.20

  $ curl -L https://cpanmin.us | /opt/perl-5.20/bin/perl - App::cpanminus Mojolicious

  $ /opt/perl-5.20/bin/mojo generate lite_app all_the_awesome.pl

  $ /opt/perl-5.20/bin/perl all_the_awesome.pl daemon

... Goto a browser and visit http://127.0.0.1:3000

The above command assumes you have a system perl that can bootstrap your user perl into /opt/perl-5.20.

Thank you for asking.

perl5 is a language name - its current release is version 22.

I presume perl6 will be doing similarly.

mst as one of the biggest perl5 proponents are you planning to switch to perl6? 1. yes 2. no 3. maybe 4. will use both

I have a plan that involves using Inline::Perl6 to get at the grammar engine, which will presumably result in me writing perl6-side shim code and then I'll have a better idea how I feel about it.

So (4), but what percentage of each that'll end up being in the long run I've no idea.

No, there won't be EOLs for the foreseeable future. For all purposes, you can imagine Perl 6 being called language XYZ. Even though 15 years ago, Perl 6 was envisioned as the next version of Perl 5, that is no longer the case. Perl 5 and Perl 6 are both actively-developed, modern languages—different languages, in the same family. Perl 5's latest release was just about 47 days ago and Perl 6's first release will be on Christmas.

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

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.

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.

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

Everything is a reference! Nice!

Not really if you car about efficiency.

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.

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

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

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

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.

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 ;)

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.

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.

Any Perl 6 code will have to include a `use v6;` instruction at the very top of the file, so there's no chance of Perl 5 code being confused for it. Is this what you mean?

EDIT: this was completely wrong, see below.

`use v6;` is not mandatory in Rakudo. Off the top of my head, I don't think it's mandatory in theory in Perl 6, either. However, it is widely used to mark Perl 6 code, because it gives you a nice clean error message if you accidentally try running it in Perl 5.

Oh! I could have sworn it was necessary. My bad.

You should declare the version of your code. 'use v6;' for Perl 6 code (more specific versions will come up soon), and "use 5.014" for Perl 5.14, for example.

This will give good error messages when trying to run your code with the wrong compiler.

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

Oh no.

It gets worse. "Hey, let's double down on weak typing!": http://examples.perl6.org/categories/cookbook/01strings/01-0...

  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'

  print  "1" + 1 ; # 2

This isn't new, is it? '+' is for addition, '.' is for concatenation.

In Perl 5, yes. In Perl 6, ~ is for concatenation, '.' is for methods.

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.

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

There is nothing "high cognitive load" about having different operators for addition and concatenation.

I think it's simpler.

Who "adds two strings"? You're 1) converting the strings to ints 2) adding the ints.

The possibility of confusion is the part that is already complex.

> Who "adds two strings"?

$timeText = $systemHours . ':' . $systemMinutes;

$durationTimer = $userInputHours + 1;

There ya go.

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

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... discussed this exact problem some 30 years ago. I do not believe that the intrinsic problem is being solved any better today than then.

PHP and other languages have a . vs + distinction.

I would say that the one area where you're right, and you are so very right, is context. Have %/@/$ cause such chaotic (and not terribly consistent, at least outside the core libraries) behavior changes was not worth the improved error messages or cool tricks you can do with it.

This is coming from someone who really likes Perl (5) both in practice and philosophically.

Honestly, I think the Perl way is clearer than the Python way:

Perl: unary + is "convert to number", binary + is "convert operands to numbers and add". This is clear and consistent. String concatenation uses a different operator completely.

Python: binary + is string concatenation if the left operand is a string, and numeric addition if the left operator is a number. It fails at runtime if the right operator is inconsistent with the operation specified by the combination of the operator and the left operand.

That's not weak typing. That's type coercion.

You're thinking of JavaScript in this particular issue.

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.

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?

So its a marketing decision? That's depressing.

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.

Reply on news.ycombinator.com