Hacker News Reader

But that's too late now....

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.

I've been in and around Perl for a long time, and this line of argument feels very tired to me.

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

Please stop pretending that starting a project to build a better Perl somehow killed the camel.

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

But Perl 5 is _not_ dead. The camel lives, and has two humps. The "lost decade" cannot be ascribed only to Perl 6. Developers were leaving in droves to newer dynamic languages of the same generation (Python, PHP, and eventually Ruby).

I can agree that it had an influence, but I'm sick of the Perl 5 perspectives that a) the language is flawless and only an idiot would choose something else, b) Perl 6 pointed to flaws which don't exist because hand-waving, Rule A, etc.

Perl 5 has fundamental problems. At first Perl 6 was an attempt to solve those problems without a complete compatability break. That proved impossible, so the scope expanded to be a new Perl.

"But it's painting a bad picture of Perl 5!"

Perl 5 painted it's own picture, I'm sorry to say. The toxicity of p5p, the constant "this language is fine why are you making a new one", the over-confidence that Perl 5 is a pinnacle of how you can design a Perl language... these are Perl 5 things, and they belong to Perl 5. Yet I rarely see Perl 5 programmers owning to these facts.

It's just tired. You yourself did a great job in breathing new life into Perl 5, as part of the Modern Perl movement, which takes as its starting point that Perl 5 allows some seriously flawed programming. Techniques and ideas borrowing from Perl 6 are used to make life easier in Perl 5, developed during the "lost decade".

So, I'm sticking to my position that this whole line of thinking is just tired. For outsiders, Perl 5 was a non-starter because of all the flaws with the language, not because another version was in the pipeline that promised to fix those flaws.

FWIW, I program in Perl 5 every day, and I really enjoy the language.

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

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

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.

Sorry if anything has come off as being too argumentative. I just feel like you are downplaying the large impact that Perl 6 has had on Perl 5 and the public perception of Perl, and the impact that will come when a 1.0 version is officially released. With the new release coming up this may be the last opportunity to avoid the future damage, and that is what my question revolves around. As for everything else, we are really on the same side and I agree with you on the notable points, so I will leave out further discussion.

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.

> Finally, Perl 5 has many unsolved problems that will hinder its evolution in the upcoming decades.

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

Here are a few:

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

Yeah, something like Perl++, Perl 10/Perl X, or something that indicted the scope of the difference in the rewrite would have been nice, though I think it's too late at this point. Ten years ago it would have helped, now 'Perl 6' has been floating around for fifteen years.