Quest starts at:Jan 01, 2023 at 05:00 UTC
Quest ends at:Jan 01, 2024 at 04:59 UTC

This quest has ended

First, read How do I create a Poll?. Then suggest your poll here. Complete ideas are more likely to be used.

Note that links may be used in choices but not in the title.

Replies are listed 'Best First'.
Re: poll ideas quest 2023 (perl version)
by hippo (Archbishop) on Jan 27, 2023 at 16:16 UTC

    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 stuck where Strawberry Perl is


      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)


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

    • because older perls are faster


      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.
Re: poll ideas quest 2023 [Reasonable 'use VERSION' for new CPAN modules]
by kcott (Archbishop) on Nov 10, 2023 at 14:35 UTC
    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)


    — Ken

      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";
        ----------------------------------------- | file | explicit | syntax | external | | ----------------------------------------- | | | ~ | ~ | n/a | | ----------------------------------------- | | Minimum explicit version : ~ | | Minimum syntax version : ~ | | Minimum version of perl : v5.4.0 (default) | -----------------------------------------

        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.



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


      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

Re: poll ideas quest 2023
by NERDVANA (Curate) on Sep 08, 2023 at 23:21 UTC

    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
Re: poll ideas quest 2023 [Perl v5.40.0 release date]
by kcott (Archbishop) on May 19, 2023 at 22:54 UTC

    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?"):

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

    — Ken

      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

Re: poll ideas quest 2023 (Anonymity)
by hippo (Archbishop) on Dec 01, 2023 at 09:54 UTC
      • I'm not real and everybody knows.
      • I'm not real and nobody knows.
      • I'm not real and who knows?
Re: poll ideas quest 2023 (animated emojis)
by hippo (Archbishop) on Oct 21, 2023 at 08:59 UTC

    Should animated emojis be allowed in the Monastery?

    • Yes, allow them
    • No, prohibit them
    • Meh, bigger fish to fry
    • What fresh hell is this?
Re: poll ideas quest 2023 (Falling)
by Arunbear (Prior) on Sep 08, 2023 at 10:55 UTC
    I fall in love ...
    • 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