Live data from Hacker News

Differences Between Perl 5 and Perl 6

design.perl6.org

61–70 of 127 posts

Re: Differences Between Perl 5 and Perl 6

#61
post #44

Earlier quoted context omitted.

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 o…

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 ag…

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

Re: Differences Between Perl 5 and Perl 6

#62
post #46

Earlier quoted context omitted.

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 numeri…

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.

Re: Differences Between Perl 5 and Perl 6

#63
post #55

Earlier quoted context omitted.

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

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

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.

Re: Differences Between Perl 5 and Perl 6

#64
post #44

Earlier quoted context omitted.

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 o…

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 ag…

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.

Re: Differences Between Perl 5 and Perl 6

#65
post #44

Earlier quoted context omitted.

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 o…

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 ag…

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.

Re: Differences Between Perl 5 and Perl 6

#66

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

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.

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

Re: Differences Between Perl 5 and Perl 6

#67
post #46

Earlier quoted context omitted.

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 numeri…

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

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

Re: Differences Between Perl 5 and Perl 6

#68
post #35

Earlier quoted context omitted.

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 gra…

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.

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.

Re: Differences Between Perl 5 and Perl 6

#69
post #66

Earlier quoted context omitted.

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.

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.

Re: Differences Between Perl 5 and Perl 6

#70

Earlier quoted context omitted.

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

Post reply on HN