Mailing List Archive

On Tue, Mar 30, 2021 at 11:15 AM Christian Walde <walde.christian@gmail.com>
wrote:

> The email mentions deprecating and removing of X and opting in a lot
> (which has, as mentioned elsewhere, dubious value).
>
> But one thing i didn't see acknowledged is that for the very determined
> even with explicit versioning there is a thermonuclear option:
>
> $ perl -v
>
> This is perl 13[...]
>
> $ cat test.pl
> print 1;
>
> $ perl test.pl
> This is Perl v13.0.0. Oldest supported version: v7.0.0. Please
> declare version 7 or higher in the first line with: use 7; , stopped at -e
> line 1.
> BEGIN failed--compilation aborted at -e line 1.
>
> Many people will absolutely and utterly hate this, but the point is that
> for the sufficiently determined perl porter this is always possible at any
> point in the future if and when it is determined that deprecation and
> removals actually provide benefits.
>
> This means that nobody needs to worry that requiring versioning also means
> maintaining Perl 5 forever, as that's not a thing.
>

Handling it that way was also my idea when reading through lots of the
current email.
Raku has its version syntax for exactly that reason and they currently
support 6c, 6d and what will eventually become 6e.
As it is quite young they haven't had the need to remove the support for 6c
but that might happen sometimes in the future.

For (larger) applications I don't see a problem with specifying the Perl
version explicitly in each module and testing compatibility when upgrading
to a newer Perl version.
As it's easy to compile your own Perl and containers are a thing you can
package your application in a container with whatever ancient Perl version
it needs and be good.
That's still an unsupported application using an unsupported Perl version
with possible security vulnerabilities then.

For CPAN modules a solution for really long-term support, as in 10+ years,
is way harder to find. But that largely depends on how long Perl (the
interpreter) supports an older version.

What do you think about a dumbed down Perl 5 variant for system scripts,
oneliners, etc. that is used when no version is specified in a package and
which will be supported longer (I don't dare to write 'forever')?

Best regards, Alex

--
> With regards,
> Christian Walde
>

On Tue, 30 Mar 2021 05:07:37 +0200, Ricardo Signes <perl.p5p@rjbs.manxome.org> wrote:

> These second two futures are built with heavy investment in the difference between typing boilerplate and no >boilerplate. We already have a means to say "get the best Perl you can get," and it's something like:
> use v5.32.0; use warnings; use utf8; no feature 'switch';
> use if $USER eq 'rjbs',
> experimental => qw(const_attr declared_refs refaliasing re_strict regex_sets >signatures);
>
> Even that first line is a bunch. Plausibly, it can all be boiled down to "use vX;" with a bit of doing. Then we get into >the space between boilerplate being "use vX" and being nothing.

Another point here i want to see mentioned:

I want future Perls to be as bold as possible. I want Perl v7 to change as much as it humanly can. I want it to be brutal, a sledge hammer. I want it to include every possible default change we can remotely justify. I want it to change so much as to get close to being a new language as the major version bump indicates.

And these aren't thoughts i had on my own, they're condensations of thoughts others had that i agree with.

However, without versioning it can't and in fact the existing proposed plans for unversioned default changes are extremely careful and conservative and in fact do very little at all. Not remotely enough to justify a major version bump. Maybe even to the point that it would be bad PR and in invitation of mockery if Perl bumped a major version with so few and small changes.

These also are thoughts from others that i found myself agreeing with.

Please give us a Perl dialect whose differences matter.

--
With regards,
Christian Walde

On Tue, 30 Mar 2021 11:37:41 +0200, Alexander Hartmaier <alex.hartmaier@gmail.com> wrote:

> Handling it that way was also my idea when reading through lots of the current email.
> Raku has its version syntax for exactly that reason and they currently support 6c, 6d and what will eventually >become 6e.
> As it is quite young they haven't had the need to remove the support for 6c but that might happen sometimes in >the future.

Big mood. You love to see it.

> What do you think about a dumbed down Perl 5 variant for system scripts, oneliners, etc. that is used when no >version is specified in a package and which will be supported longer (I don't dare to write 'forever')?
Something like this?

"Perl v13 includes the tarball for Perl v12.8 and installs it as /usr/bin/perl5-legacy which you can choose to use if you know your code needs that?"

Could work. But that's about the only way i can think of for that, as due to dynamic loading you can't decide before runtime if using "dumbed down variant" is possible, unless you have metadata of some kind, even if it's just "bob said so".

--
With regards,
Christian Walde

On Tue, 30 Mar 2021 07:00:37 +0200, Dan Book <grinnz@gmail.com> wrote:

> Thank you for writing this out. It elaborates the set of considerations that has led me to my conclusions upthread >and elsewhere.
>
> On Mon, Mar 29, 2021 at 11:08 PM Ricardo Signes <perl.p5p@rjbs.manxome.org> wrote:
>>
>> ???? A big question: Does this mean that the benefit to people writing new code is contingent on future changes >>to the defaults being much, much safer than (say) turning on strict? Or just as valuable?
>
> I think this highlights a future-facing problem with the idea of changing defaults as a design, which I have touched >on in other posts. Say we decide it is worth the risk to have strict and warnings by default, through whatever >timeframe or mechanism. That means Perl code written for that version has to be interpreted differently by both >the interpreter and things which are not the interpreter (linting tools, documentation, stack overflow, the humans >reading it). Then we find that something else is "as safe" and "as important" to change in a similar process. Now we >have three versions of the language, three interpreters that operate noticeably differently, and three ways that all of >these things have to read Perl code. This situation (even before we get to three) is in fact a detriment in addition to >a benefit to new users of the language, as almost none of them will be learning exclusively from a clean room of new >code examples. Given the alternative design that avoids
> these problems and makes it clear to all consumers >(machine and otherwise) what is going on, for me there is no choice at all.

I highly agree with this email. All possible plans hurt newbies, just different plans hurt different demographics of newbies.

And i want to highlight it with this:

On Tue, 30 Mar 2021 05:07:37 +0200, Ricardo Signes <perl.p5p@rjbs.manxome.org> wrote:

> People writing new code get benefits from writing "no boilerplate" code. They just start writing, they don't need to >remember the correct invocation, and the documentation shipped with their Perl is written for the common >case being "you are using default Perl, so we never need to show any governing pragmas."

I'm pretty sure most people learning Perl do not do so by going `man perl`, but by googling perl tutorial and pasting the first code examples they find on the internet.

Changing Perl defaults may benefit the newbies who learn via `man perl`, but it breaks the process for newbies learning via Google.

--
With regards,
Christian Walde

On Tue, 30 Mar 2021 08:53:20 +0200
"H.Merijn Brand" <perl5@tux.freedom.nl> wrote:

> I think I am more into perl than an average user, but this happens to
> me too. BUT ...
>
> Having to deal with (a lot) of systems that do not have everything
> installed (by default) on systems that I need to work on, I am by now
> used to do man/perldoc/whatever on my home box in a new xterm instead
> of on the target machine.
>
> There are just too many reasons why some tools are not available on
> machines you work on: disk space, install speed, build deps, whatever.

Another small +1 from me here. I'm perfectly happy with the perl vs.
perl-doc split. I quite like it - it means my small utility machines I
build on compact flash cards don't need to waste that disk space on
manpages we don't need there. If I want docs I can easily install them
- the placeholder `perldoc` binary explains it well enough.

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/

On Tue, 30 Mar 2021 11:40:36 +0200
"Christian Walde" <walde.christian@gmail.com> wrote:

> I want future Perls to be as bold as possible. I want Perl v7 to
> change as much as it humanly can. I want it to be brutal, a sledge
> hammer. I want it to include every possible default change we can
> remotely justify. I want it to change so much as to get close to
> being a new language as the major version bump indicates.
>
> And these aren't thoughts i had on my own, they're condensations of
> thoughts others had that i agree with.
>
> However, without versioning it can't and in fact the existing
> proposed plans for unversioned default changes are extremely careful
> and conservative and in fact do very little at all. Not remotely
> enough to justify a major version bump. Maybe even to the point that
> it would be bad PR and in invitation of mockery if Perl bumped a
> major version with so few and small changes.

+1 to all of this.

I want to introduce lots of new exiting things, all gated by that
single line `use v7`. The more and exciting the features, the more
likely people are to use them, and the less likely we are to be laughed
off the face of hackernews/reddit/etc.. for "is that all you've got?"
of a lackluster, mediocre bump of just "default strict+warnings+say" or
whatever we otherwise do.

At that point we are *so* strongly encouraging any new code to be
written with `use v7` that there is really little to gain by changing
the semantics of any code without it, that we'd be better off leaving
that alone and retaining compatibility of every existing perl script
and CPAN module that currently still works with 5.32.

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/

On 3/30/21 7:17 AM, Paul "LeoNerd" Evans wrote:
> On Tue, 30 Mar 2021 08:53:20 +0200
> "H.Merijn Brand" <perl5@tux.freedom.nl> wrote:
>
>> I think I am more into perl than an average user, but this happens to
>> me too. BUT ...
>>
>> Having to deal with (a lot) of systems that do not have everything
>> installed (by default) on systems that I need to work on, I am by now
>> used to do man/perldoc/whatever on my home box in a new xterm instead
>> of on the target machine.
>>
>> There are just too many reasons why some tools are not available on
>> machines you work on: disk space, install speed, build deps, whatever.
>
> Another small +1 from me here. I'm perfectly happy with the perl vs.
> perl-doc split. I quite like it - it means my small utility machines I
> build on compact flash cards don't need to waste that disk space on
> manpages we don't need there. If I want docs I can easily install them
> - the placeholder `perldoc` binary explains it well enough.
>

Sure, again; fair enough. Let's not lose my original point. It had
nothing to do with docker (or maybe it does also) or documentation
specifically. It was a suggestion to have a community maintained summary
of various operating systems/programming environments and if/how 'perl'
is provided - mainly to see how consistently it is done.

Today I will like put up or shut up in the form of a git repo or gh wiki
page; if it's valuable info, some may help maintain it or file
issues/PRs that its out of date. If not, then not. But I will at least
start it. Thank you!

Cheers,
Brett

On Tue, 30 Mar 2021 16:29:56 +0200, B. Estrade <brett@cpanel.net> wrote:

>
>
> On 3/30/21 7:17 AM, Paul "LeoNerd" Evans wrote:
>> On Tue, 30 Mar 2021 08:53:20 +0200
>> "H.Merijn Brand" <perl5@tux.freedom.nl> wrote:
>>
>>> I think I am more into perl than an average user, but this happens to
>>> me too. BUT ...
>>>
>>> Having to deal with (a lot) of systems that do not have everything
>>> installed (by default) on systems that I need to work on, I am by now
>>> used to do man/perldoc/whatever on my home box in a new xterm instead
>>> of on the target machine.
>>>
>>> There are just too many reasons why some tools are not available on
>>> machines you work on: disk space, install speed, build deps, whatever.
>>
>> Another small +1 from me here. I'm perfectly happy with the perl vs.
>> perl-doc split. I quite like it - it means my small utility machines I
>> build on compact flash cards don't need to waste that disk space on
>> manpages we don't need there. If I want docs I can easily install them
>> - the placeholder `perldoc` binary explains it well enough.
>>
>
> Sure, again; fair enough. Let's not lose my original point. It had
> nothing to do with docker (or maybe it does also) or documentation
> specifically. It was a suggestion to have a community maintained summary
> of various operating systems/programming environments and if/how 'perl'
> is provided - mainly to see how consistently it is done.
>
> Today I will like put up or shut up in the form of a git repo or gh wiki
> page; if it's valuable info, some may help maintain it or file
> issues/PRs that its out of date. If not, then not. But I will at least
> start it. Thank you!

Please also see this related issue about how the current documentation about supported platforms is inconsistent and incoherent. :)

https://github.com/Perl/perl5/issues/18243

--
With regards,
Christian Walde

On 3/30/21 10:26 AM, Christian Walde wrote:
> On Tue, 30 Mar 2021 16:29:56 +0200, B. Estrade <brett@cpanel.net> wrote:
>
>>
>>
>> On 3/30/21 7:17 AM, Paul "LeoNerd" Evans wrote:
>>> On Tue, 30 Mar 2021 08:53:20 +0200
>>> "H.Merijn Brand" <perl5@tux.freedom.nl> wrote:
>>>
>>>> I think I am more into perl than an average user, but this happens to
>>>> me too. BUT ...
>>>>
>>>> Having to deal with (a lot) of systems that do not have everything
>>>> installed (by default) on systems that I need to work on, I am by now
>>>> used to do man/perldoc/whatever on my home box in a new xterm instead
>>>> of on the target machine.
>>>>
>>>> There are just too many reasons why some tools are not available on
>>>> machines you work on: disk space, install speed, build deps, whatever.
>>>
>>> Another small +1 from me here. I'm perfectly happy with the perl vs.
>>> perl-doc split. I quite like it - it means my small utility machines I
>>> build on compact flash cards don't need to waste that disk space on
>>> manpages we don't need there. If I want docs I can easily install them
>>> - the placeholder `perldoc` binary explains it well enough.
>>>
>>
>> Sure, again; fair enough. Let's not lose my original point. It had
>> nothing to do with docker (or maybe it does also) or documentation
>> specifically. It was a suggestion to have a community maintained summary
>> of various operating systems/programming environments and if/how 'perl'
>> is provided - mainly to see how consistently it is done.
>>
>> Today I will like put up or shut up in the form of a git repo or gh wiki
>> page; if it's valuable info, some may help maintain it or file
>> issues/PRs that its out of date. If not, then not. But I will at least
>> start it. Thank you!
>
> Please also see this related issue about how the current documentation
> about supported platforms is inconsistent and incoherent. :)
>
> https://github.com/Perl/perl5/issues/18243
>

Noted Christian; thank you!

Brett

On Tue, Mar 30, 2021 at 5:40 AM Christian Walde <walde.christian@gmail.com>
wrote:

> On Tue, 30 Mar 2021 05:07:37 +0200, Ricardo Signes <
> perl.p5p@rjbs.manxome.org> wrote:
>
> These second two futures are built with heavy investment in the difference
> between typing boilerplate and no boilerplate. We already have a means to
> say "get the best Perl you can get," and it's something like:
>
> use v5.32.0; use warnings; use utf8; no feature 'switch';
> use if $USER eq 'rjbs',
> experimental => qw(const_attr declared_refs refaliasing re_strict regex_sets signatures);
>
>
> Even that first line is a bunch. Plausibly, it can all be boiled down to
> "use vX;" with a bit of doing. Then we get into the space between
> boilerplate being "use vX" and being nothing.
>
>
> Another point here i want to see mentioned:
>
> I want future Perls to be as bold as possible. I want Perl v7 to change as
> much as it humanly can. I want it to be brutal, a sledge hammer. I want it
> to include every possible default change we can remotely justify. I want it
> to change so much as to get close to being a new language as the major
> version bump indicates.
>
> And these aren't thoughts i had on my own, they're condensations of
> thoughts others had that i agree with.
>
> However, without versioning it can't and in fact the existing proposed
> plans for unversioned default changes are extremely careful and
> conservative and in fact do very little at all. Not remotely enough to
> justify a major version bump. Maybe even to the point that it would be bad
> PR and in invitation of mockery if Perl bumped a major version with so few
> and small changes.
>
> These also are thoughts from others that i found myself agreeing with.
>
> Please give us a Perl dialect whose differences matter.
>

Co-signed. This is the overarching theme of my most recent post on the
matter: https://dev.to/grinnz/perl-7-a-modest-proposal-434m

Two particular examples for this point are the 'unicode_strings' and
'signatures' feature. Neither of these have a reasonable path to becoming
default, even if we wanted to, due to the impossibility of distinguishing
whether code was intended to run with or without these features; I don't
think anyone disagrees with this at the moment. But they are also two of
the most important features to provide a modern programming environment.

unicode_strings is more subtle than signatures, perhaps, but makes string
operations consistent rather than dependent on an internal string flag that
users don't and shouldn't interact with, and is one of many steps that can
provide a better unicode programming environment. It is also already
enabled in every feature bundle since v5.12. So promoting a "default"
programming environment without this feature is a step backwards. But
promoting and improving "use v7" brings this and many other great features
in for new code "for free".

-Dan

"Ricardo Signes" <perl.p5p@rjbs.manxome.org> wrote:
:I don't think we've had enough responses, especially from core team
:members [...]

Apologies for that, for some reason I didn't imagine this was aimed at us.

I signed up to Sawyer's original plan, and continue to believe a) that
change is good and necessary, and b) that we have the collective will
and intelligence to minimize the downside to a level that the vast
majority of people would find acceptable.

I tend to write to whatever the default perl is, so I'm unlikely to make
use of any of the new features (past or future) unless they get turned on
by default one day in some perl release.

Hugo

On Tue, Mar 30, 2021, at 3:54 AM, Christian Walde wrote:
> On Tue, 30 Mar 2021 05:07:37 +0200, Ricardo Signes <perl.p5p@rjbs.manxome.org> wrote:
>> * This one I think I can only state as a trade-off per se: Spending time on maintaining long-discouraged behaviors is good only to the extent that they can't be deprecated and removed instead. How do we know whether we can deprecate and remove some behavior? Well, that's largely a function of all of the above.
> Have more reading and thinking to do, but:
>
> As far as i am informed this one is a red herring.

I think that *usually* when "if only we could remove X, things would be simpler" is incorrect. The common whipping boy here is formats. "Why can't we get rid of formats??" people cry. "They're just taking up space!"

Well, in reality, deleting formats would not be such a big win. Except, maybe, to reclaim the syntax that their special punctuation variables occupy. LeoNerd was talking about (or possibly implemented?) a means to hide those variables away to free up the syntax. Very nice!

On the other hand, there are some places that the complexity is present, and my assertion (which I'm happy to see challenged) is that the more interesting places to remove it are those where it's most difficult to remove in a safe way. unicode_strings is one example.

At any rate: I agree that "allow us to eject troublesome parts of the implementation" is not the major driving force for changing defaults in any way currently being floated.

--
rjbs

On Sat, Mar 27, 2021, at 5:31 PM, Dan Book wrote:
> In my opinion, none of these are reasonably doable as it stands currently, aside from deprecating the behavior that they would change.
> […]
> *fc: adds the fc keyword, both useful and risky
>
> *say: useful and very risky
> *state: useful and very risky

Dan,

I meant to send this immediately and forgot and then suddenly I remembered.

I think there are risks here — specific ones. But I wondered whether we are thinking about the same risks. Could you elaborate on what risks you have in mind when you say these are "risky"? Thanks!

--
rjbs

On Tue, Mar 30, 2021 at 9:44 PM Ricardo Signes <perl.p5p@rjbs.manxome.org>
wrote:

> On Sat, Mar 27, 2021, at 5:31 PM, Dan Book wrote:
>
> In my opinion, none of these are reasonably doable as it stands currently,
> aside from deprecating the behavior that they would change.
> […]
> *fc: adds the fc keyword, both useful and risky
>
> *say: useful and very risky
> *state: useful and very risky
>
>
> Dan,
>
> I meant to send this immediately and forgot and then suddenly I remembered.
>
> I think there are risks here — specific ones. But I wondered whether we
> are thinking about the same risks. Could you elaborate on what risks you
> have in mind when you say these are "risky"? Thanks!
>

Specifically, that these are very common words that are likely to already
exist as keywords in codebases in the wild.

-Dan

On Wed, 31 Mar 2021 03:26:45 +0200, Ricardo Signes <perl.p5p@rjbs.manxome.org> wrote:

> On Tue, Mar 30, 2021, at 3:54 AM, Christian Walde wrote:
>> On Tue, 30 Mar 2021 05:07:37 +0200, Ricardo Signes <perl.p5p@rjbs.manxome.org> wrote:
>>> This one I think I can only state as a trade-off per se: Spending time on maintaining long->>>discouraged behaviors is good only to the extent that they can't be deprecated and >>>removed instead. How do we know whether we can deprecate and remove some >>>behavior? Well, that's largely a function of all of the above.
>> Have more reading and thinking to do, but:
>>
>> As far as i am informed this one is a red herring.
>
> I think that usually when "if only we could remove X, things would be simpler" is incorrect. The common >whipping boy here is formats. "Why can't we get rid of formats??" people cry. "They're just taking up space!"
>
> Well, in reality, deleting formats would not be such a big win. Except, maybe, to reclaim the syntax that their >special punctuation variables occupy. LeoNerd was talking about (or possibly implemented?) a means to hide >those variables away to free up the syntax. Very nice!
>
> On the other hand, there are some places that the complexity is present, and my assertion (which I'm happy to >see challenged) is that the more interesting places to remove it are those where it's most difficult to remove in a >safe way. unicode_strings is one example.

Agreed on all of that.

> At any rate: I agree that "allow us to eject troublesome parts of the implementation" is not the major driving >force for changing defaults in any way currently being floated.

I don't think this is entirely accurate.

I've seen several people speak in ways that make me think that one of the reasons they want unversioned default changes is because they believe it makes this possible and they consider it a good thing. When detailing counter-proposals I ran into objections of "but wouldn't that mean supporting Perl 5 forever?!" and similar comments that indicate people believe that removing things is a necessary step towards getting good things.

Thus, i think the contradiction and the truth values of various things here ought to be inspected very explicitly and such notions confirmed with specificity, or dismantled as appropriate.

--
With regards,
Christian Walde

On Tue, 30 Mar 2021 21:26:45 -0400
"Ricardo Signes" <perl.p5p@rjbs.manxome.org> wrote:

> Well, in reality, deleting formats would not be such a big win.
> Except, maybe, to reclaim the syntax that their special punctuation
> variables occupy. LeoNerd was talking about (or possibly
> implemented?) a means to hide those variables away to free up the
> syntax. Very nice!

I haven't yet, no.

But this reminds me - I shall probably begin work on that this week.

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/

No, I didn't fall off the list! Between some non-Perl obligations and waiting on talking to the rest of the steering council, this email has been waiting to get written. (Also, I allowed myself to enjoy the long weekend a little!)

In my last long email, I was writing about the conflicts between:
* wanting it to be easy to have "the best perl" to write in
* wanting your existing, working code to keep on running without edits
…and other related tensions.

One thing that we talk about a lot is "use vX". The idea behind "use vX" is that it gives you a one-stop shop to say "give me the best set of defaults [according to p5p consensus]", and that this set of defaults can be left intact indefinitely so that ten years down the line, a program that said "use v5.12.0" can still run with largely unaltered behavior. I say "largely" unaltered, because we have altered it. The use of `qw(...)` as if it was `(qw(...))` was deprecated and removed, for example. This allowed for simplification of the language implementation, and we could do it even though using "qw" in this way was never guarded by a named "feature". We warned that the feature was going, then we deleted it and smoothed out some wrinkly code.

The same thing could be done again for, say, indirect object syntax. When encountered, perl could begin warning now, and then in a few years, it could be fatal. In theory, this could simplify the grammar. I think that this mechanism (deprecate, then remove) is *orthogonal* to the addition of feature guards. Being able to lexically disable indirect object syntax is a help to programmers who know they will never *want* to use it. It is not a direct path to removing the feature — but it can be helpful on that front. That is, as more people disable indirect syntax by default, the idea of removing it becomes more palatable.

So this may be an accurate set of statements about how we've done things so far:
* 1: We make new behaviors opt-in when they would break existing code if on by default.
* 2: We make new behaviors on by default if they could not appear in existing, working code.
* 3: We remove behaviors when they are making the language implementation harder to work on *and* cause only acceptable amounts of inconvenience.
* 4: When a behavior is going to be removed, it first issues a deprecation "this is being removed!" warning for several versions.
* 5: We make old "bad" behaviors lexically optional when we think people will (or should) want to turn them off by default in new code. (I would argue that this is exactly what "use strict" did in v5.0.)
* 6: We bundle all the options (both opt in and opt out) in "use vX" to make it easy to get them all.

I think some of the discussion of new defaults and future perl changes have also had these things in mind:
* 7: We will alter the default opting in or out of behaviors over time, so that the starting position is closer to the ideal.
* 8: When a default behavior is going to be changed, encountering the behavior when no opt in/out has been explicitly performed, a warning is issued, giving the user a nudge to either add a "use feature" or to update their code.

Item 6 is built on the idea that writing a bunch of boilerplate is bad, and writing close to zero is better. Item 7 says "zero is better than nearly zero." But it *also* says "just adding vX to my code is a bridge too far."

That is: "I want all my code to have strict, warnings, no indirect object syntax. I believe any violation of this is a bug on my part, and I want it applied everywhere." Turning on "use strict; use warnings; no feature 'indirect'" everywhere gets exactly that. Saying "use vX will turn all that on [.and a bunch of other stuff you don't know how to evaluate]" is not necessarily a big win. If an organization wants to have a standard boilerplate, and users see "we run perl-5.20, but use v5.20 turns on unicode strings, and I don't know what that does to my existing code, but I know that it sounds scary", then they are not likely to add it to their old code. And once it's not in their old code, will it become standard in their new code?

I think that item 7, above, is (in part!) built on this concern. "Users are never going to go back and add one of our big omnibus feature bundles. We can't possibly turn all that stuff on without their opting in. On the other hand, we can guarantee that every program running meets these minimal criteria with zero edits to the source by just changing those defaults. Only already-bad code will be broken."

There are a few assumptions built into that. Most often objected to: the assertion that code that does not say "no strict" and then violates strictures is bad. But other points worth considering: "users don't want to use vX because they don't know what it does" and "users don't want to add use vX to old code [for the same reason]" and "I want to know that all my code follows the same rules out of the gate without chasing up any set of use statements everywhere."

And built into *that* is the question of "my code". Is that "all the code we run" or "all the code we run *that we wrote*."

*Anyway:* I'm not going to address all of that now and act like I have an answer that will please everyone. I do think it's at least a bunch of the "new defaults" argument broken down into pieces.

My question is more like this: We assume that "just start all code with use vX" is workable for new code. What can we do to encourage users to feel good about how they take their existing, running code and get it up closer to "the best perl we know" options? Here, I'm assuming that there's a lower cost of ownership to your code if you can know that all your code can be skimmed the same way, because it's got the same set of options. But you now want to take your older code and stick the same use vX at the top as you have in your new code. How do we help users feel confident in staying up to date with the "use vX" of their current perl-X?

--
rjbs

On Sat, Apr 3, 2021 at 11:08 PM Ricardo Signes <perl.p5p@rjbs.manxome.org>
wrote:

>
> "users don't want to use vX because they don't know what it does"
>

This seems like a non-concern to me unless there is evidence people
commonly make this decision - in my experience, it's more often
specifically because "use warnings" is not included. People use Mojo::Base
with no qualms, even if they may not know everything it does (it does a
lot, and what it does is well documented), but because they want its
benefits. Major versions give us a platform to list out the benefits of
such a declaration in an easily referenced manner.


> "users don't want to add use vX to old code [for the same reason]"
>

This is a different concern, and in my opinion a good one. We cannot
provide both a good environment for new code and a good environment for
existing unreviewed code at the same time. We must choose.


> "I want to know that all my code follows the same rules out of the gate
> without chasing up any set of use statements everywhere."
>

Better to have use statements declare such rules than have them invisibly
applied by the environment.


> And built into *that* is the question of "my code". Is that "all the
> code we run" or "all the code we run *that we wrote*."
>

Lexical declarations make this distinction trivial.


>
> *Anyway:* I'm not going to address all of that now and act like I have
> an answer that will please everyone. I do think it's at least a bunch of
> the "new defaults" argument broken down into pieces.
>
> My question is more like this: We assume that "just start all code with
> use vX" is workable for new code. What can we do to encourage users to
> feel good about how they take their existing, running code and get it up
> closer to "the best perl we know" options? Here, I'm assuming that there's
> a lower cost of ownership to your code if you can know that all your code
> can be skimmed the same way, because it's got the same set of options. But
> you now want to take your older code and stick the same use vX at the top
> as you have in your new code. How do we help users feel confident in
> staying up to date with the "use vX" of their current perl-X?
>

Provide guidance and good documentation, publicize the new bundle well, and
accept that some code is better off without it.

-Dan

Personally, why not use the following syntax

use v5.26;
use v5.28;
use v5.30;
use v5.32;

1. that don't include warnings program.

2. The features introduced in the minor version are hard to understand. It
feels like a feature that early adopters try.


2021?4?4?(?) 12:08 Ricardo Signes <perl.p5p@rjbs.manxome.org>:

> No, I didn't fall off the list! Between some non-Perl obligations and
> waiting on talking to the rest of the steering council, this email has been
> waiting to get written. (Also, I allowed myself to enjoy the long weekend
> a little!)
>
> In my last long email, I was writing about the conflicts between:
>
> - wanting it to be easy to have "the best perl" to write in
> - wanting your existing, working code to keep on running without edits
>
> …and other related tensions.
>
> One thing that we talk about a lot is "use vX". The idea behind "use vX"
> is that it gives you a one-stop shop to say "give me the best set of
> defaults [according to p5p consensus]", and that this set of defaults can
> be left intact indefinitely so that ten years down the line, a program that
> said "use v5.12.0" can still run with largely unaltered behavior. I say
> "largely" unaltered, because we have altered it. The use of qw(...) as
> if it was (qw(...)) was deprecated and removed, for example. This
> allowed for simplification of the language implementation, and we could do
> it even though using "qw" in this way was never guarded by a named
> "feature". We warned that the feature was going, then we deleted it and
> smoothed out some wrinkly code.
>
> The same thing could be done again for, say, indirect object syntax. When
> encountered, perl could begin warning now, and then in a few years, it
> could be fatal. In theory, this could simplify the grammar. I think that
> this mechanism (deprecate, then remove) is *orthogonal* to the addition
> of feature guards. Being able to lexically disable indirect object syntax
> is a help to programmers who know they will never *want* to use it. It
> is not a direct path to removing the feature — but it can be helpful on
> that front. That is, as more people disable indirect syntax by default,
> the idea of removing it becomes more palatable.
>
> So this may be an accurate set of statements about how we've done things
> so far:
>
> - 1: We make new behaviors opt-in when they would break existing code
> if on by default.
> - 2: We make new behaviors on by default if they could not appear in
> existing, working code.
> - 3: We remove behaviors when they are making the language
> implementation harder to work on *and* cause only acceptable amounts
> of inconvenience.
> - 4: When a behavior is going to be removed, it first issues a
> deprecation "this is being removed!" warning for several versions.
> - 5: We make old "bad" behaviors lexically optional when we think
> people will (or should) want to turn them off by default in new code. (I
> would argue that this is exactly what "use strict" did in v5.0.)
> - 6: We bundle all the options (both opt in and opt out) in "use vX"
> to make it easy to get them all.
>
>
> I think some of the discussion of new defaults and future perl changes
> have also had these things in mind:
>
> - 7: We will alter the default opting in or out of behaviors over
> time, so that the starting position is closer to the ideal.
> - 8: When a default behavior is going to be changed, encountering the
> behavior when no opt in/out has been explicitly performed, a warning is
> issued, giving the user a nudge to either add a "use feature" or to update
> their code.
>
>
> Item 6 is built on the idea that writing a bunch of boilerplate is bad,
> and writing close to zero is better. Item 7 says "zero is better than
> nearly zero." But it *also* says "just adding vX to my code is a bridge
> too far."
>
> That is: "I want all my code to have strict, warnings, no indirect object
> syntax. I believe any violation of this is a bug on my part, and I want it
> applied everywhere." Turning on "use strict; use warnings; no feature
> 'indirect'" everywhere gets exactly that. Saying "use vX will turn all
> that on [.and a bunch of other stuff you don't know how to evaluate]" is not
> necessarily a big win. If an organization wants to have a standard
> boilerplate, and users see "we run perl-5.20, but use v5.20 turns on
> unicode strings, and I don't know what that does to my existing code, but I
> know that it sounds scary", then they are not likely to add it to their old
> code. And once it's not in their old code, will it become standard in
> their new code?
>
> I think that item 7, above, is (in part!) built on this concern. "Users
> are never going to go back and add one of our big omnibus feature bundles.
> We can't possibly turn all that stuff on without their opting in. On the
> other hand, we can guarantee that every program running meets these minimal
> criteria with zero edits to the source by just changing those defaults.
> Only already-bad code will be broken."
>
> There are a few assumptions built into that. Most often objected to: the
> assertion that code that does not say "no strict" and then violates
> strictures is bad. But other points worth considering: "users don't want
> to use vX because they don't know what it does" and "users don't want to
> add use vX to old code [for the same reason]" and "I want to know that all
> my code follows the same rules out of the gate without chasing up any set
> of use statements everywhere."
>
> And built into *that* is the question of "my code". Is that "all the
> code we run" or "all the code we run *that we wrote*."
>
> *Anyway:* I'm not going to address all of that now and act like I have
> an answer that will please everyone. I do think it's at least a bunch of
> the "new defaults" argument broken down into pieces.
>
> My question is more like this: We assume that "just start all code with
> use vX" is workable for new code. What can we do to encourage users to
> feel good about how they take their existing, running code and get it up
> closer to "the best perl we know" options? Here, I'm assuming that there's
> a lower cost of ownership to your code if you can know that all your code
> can be skimmed the same way, because it's got the same set of options. But
> you now want to take your older code and stick the same use vX at the top
> as you have in your new code. How do we help users feel confident in
> staying up to date with the "use vX" of their current perl-X?
>
> --
> rjbs
>

On Sun, Apr 4, 2021, at 7:58 PM, Yuki Kimoto wrote:
> Personally, why not use the following syntax
>
> use v5.26;
> use v5.28;
> use v5.30;
> use v5.32;
>
> 1. that don't include warnings program.
>
> 2. The features introduced in the minor version are hard to understand. It feels like a feature that early adopters try.

I don't understand what you mean, especially by point #2.

--
rjbs

On 2021-04-03 8:07 p.m., Ricardo Signes wrote:
> I think that item 7, above, is (in part!) built on this concern.  "Users are
> never going to go back and add one of our big omnibus feature bundles.

The solution here is the same as with many other things, users do it gradually.

When users are going back to old code, they start by doing what would be a
minimal delta for them, and move forward small steps at a time, rather than
jumping to the end all at once.

So that means for example, all files without a "use vX;" add the boilerplate
"use 5.0;", and they make sure everything works, and then they iterate, 5.2,
5.4, and so on, up to whatever interpreter version they're using.

So that way, it isn't an omnibus at all, because each next X only added very few
things over the previous X, and the devs familiarize with and test with each X
value one at a time, and they move up as they're comfortable.

I don't see why this process can't be a very effective solution.

-- Darren Duncan

On Sun, Apr 4, 2021, at 5:58 PM, Dan Book wrote:
> On Sat, Apr 3, 2021 at 11:08 PM Ricardo Signes <perl.p5p@rjbs.manxome.org> wrote:
>>
>> "users don't want to use vX because they don't know what it does"
>
> This seems like a non-concern to me unless there is evidence people commonly make this decision - in my experience, it's more often specifically because "use warnings" is not included. People use Mojo::Base with no qualms, even if they may not know everything it does (it does a lot, and what it does is well documented), but because they want its benefits. Major versions give us a platform to list out the benefits of such a declaration in an easily referenced manner.

So, I called that line out because it was originally given to me as significant component of how changing the out-of-the-box behavior of perl would be of benefit. I think it's something like this:
* having to add boilerplate to get the best practical Perl language is bad
* having a large corpus of Perl code with different boilerplates is bad
* when you find you have code that doesn't have "house standard boilerplate", you want to be able to add it safely
In some conversations recently, I found myself saying, "The thing is, Perl isn't C. When we ship a new compiler, it's all the programs are recompiled before their next run, whether or not you're looking when it happens." This is (in my mind) a good reason to minimize the breakage shipped out with a new compiler.

It also influences the decision of what can go in standard boilerplate. If boilerplate may be added later, adding "use v5.30" starting from nothing is a nightmare. If the behavior is a runtime exception (use strict refs) or runtime behavior change (use feature unicode_strings) it's not "obviously safe."

I can imagine an "adds compile-time failures only" boilerplate that would be safe to add freely. You'd add it to your code, run "perl -c", and know you're now in line with house practices.

If we further imagine that "notice that boilerplate is present" is too much to ask, then I think we reach a big part of the "change the defaults by adding the 'obviously needed' stuff, but not the less safe changes." I think in this scenario, the way one would change defaults would be to turn on more compile-time warnings, to turn on compile-time strictures, to disable compile-time-detectable syntax, and so on and, further, to do it by changing the default language.

A big problem, though, is that this isn't a safe change for code already out in production. It requires a "compile test all code with new perl" before you install the new perl. But so does any upgrade of perl, in theory. It's just that in practice, we're used to surprise breakage being pretty small.

At any rate, where this train of thought led me was: imagine a pragma, which I'll call "xyz", that works like this:
use xyz ':5.34';
# enables strict vars, compile time warnings
# disables indirect, bareword filehandles, etc.

Setting this up "everywhere" in sitecustomize would "safely" let you lift up the baseline expectations. But it gets at the question I asked — do you want to affect only the code you *wrote* or *all the code you run* (including CPAN code). I would presume that for most people the answer is "the code you wrote." Otherwise you're stuck trying to edit code that comes from upstream for very unclear benefit.

That means your sitecustomize will have to distinguish between your code and external dependencies, which gets us to this:

>> "I want to know that all my code follows the same rules out of the gate without chasing up any set of use statements everywhere."
>
> Better to have use statements declare such rules than have them invisibly applied by the environment.

If the user believes that absolutely *all* of their code should have the same rules, then *eliminating *use statements to reach the preferred base state is the way to get there… but if it isn't totally universal, then now there are (at least) two distinct sets of baseline languages at play, and by definition you can't look at the source code and know which one you get.

That's where, I think, we get to rules being applied invisibly, as you say!

So we throw that rule out, we accept the need to push changes back out into the CPAN, and we arrive at "to ensure that all code can assume a better common Perl, we should change the defaults for all code to add a compile-time-checkable subset of behavior changes that make the language better, then work to lift up the whole existing corpus of existing code to meet those guidelines."

I think the primary objection to this tactic is "the amount of work required to make existing public code work under these new rules is large, and then there's the work required to make existing unpublished code work; meanwhile, the code was working, and the benefit pales in comparison to what would be available by adding a more comprehensive set of pragmas."


>> *Anyway:* I'm not going to address all of that now and act like I have an answer that will please everyone. I do think it's at least a bunch of the "new defaults" argument broken down into pieces.
>>
>> My question is more like this: We assume that "just start all code with use vX" is workable for new code. What can we do to encourage users to feel good about how they take their existing, running code and get it up closer to "the best perl we know" options? Here, I'm assuming that there's a lower cost of ownership to your code if you can know that all your code can be skimmed the same way, because it's got the same set of options. But you now want to take your older code and stick the same use vX at the top as you have in your new code. How do we help users feel confident in staying up to date with the "use vX" of their current perl-X?
>
> Provide guidance and good documentation, publicize the new bundle well, and accept that some code is better off without it.

I think that's a big part of it, and will try to write more about specifics. But not tonight! Maybe tomorrow, but I might spend the day loafing and reading. We'll see how I feel in 12 hours…

--
rjbs

On Mon, 5 Apr 2021 08:58:07 +0900
Yuki Kimoto <kimoto.yuki@gmail.com> wrote:

> Personally, why not use the following syntax
>
> use v5.26;
> use v5.28;
> use v5.30;
> use v5.32;
>
> 1. that don't include warnings program.

Good news - we have a PR in progress that will add `use warnings` to
those things.

https://github.com/Perl/perl5/pull/18666

> 2. The features introduced in the minor version are hard to
> understand. It feels like a feature that early adopters try.

Again good news - with the new influx of more exciting features already
in 5.3x (isa, try/catch), and a whole raft of new things I want to be
getting into a state where they're ready for a 7 (match/case, equ, in,
an object system), that means that

use v7;

will be quite a bit more of a jump change up from 5, to the point that
it is a meaningful difference on the language.

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/

rjbs

----------
On Sun, Apr 4, 2021, at 7:58 PM, Yuki Kimoto wrote:

Personally, why not use the following syntax

use v5.26;
use v5.28;
use v5.30;
use v5.32;

1. that don't include warnings program.

2. The features introduced in the minor version are hard to understand. It
feels like a feature that early adopters try.


I don't understand what you mean, especially by point #2.
------------

Suppose I am a beginner.

I can't understand the difference between "use v5.26" and "use v5.32".

This is because the unit for minor releases is too small.

If it is "use v7;", I can understand the features by reading only one page
that explains it.


2021?4?5?(?) 9:30 Ricardo Signes <perl.p5p@rjbs.manxome.org>:

> On Sun, Apr 4, 2021, at 7:58 PM, Yuki Kimoto wrote:
>
> Personally, why not use the following syntax
>
> use v5.26;
> use v5.28;
> use v5.30;
> use v5.32;
>
> 1. that don't include warnings program.
>
> 2. The features introduced in the minor version are hard to understand. It
> feels like a feature that early adopters try.
>
>
> I don't understand what you mean, especially by point #2.
>
> --
> rjbs
>

Paul

> Good news - we have a PR in progress that will add `use warnings` to
those things.

Thank you.

2021?4?5?(?) 20:39 Paul "LeoNerd" Evans <leonerd@leonerd.org.uk>:

> On Mon, 5 Apr 2021 08:58:07 +0900
> Yuki Kimoto <kimoto.yuki@gmail.com> wrote:
>
> > Personally, why not use the following syntax
> >
> > use v5.26;
> > use v5.28;
> > use v5.30;
> > use v5.32;
> >
> > 1. that don't include warnings program.
>
> Good news - we have a PR in progress that will add `use warnings` to
> those things.
>
> https://github.com/Perl/perl5/pull/18666
>
> > 2. The features introduced in the minor version are hard to
> > understand. It feels like a feature that early adopters try.
>
> Again good news - with the new influx of more exciting features already
> in 5.3x (isa, try/catch), and a whole raft of new things I want to be
> getting into a state where they're ready for a 7 (match/case, equ, in,
> an object system), that means that
>
> use v7;
>
> will be quite a bit more of a jump change up from 5, to the point that
> it is a meaningful difference on the language.
>
> --
> Paul "LeoNerd" Evans
>
> leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
> http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/
>