Live data from Hacker News

What Happened to Perl 7?

blogs.perl.org

11–20 of 245 posts

Re: What Happened to Perl 7?

#11
I’ve written a nontrivial anount of Perl code in my life, admittedly almost none in the last decade. For all its obvious flaws, I always liked the language, and am happy to see it getting attention and moving forward.

Having said that, I think this might be too fine-grained.

First, opting in to an experimental feature could be a one-liner, “use experimental feature ‘try’” or similar. There’s no point in punishing your valuable beta testers beyond that with a second line that’s entirely redundant with the first one.

The larger problem is the versions. This basically requires someone to update their script headers all the time if they want to keep getting new features. Probably not much of a problem currently, but might be if releases get more frequent. I personally like the “edition” concept of Rust a lot better: get over with all necessary breaking changes in one swoop, but then begin a new (hopefully long) era of backwards compatibility. That makes it easier for users to maintain their code, is probably easier to implement, and also easier for users to learn, since there are fewer sets of rules.

Lastly, I hope they also focus on tooling around installation. One paradoxical problem with modernizing Perl is its historic success: every variant of Linux or Unix already comes with an ancient version of it. I know many experienced Unix people hate this trend, but there’s a reason some of the most actively evolving language ecosystems install more and more of their binaries into the user’s home directory. Maybe that’s already the case for Perl, I wouldn’t know.

All that said, I’m not following Perl that closely anymore. These are just some really quick observations about very complex topics. I don’t claim to know nearly as much as the people who made these decisions, and it’s great to see that things are happening.

Re: What Happened to Perl 7?

#13
post #9
post #7

Earlier quoted context omitted.

Speaking as a London-based freelancer specialising in Perl, I can tell you that the number of companies developing new systems in Perl is tiny (like, maybe, half a dozen). Until four or five years ago, there was still plenty of maintenance work to be had, but even that has pretty much dried up now.

what are you going to do then?

I'm semi-retired. I have a part-time contract maintaining a system I worked on a few years ago and I pick up other bits of freelance work from time to time.

And I've been prototyping a few project ideas (in Perl) to see if any of them could be a sustainable source of passive income. Of course, if any of them grow to the extent that they need a development team, I'll need to rewrite them in a more sustainable language.

Re: What Happened to Perl 7?

#14

I'm curious to know if anyone out there building new systems in Perl or is it all just maintenance mode for Perl based systems?

I chose to build in Perl because of its ubiquity and committment to backwards compatibility.

I was extremely frustrated with existing projects having dependency issues and frequent breakage and wanted to avoid that at all costs.

Perl's flexibility has allowed me to develop my own coding style, which is basically Java-like, and I rarely have trouble figuring out what something does, even months later.

I think Perl is vastly underrated as a language, and its suffers from repeat-speak of people who have only seen poorly written Perl or have never seen a well-managed Perl project.

One of my favorite things about Perl is that there are 20 years of code samples on the Web for it and they ALL WORK because Perl has not introduced breaking changes since 5.000.

Re: What Happened to Perl 7?

#15
post #11

I’ve written a nontrivial anount of Perl code in my life, admittedly almost none in the last decade. For all its obvious flaws, I always liked the language, and am happy to see it getting attention and moving forward. Having said that, I think this might be too fine-grained. First, opting in to an experimental feature could be a one-liner, “use experimental feature ‘try’” or similar. There’s no point in punishing you…

> The larger problem is the versions. This basically requires someone to update their script headers all the time if they want to keep getting new features. Probably not much of a problem currently, but might be if releases get more frequent.

But to use that new feature they'd need to modify their code anyway, so this isn't really an issue in practice, is it?

> I personally like the “edition” concept of Rust a lot better: get over with all necessary breaking changes in one swoop, but then have a new (hopefully long) era of backwards compatibility.

How is this any different from having a repeat of the python2->python3 fiasco (which, AFAIK, Perl developers are trying to avoid)? Making piecemeal (if needed) changes is much easier than having to update a ton of code and that is even more important when that code wasn't touched for a long time.

EDIT (i put it here since i already got three replies on the same thing): i understand that you can mix two different files with different "editions" but it still makes it hard to update these files themselves.

Re: What Happened to Perl 7?

#16
post #11

I’ve written a nontrivial anount of Perl code in my life, admittedly almost none in the last decade. For all its obvious flaws, I always liked the language, and am happy to see it getting attention and moving forward. Having said that, I think this might be too fine-grained. First, opting in to an experimental feature could be a one-liner, “use experimental feature ‘try’” or similar. There’s no point in punishing you…

>>I know many experienced Unix people hate this trend, but there’s a reason some of the most actively evolving language ecosystems install more and more of their binaries into the user’s home directory.

The future is containers, which is basically increasingly thin images tailored to your application.

These days I struggle to find Perl on many EC2 instance I work on. Its always good to have something like Perl in your installation for some quick scripting work. But most don't have Perl installed.

Re: What Happened to Perl 7?

#17
post #11

I’ve written a nontrivial anount of Perl code in my life, admittedly almost none in the last decade. For all its obvious flaws, I always liked the language, and am happy to see it getting attention and moving forward. Having said that, I think this might be too fine-grained. First, opting in to an experimental feature could be a one-liner, “use experimental feature ‘try’” or similar. There’s no point in punishing you…

> The larger problem is the versions. This basically requires someone to update their script headers all the time if they want to keep getting new features. Probably not much of a problem currently, but might be if releases get more frequent. But to use that new feature they'd need to modify their code anyway, so this isn't really an issue in practice, is it? > I personally like the “edition” concept of Rust a lot be…

IIRC you can mix different editions in a project, and I think backward incompatibilities are also fewer (and detected at compilation)

Re: What Happened to Perl 7?

#18
post #12

The feature pragmas look like an interesting way to preserve backwards compatibility & yet allowing for new language features.

Yeah, this is basically what Free Pascal does too. The default language mode is actually kinda obsolete (it is more of a Turbo Pascal 7+), but you can change dialects with the $mode directive (with most common being "objfpc", an extension to the default "fpc" mode that adds more advanced features and "delphi" which is used for Delphi compatibility to allow sharing code). In addition to that many new features are enabled with additional directives, like $modeswitch (e.g. "$modeswitch advancedrecords" enables using methods and management operators in records and "$modeswitch prefixedattributes" enables attaching custom attributes to classes, properties, etc to be accessed via the RTTI later) and $scopedenums (so that when you have an enum like TFoo = (Bar, Baz) it wont create Bar and Baz globals like in classic Pascal, but TFoo.Bar and TFoo.Baz - the fact that it isn't a modeswitch is most likely for Delphi compatibility as AFAIK Delphi doesn't have a modeswitch directive - or mode directive for that matter).

It does require having a litany of switches at the top of each source code but it beats having old code break (though i do think that in some cases the FPC devs go a bit too overboard - e.g. attributes would be a syntax error anyway).

Re: What Happened to Perl 7?

#19
post #11

I’ve written a nontrivial anount of Perl code in my life, admittedly almost none in the last decade. For all its obvious flaws, I always liked the language, and am happy to see it getting attention and moving forward. Having said that, I think this might be too fine-grained. First, opting in to an experimental feature could be a one-liner, “use experimental feature ‘try’” or similar. There’s no point in punishing you…

> The larger problem is the versions. This basically requires someone to update their script headers all the time if they want to keep getting new features. Probably not much of a problem currently, but might be if releases get more frequent. But to use that new feature they'd need to modify their code anyway, so this isn't really an issue in practice, is it? > I personally like the “edition” concept of Rust a lot be…

> How is this any different from having a repeat of the python2->python3 fiasco (which, AFAIK, Perl developers are trying to avoid)?

AFAIUI you can mix Rust 2015, 2018, and 2021 crates; so a developer can update their own crate to 2021, while not having to completely re-write the dependencies which are still Rust 2015. With Python 2 -> 3, my understanding was that everything had to be updated recursively.

That said...

> I personally like the “edition” concept of Rust a lot better: get over with all necessary breaking changes in one swoop, but then have a new (hopefully long) era of backwards compatibility.

What they describe actually sounds somewhat similar:

> At some point in the future, the PSC may decide that the set of features, taken together, represent a big enough step forward to justify a new baseline for Perl. If that happens, then the version will be bumped to 7.0. If this happens, Perl 7 will still be backwards compatible with Perl 5 by default – you'll have to put use v7; at the top of your code to use all the new features. Think of use v7 like Modern::Perl and similar modules.

So the 'use ' is going to be similar to Rust's "nightly unstable features", but actually being stable; and 'use vN' is going to be like Rust's Editions.

It's just that they don't think they've accumulated enough features to release a new Edition yet.

Re: What Happened to Perl 7?

#20
Ah Perl!

The old friend, you can always rely on to do quick scripting work. I've written non-trivial quantities of Perl in the past, and maintained other people's Perl code too. Contrary to popular opinion, I've always found it easy to maintain.

I still call upon Perl to do

    open(FILEHANDLE, $file) or die;
    while(){
    ....
    }
    close(FILEHANDLE)
Sort of work.

These days I do good deal of work in Python. Python itself has been heavily Perlified over the years, especially Python3. Its fame seems to have come moving away from Pythonic principles, to Perlic principles. They add lots of features, even syntactic features, libraries and even things like typing. Python isn't the small, minimal core of ecosystem anymore.

Every single release of Python gives me the Perl feel from the old days.

So I kind of don't miss Perl at all, after all we managed to turn Python into Perl.

Long live Python, Long live Perl.

Post reply on HN