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