It's both, really. If you use it (and after a while of getting used it), it just feels like perl.
> I fully support the development of Perl 6, but I really wish the name would change to something that doesn't involve Perl.
Well, in retrospect, it might have been a good idea to name it something else entirely. But that's too late now, and nobody has been able to come up with a good new name anyway. And the "Perl" brand is still very strong, so we are loath to give it up.
Finally, Perl 5 has many unsolved problems that will hinder its evolution in the upcoming decades. Once Perl 6 has become as fast and mature as Perl 5 is now, we want to provide the future that's closed to Perl 5.
That is great for you as a Perl 6 developer that gets extra attention for the new language by leveraging the Perl brand, but it is absolutely awful for people in the Perl 5 community. Perl 6 gets free press, but Perl 5 gets mocked and public opinion turns even further against it.
> Finally, Perl 5 has many unsolved problems that will hinder its evolution in the upcoming decades. Once Perl 6 has become as fast and mature as Perl 5 is now, we want to provide the future that's closed to Perl 5.
I know Perl 5 isn't perfect, but no languages are. You refer to "unsolved problems" and while I'm sure there are from your perspective, from mine as someone who writes large Perl 5 applications, there are no great issues. I can do everything I need to already, and I can do it really well. I don't need Perl 6, and I won't even consider it until it has a proven track record.
For most people to make the switch, Perl 6 won't need to prove itself as being just better than Perl 5, but it will need to prove itself as the right choice in the full market of languages out there. For at least a few years, and likely many more, Perl 5 will still be the right choice for a lot of work, and Perl 6 will do nothing but confuse people and cause public opinion about Perl and with it Perl 5's market share to sink even further.
First of all, the press for Perl 6 isn't free at all. We get press because we do cool stuff with programming languages. So do the Rust and Nim communities, for example. Please don't downplay our effort. And the comments are full of prejudice against Perl 6 that is rooted in its Perl 5 legacy; so it's not "free" in a second dimension.
Second, in my experience, Perl 6 is only a small part of the ridicule. Mostly it's about Perl being aweful to read (for which Perl 6 bears no blame at all), lousy code quality, unfamiliar looks through sigils, and so on.
> You refer to "unsolved problems" and while I'm sure there are from your perspective, from mine as someone who writes large Perl 5 applications, there are no great issues
Have you ever asked yourself if this is actually true? Would your work be much easier if you had sane threading in some scenarios? Subroutine and method signatures? never had to deal with the bloat that comes from different libraries using different object systems?
I also happen to work on big Perl 5 code bases for money, and with the knowledge of what's possible in a perlish language, I regularly identify pain points that in the end are rooted in missing or deficient language features.
I am looking forward to the future of Perl 6. I really do like some of the things I've seen going on there, and it is fairly likely that in the future I will be happily writing Perl 6 code on some projects. With that said, I am very concerned about how Perl 6 carrying the Perl name will impact Perl 5, but that is separate from my excitement that a new more modern language will be carrying forward some of the Perl styles.
In short, I do appreciate Perl 6 and I don't mean to downplay anything going on there, but my concern is about what it all means for Perl 5.
Come now; that was the excuse given five and ten years ago.
the "Perl" brand is still very strong
Some would argue (including the post to which you're replying) that the brand is much less so, thanks to the very line of thinking you're defending.
Perl 6 did not "kill" the Perl brand, the state of Perl circa-2000 "killed" the Perl brand. All the issues @perlgeek just noted, those "killed" the Perl brand. The fact that Python was simply a better option for 99% of the projects that were started around that time (even if half or more went with PHP instead) "killed" the Perl brand.
If Perl 5 as a programming language is so susceptible to "oh but this new version makes it seem that there are deficiencies in the current version", could it be because there are deficiencies in Perl 5? If hiding that fact from others is so important to the "brand of Perl", what does that actually imply?
Please stop pretending that starting a project to build a better Perl somehow killed the camel. It's obvious that this is not true even from a Perl 5 usage standpoint, but it's even more absurd from the standpoint of next year, or the year after...
It's easy to look at the rate of change and the timeline of releases of Perl after 2000. It's easy for me to argue that the announcement of P6 (and the promise that 6.0 would be a successor to 5.10 or 5.12) took a lot of momentum from working on Perl.
I suspect, but can't prove without a time machine and a multiverse, that if the "they're sister languages" line of thinking had been in place from the start, Perl could have avoided its lost decade (5.6.0 to 5.10.1).
I'm wondering which unsolved problems you're referring to in particular. (Surely Perl 5 is not the only language which might happen on problems in upcoming decades, and just as surely Perl 6 isn't immune to them.)
* way too many globals in the language, making any sane threading support very hard
* OO (or lack thereof) in core. Yes, there are nice OO modules out there (Moose/Moo), but it's easy to land in a situation where you have several OO modules in the same project. Also, many built-ins still only deal in strings (example: error messages), not objects.
* lack of proper subroutine signatures. The ones in 5.20 are a step in the right direction, but still far away from anything that the competing languages offer
* high exposure of internals to the XS (C) API make it nearly impossible to do substantial rewrites of the internals
* The regex syntax has been extended way beyond its limits of sane extensibility. Yes, Perl 5 now has named captures, re-usable(ish) subrules and all that neat stuff, but the syntax is so arcane that I have to look it up every single time I use it.
* Poor type system. Perl 5's types (scalar, list, hash, code, type glob) simply aren't enough in world where you have to distinguish binary data and Unicode strings, for example. Or subroutines and methods.
