Comment by kbenson | Hacker News Reader

Comment by kbenson | Hacker News Reader

Parent Full thread

I wish I could be confident that Perl 7 was actually going to see the light of day. Honestly, I was extremely excited when they announced it, and hoped it could make a real difference. The lack of real status information since then (even past the proposed initial release date) along with the implosion of the a lot of the core community and steering, is honestly what finally broke me from thinking anything could be salvaged for the future.

If Perl 7 is actually still coming and there's real progress there, then there's a spectacular messaging fail going on.

Perl's been my go-to language for well over 20 years, and it's the first thing I reach for when writing anything new. The problem is I'm having a harder and harder time justifying that decision. I built something small with Deno for the first time a few months back because I both wanted to try out typescript and I wanted something that I could easily turn into an executable on windows. The built in features (compile to an executable, limited security exposure based on runtime flags) and the ability to go far past JS because it as TypeScript built in all put a lot of stuff with Perl in stark relief. These are features you get when you have people actively trying to solve people's problems, iterating on substantial new and better things, and you have users (or potential users) with problems to solve. Perl 7 is/was possibly Perl's last chance to pull itself out of the ashes and try to offer something new to pull new people in and bring old users back, and I'm just not sure there's enough of a community left to pull it off. That's extremely sad, but ignoring it won't make it any less true as I see it. Hopefully I'm wrong.

The original proposal for Perl 7 was good at grabbing attention, but not good at being something that could reasonably be accomplished by the current set of core developers - it would require either maintenance of two forks of the language (not feasible), or sunsetting of Perl 5 (risking it all on unlikely adoption and migration to the new fork, and likely losing several volunteer developers).

The current status is, roughly, planning for Perl 7 to be a compatible release with good features, and waiting until such a featureset is ready. See https://perl7faq.grinnz.com

The way I read it (which might have been reading between the lines), is that whatever 5.3x was released with Perl 7 would be the last in that line, but it would never die, and just get bug fixes.

I viewed Perl 7 as a way to break from the expectations of the two types of existing Perl users. Those that use it for stuff they expect to continue working without fail in perpetuity, relying on Perl's exceptional forwards compatibility, and those that are willing to break that to usher in new features that are long overdue.

At work we have Perl in production that's well over two decades old, and all stages in-between because it's always been the core language of our department. The expectation that it "just works" for the most part on newer OS distro releases with newer Perl is extremely valuable to us. At the same time, new development in it has gotten more and more cumbersome over the years, both in relation to other options and in itself, as modules for newer services and APIs are less likely to be available and well maintained.

Perl 7 as an idea was exciting to me because I viewed it as a way to both satisfy the needs of the job I'm in (through a static Perl 5 version), and also my personal tastes by allowing Perl to evolve and change as needed, and add some long overdue features (or even just change defaults to be sane for the current time).

You were reading between the lines, and the initial announcement was writing between them. But like I said, it is not feasible to maintain a LTS Perl 5 next to a fork of the interpreter. The actual proposal was only even to maintain Perl 5 for a few years before sunsetting it. CPAN would not have been compatible with Perl 7, it would require a separate ecosystem of code and installed libraries. The ideas sound nice but I don't think a lot of people would have been happy with how the details would have worked out. Most of the problems you're talking about are more a deficiency of perception and tooling, and these can be addressed without such drastic measures.

> But like I said, it is not feasible to maintain a LTS Perl 5 next to a fork of the interpreter.

I know, but even if the Perl community didn't want to maintain it, it would be maintained. Some company would take that up and provide it (ActiveState maybe?), because there's a need for it and companies that would pay for it. That it would be maintained is all that really mattered to me, and there's no doubt in my mind that it would be.

> Most of the problems you're talking about are more a deficiency of perception and tooling, and these can be addressed without such drastic measures.

I'm not sure they can be. There's a decade of the past of evidence that they wouldn't be, even if it is theoretically possible. As soon as you make breaking changes, you would possibly lose a lot of corporate users because you force work on them where there wasn't previously, and that means deciding whether that time is better spent moving away from the aging language with an unsure future. Losing those users would gut what little was left of the community.

That's long been the catch-22 of Perl, and getting past that has long been the hardest problem facing the community, IMO.

> That it would be maintained is all that really mattered to me, and there's no doubt in my mind that it would be.

Nor mine, but because I know that Perl 7 would die as most of the maintainers stayed working on Perl 5. Or the worst case: too many leave Perl entirely to maintain either fork. Perhaps some corporations would take up the funding, but it is not a simple piece of software you can throw new developers at and expect progress; it's an enormous C program built on thousands of macros and decades of history, as anyone who has tried writing XS code probably sees in their nightmares.

> As soon as you make breaking changes,

I am referring specifically to doing it without breaking changes, as is the current plan, and the only option at this juncture.

Reply on news.ycombinator.com