|
> And the "Perl" brand is still very strong, so we are loath to give it up. 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.