I prefer not to run the latest version of Perl because

• there is too much technical debt in my codebase
• the stability of the system perl suits me better
• I have to support users of some ancient version
• I'm stuck with ActiveState/TinyPerl/microperl/...
• letting the early adopters trip over the bugs is fine
• some other reason

• I have to develop for the version of Perl that is on the production systems
• my web hosting provider has not updated their Perl

Actually, those two (plus maybe "have to support users") boil down to:

• I am not the one who decides if/when the Perl version is upgraded

Not sure if "the stability of the system perl suits me better" is intended to cover this, but:

- the cost of potentially introducing new bugs far outweighs the benefit of (this list of) new features;

- last time I upgraded everything broke, I don't want to do that again.

The first of those pretty much covers the perl I use for maths research - it is currently running on 5.34, but I tend to upgrade it very rarely. If I find a bug that affects my maths results, I potentially have to rerun tens of CPU-years-worth of calculations. (Last time that happened I was lucky that I had just moved to a much faster new computer, so it only took 6 months to recompute the previous 10 years of calculations.)

The second covers a couple of companies I used to work for.

G'day hippo,

I really like this idea for a poll.

If this is used in the next few months, replace "latest version" with v5.36; if later in 2023, use v5.38. There's also the possibility that "latest version" is v7.0. Anyway, I'm just thinking that attitudes may change depending on what that "latest version" is.

Furthermore, an option should be provided for those with the opposite preference. I'm not sure of the best wording; perhaps something like:

• well, actually, I have no such preference: I'm happily using <latest version>

— Ken

Not that I condone any of these reasons, but...

• I find re-installing all of my modules into a new version a hassle
• we use XS code that doesn't compile against newer Perls
• I just haven't gotten around to it
• I simply don't want to, for reason X (comment below) [perhaps instead of "some other reason"]

I'm waiting for IndigoStar Software to release "perl2exe" for the latest version of Perl.

"It's not how hard you work, it's how much you get done."

• I'm stuck where Strawberry Perl is

  L*

  There are no rules, there are no thumbs..
  Reinvent the wheel, then learn The Wheel; may be one day you reinvent one of THE WHEELS.

Is that worth lumping in with the ActiveState/TinyPerl etc. group or is it a different class of problem? (I don't use such things myself so defer to your expert knownledge)

---

🦛

• because older perls are faster

  L*

  There are no rules, there are no thumbs..
  Reinvent the wheel, then learn The Wheel; may be one day you reinvent one of THE WHEELS.

Is there still a page that benchmarks different Perl versions? I haven't seen it since about 5.26 and my Google-Fu doesn't help me finding it.
map{substr$_->[0],$_->[1]||0,1}[\*||{},3],[[]],[ref qr-1,-,-1],[{}],[sub{}^*ARGV,3]

This seems to leave out people who *do* run the latest version of perl.

That very subject was discussed when the poll itself was published back in February.

---

🦛

Question/topic

What's a reasonable 'use VERSION' for new CPAN modules in 2023?

Prologue paragraph

This relates to new CPAN modules only. It excludes modules relying on external code; e.g. to support Unicode 13.0, you'd need Perl 5.32 as a minimum. There are a number of versions from which to select, with potential reasons for doing so; these are just suggestions, "Other" is a perfectly valid choice. If you think coding to a preset VERSION is not a good idea, choose "Dynamic".

One or more choices

• 5.003 (Camel Book 2nd Edition)
• 5.6 (Camel Book 3rd Edition)
• 5.8 (stable version for >5 years)
• 5.10 (many new features now in common use)
• 5.16 (Camel Book 4th Edition)
• 5.18 (hash overhaul)
• 5.26 (no "." in @INC)
• 5.36 (subroutine signatures)
• Other (discuss in comments)
• Dynamic (no standard; code dictates VERSION)

Updates:

• Added Dynamic — see hippo^#11155547 and jo37^#11155549
• Changed "5.18 (new experimental features)" to "5.18 (hash overhaul)" — as I don't really want to suggest that experimental features are included in CPAN modules. See "perl5180delta: Hash overhaul".

I think I would write the code and then just before publishing run perlver on it and use whatever minimum version that tells me is necessary.

So, perhaps a "whatever minimum version the code itself requires" option would be useful?

---

🦛

I like the idea of a "whatever minimum version the code itself requires" , but perlver doesn't seem to be the right tool. Sadly, it fails on features. Consider:

#!/usr/bin/perl

$_ = [];
my @a = $_->@*;
say "@a";
[download]

   -----------------------------------------  
 | file       | explicit | syntax | external |
 | ----------------------------------------- |
 | perlver.pl | ~        | ~      | n/a      |
 | ----------------------------------------- |
 | Minimum explicit version : ~                             |
 | Minimum syntax version   : ~                             |
 | Minimum version of perl  : v5.4.0 (default)              |
   -----------------------------------------
[download]

say requires v5.10 and 'postderef' requires v5.20. For say, even on more recent versions use feature 'say' is required unless use v5.10 is in effect, while 'postderef' is silently available from v5.24 on.

Greetings,
-jo

$gryYup$d0ylprbpriprrYpkJl2xyl~rzg??P~5lp2hyl0p$

++ Thanks for the suggestion.

I've added "Dynamic" to cover this option; implementation details are intentionally omitted.

— Ken

My just-released CodeGen::Cpppp requires 5.20 because I required lexical subs, and wanted template authors to be able to use sub signatures and 5.20 is the earliest version that supports it. I enable the 'use experimental' for them behind the scenes. I think this is a fairly reasonable target version because it's been out for a long while and there's simply no good way to back-port subroutine signatures if you're advertising them to users of the module.

Meanwhile, most of my modules will continue to be ~5.8 because 5.8 can do most of anything that needs done, sometimes with some shims to work around bugs. I don't *need* to use subroutine signatures for my own benefit, and indeed they sometimes slow down the code a bit so all the more reason to leave them out of modules if the purpose of the module is performance.

I don't see any reason to support before 5.8 because I've not heard of a single person still using one of them. Also before 5.8 doesn't have weakrefs, and I consider those to be mandatory for any language that is based on reference counting.

Edit

Actually, I'm debating moving all my modules to 5.10 so that I can use //. While I can write that as defined $x? $x : ... the // is cleaner and also more performant.

I don't see how this relates to the poll idea.

Did you want a change to the options (or some other aspect of the poll idea)?

If this idea is accepted (and published) as an actual poll, your post looks more like an explanation of your voting choice in that poll.

I read what you wrote several times. Am I missing something?

— Ken

My strongest feeling about the new core object system of 5.38 is:

• Looks great, and I'm already using it
• Looks great, but I'm waiting until it's not experimental
• Needs improved to interoperate with existing object systems
• Needs improved to provide XS-speed accessors
• Needs improved to support Roles that can access the fields
• Needs a type validation system like Moose 'isa' or support Type::Tiny
• Needs my favorite Moo(se) attribute features (lazy-build, triggers, etc)
• You can pry Moo(se) out of my cold dead hands
• I'm perfectly happy with 'bless'
• Objects are an over-hyped fad and we should all be using plain functions

I wish I had thought of this earlier: it could have referred to v5.38.0. So, instead, there's plenty of time for Perl v5.40.0; just put this on hold for 10-11 months.

I've picked the choices based on typical release dates for stable (maintenance) 5.x.0 versions over the last decade or so (as shown in perlhist).

Draft (based on Step 2 of "How do I create a Poll?"):

Question/topic

Perl v5.40.0 release date?

Prologue paragraph

When do you think Perl v5.40.0 will be released (based on the date shown in https://metacpan.org/pod/perl).

One or more choices

• Before May 2024
• 1-15 May 2024
• 16-31 May 2024
• June 2024
• After June 2024
• I predict an exact date (in comment below)
• Won't happen; the next will be v7.0.0
• None of the above

Is it too late to do this with 5.38, or is there something special about 5.40?

It's definitely too late for the "Before May" option for 5.38. :-)
map{substr$_->[0],$_->[1]||0,1}[\*||{},3],[[]],[ref qr-1,-,-1],[{}],[sub{}^*ARGV,3]

G'day Arunbear,

My timestamp on this post is "May 20, 2023 at 08:54 AEST"; yours is probably "May 19, 2023 at 23:54 BST".

If you look in perlhist, you'll see that the most common release date, for v5.x.0 stable releases (x is even), is May or June (in the last decade or so).

Given that the previous 11 development versions (v5.37.1 to v5.37.11) were all released on the 20th of consecutive months, I was half expecting v5.38.0 to be released on 20/5/23 (unless there was a further v5.37.12) on that date. As it turns out, no further versions have been released yet.

In 2023, all of "Before May" and "1-15 May", as well as a fair chunk of "16-31 May", had already gone; hence my "I wish I had thought of this earlier".

So, yes, it's too late for v5.38.0; and, no, there's nothing special about v5.40.0 beyond the not unreasonable expectation that it will be released in 2024, probably around May or June.

— Ken

How anonymous are you?

• I am Anonymous Monk
• I sign in but nobody knows who I really am
• My true identity is known only to a small group of other monks
• Anyone who really wants to know can find out who I am
• My monk name is my real name or address
• I am paco

This poll is inspired by Re^4: RFC: Add profile field "emergency contact" or such like as

• I'm not real and everybody knows.
• I'm not real and nobody knows.
• I'm not real and who knows?

Should animated emojis be allowed in the Monastery?

• Yes, allow them
• No, prohibit them
• Meh, bigger fish to fry
• What fresh hell is this?

• Quickly
• Gradually
• Unpredictably

Problem is that some of these options are not mutually exclusive. I'd check both 'Quickly' and 'Unpredictably' if I could.

I was trying to capture whether there's a pattern to it (the first two options being the patterns), and 'Unpredictably' was the option for "No pattern".

• Deliberately

• Never