Mailing List Archive

On Sat, Mar 27, 2021 at 4:49 PM Ricardo Signes <perl.p5p@rjbs.manxome.org>
wrote:

> So I think, after saying all this, the first big question is: Is there a
> general agreement that there are kinds of changes we've made (or will make)
> to the language that we can ease into making the default, through some
> multi-step process? We may need to hash out individual changes' paths
> forward, but if there is an overwhelming opposition to changing these sorts
> of defaults *at all*, then I think a lot of this conversation has to be
> entirely reconsidered.
>

I am not opposed to considering what a path may be for a specific feature,
but I do not believe it is worth the cost for any of the currently existing
features.

-Dan

On Sat, Mar 27, 2021 at 4:49 PM Ricardo Signes <perl.p5p@rjbs.manxome.org>
wrote:

> $* is a nice example because it's connected to so many changes, but it's
> not the only place we've changed defaults, either to deprecate things, to
> remove deprecated things, or to just change behavior. (For example, the
> meaning of "scalar %hash" changed between v5.24 and v5.26.) Some of these
> changes change runtime behavior of the code, some change the legal syntax
> of Perl. The "only perl can parse Perl" rule will apply to these in
> different amounts.
>

They are nice examples for specific instances, but they each have their own
unique circumstances and aren't great for informing a "general case" of any
sort.

$* was used by almost nobody while it existed, for its part.

scalar %hash was already a weird return value, so even code that used it
rarely cared what it actually contained.

The current feature bundle contains: bitwise, current_sub, evalbytes, fc,
> indirect, postderef_qq, say, state, switch (good grief), unicode_eval, and
> unicode_strings. I think some of these are things that should become
> default parts of the language. It's helpful to people who write code to a
> recent version of perl only. It makes it possible to eventually make the
> feature always-on.
>

We can split the features into roughly two categories: features that change
the meaning of existing constructs, and features that add new keywords
(which could clash with custom subs or keywords).

Changing behavior:
*bitwise: splits "smart" bitwise operators into two sets, potential to
break any code using these operators, difficult to determine if it has been
broken
*indirect: we'd want to remove this, it's already default; but doing so
would break a lot of existing code and the nature of the parser change
makes it difficult to warn nicely about
*unicode_eval: changes the behavior of string eval to make it more
consistent, but existing string evals could be relying on the inconsistent
interpretation
*unicode_strings: similar to unicode_eval but much more wide reaching risk
for a variety of string operations
*postderef_qq: would break currently valid strings
In my opinion, none of these are reasonably doable as it stands currently,
aside from deprecating the behavior that they would change.

New keywords:
*current_sub: probably the lowest risk/highest reward of the features, use
of the token __SUB__ outside of this feature is unlikely, but possible
*evalbytes: adds the evalbytes keyword, low risk but not commonly used
anyway
*fc: adds the fc keyword, both useful and risky
*say: useful and very risky
*state: useful and very risky

-Dan

On Sat, Mar 27, 2021 at 5:31 PM Dan Book <grinnz@gmail.com> wrote:

> On Sat, Mar 27, 2021 at 4:49 PM Ricardo Signes <perl.p5p@rjbs.manxome.org>
> wrote:
>
>> $* is a nice example because it's connected to so many changes, but it's
>> not the only place we've changed defaults, either to deprecate things, to
>> remove deprecated things, or to just change behavior. (For example, the
>> meaning of "scalar %hash" changed between v5.24 and v5.26.) Some of these
>> changes change runtime behavior of the code, some change the legal syntax
>> of Perl. The "only perl can parse Perl" rule will apply to these in
>> different amounts.
>>
>
> They are nice examples for specific instances, but they each have their
> own unique circumstances and aren't great for informing a "general case" of
> any sort.
>
> $* was used by almost nobody while it existed, for its part.
>
> scalar %hash was already a weird return value, so even code that used it
> rarely cared what it actually contained.
>
> The current feature bundle contains: bitwise, current_sub, evalbytes, fc,
>> indirect, postderef_qq, say, state, switch (good grief), unicode_eval, and
>> unicode_strings. I think some of these are things that should become
>> default parts of the language. It's helpful to people who write code to a
>> recent version of perl only. It makes it possible to eventually make the
>> feature always-on.
>>
>
> We can split the features into roughly two categories: features that
> change the meaning of existing constructs, and features that add new
> keywords (which could clash with custom subs or keywords).
>
> Changing behavior:
> *bitwise: splits "smart" bitwise operators into two sets, potential to
> break any code using these operators, difficult to determine if it has been
> broken
> *indirect: we'd want to remove this, it's already default; but doing so
> would break a lot of existing code and the nature of the parser change
> makes it difficult to warn nicely about
> *unicode_eval: changes the behavior of string eval to make it more
> consistent, but existing string evals could be relying on the inconsistent
> interpretation
> *unicode_strings: similar to unicode_eval but much more wide reaching risk
> for a variety of string operations
> *postderef_qq: would break currently valid strings
> In my opinion, none of these are reasonably doable as it stands currently,
> aside from deprecating the behavior that they would change.
>
> New keywords:
> *current_sub: probably the lowest risk/highest reward of the features, use
> of the token __SUB__ outside of this feature is unlikely, but possible
> *evalbytes: adds the evalbytes keyword, low risk but not commonly used
> anyway
> *fc: adds the fc keyword, both useful and risky
> *say: useful and very risky
> *state: useful and very risky
>

And to add to this a few things which are not features but have been
considered for the same honor:

*strict: Breaks working code. I don't see a reasonable path to make this
happen aside from deprecating all non-strict syntax for strict 'subs' and
'vars', but strict 'refs' operates at runtime.
*warnings: Well, warnings are an interesting case. They are already enabled
by default, just only certain ones we decided were worth doing that for. I
suggest reading through https://perldoc.perl.org/perldiag if you aren't
familiar with the organization of Perl warnings. Instead of a blanket "make
all warnings default" maybe we should be considering if some of the ones
that aren't should be moved there.
*utf8: A path for this was outlined by Zefram (
https://www.nntp.perl.org/group/perl.perl5.porters/2017/10/msg246838.html)
and roughly requires a deprecation period for non-ascii bytes in source
code outside of "use utf8".

-Dan

On Sat, Mar 27, 2021 at 05:31:53PM -0400, Dan Book wrote:
> On Sat, Mar 27, 2021 at 4:49 PM Ricardo Signes <perl.p5p@rjbs.manxome.org>
> wrote:
>
> > $* is a nice example because it's connected to so many changes, but it's
> > not the only place we've changed defaults, either to deprecate things, to
> > remove deprecated things, or to just change behavior. (For example, the
> > meaning of "scalar %hash" changed between v5.24 and v5.26.) Some of these
> > changes change runtime behavior of the code, some change the legal syntax
> > of Perl. The "only perl can parse Perl" rule will apply to these in
> > different amounts.
> >
>
> They are nice examples for specific instances, but they each have their own
> unique circumstances and aren't great for informing a "general case" of any
> sort.
>
> $* was used by almost nobody while it existed, for its part.

Your mileage may vary. I *still* have stuff with $*=1 that I haven't converted.

--
Andy Dougherty doughera@lafayette.edu

On Sat, 27 Mar 2021 at 21:49, Ricardo Signes <perl.p5p@rjbs.manxome.org> wrote:
>
> So I think, after saying all this, the first big question is: Is there a general agreement that there are kinds of changes we've made (or will make) to the language that we can ease into making the default, through some multi-step process?

I don't think that question is very worthwhile. We obviously can. We
have done so. The question is: Should we?

And specifically: Should we break people's stuff because we disagree
with how they use Perl?

As i told you in the private convo:

The postfix-deref defaulting isn't a huge issue. I don't think i said
clearly that this is primarily because introducing it broke nothing
that reasonably affected anyone.

However as i also told you: It IS AN ISSUE. If it had not happened and
postfix-deref were version-gated we could have Perl::Critic policies
that verify people are applying it correctly. Now we can't. It broke
something.

And to lead back to the 7.0 plan:

Making strict default isn't something that breaks nothing that
reasonably affects anyone.

Making strict default is VERY EXPLICITLY intended to break people's
stuff and force them into action. And worse, you institute a policy of
introducing changes without versioning on major versions. This is a
promise that you'll break stuff that can NEVER BE FIXED. You break
IDEs, syntax highlighters, static analysers of all kinds by creating a
new untagged dialect with EVERY FUCKING MAJOR RELEASE if you follow
the plan you laid out.

If you want to do it the very first thing you MUST ADMIT is that
you're breaking something, whose stuff you're breaking and how you're
hurting them and how they're likely to react and whether that reaction
is worth it.

Seriously, this is actually making me incredibly angry at this point.
I STILL, despite having asked REPEATEDLY, don't know: Do y'all even
know how much you're breaking and if you don't care, or do you not
even know?

Is it so much to ask for that being acknowledged clearly and without
any sort of indirection or flowery language or whatever the fuck?

Can't y'all just say "Actually i don't think it breaks XYZ."
or "It breaks XYZ and this is good."?

It's been almost a year.

I'm utterly and completely sick of asking and never getting replies or
getting stuff in return that just leads multiple layers of indirection
astray.

Christian,

While there are specific points in your email I’d like to respond to, the bigger issue is your tone and language.

That is not how members of a community talk to each other. Please acknowledge that and apologise to Rik, and the list.

Neil

On Sat, 27 Mar 2021 17:31:53 -0400
Dan Book <grinnz@gmail.com> wrote:

> We can split the features into roughly two categories: features that
> change the meaning of existing constructs, and features that add new
> keywords (which could clash with custom subs or keywords).
>
> Changing behavior:
> *bitwise: splits "smart" bitwise operators into two sets, potential to
> break any code using these operators, difficult to determine if it
> has been broken
> *indirect: we'd want to remove this, it's already default; but doing
> so would break a lot of existing code and the nature of the parser
> change makes it difficult to warn nicely about
> *unicode_eval: changes the behavior of string eval to make it more
> consistent, but existing string evals could be relying on the
> inconsistent interpretation
> *unicode_strings: similar to unicode_eval but much more wide reaching
> risk for a variety of string operations
> *postderef_qq: would break currently valid strings
> In my opinion, none of these are reasonably doable as it stands
> currently, aside from deprecating the behavior that they would change.
>
> New keywords:
> *current_sub: probably the lowest risk/highest reward of the
> features, use of the token __SUB__ outside of this feature is
> unlikely, but possible *evalbytes: adds the evalbytes keyword, low
> risk but not commonly used anyway
> *fc: adds the fc keyword, both useful and risky
> *say: useful and very risky
> *state: useful and very risky

I think another potentially useful way to split these changes is to
consider whether they are detectable at compile time, vs runtime; and
of those runtime ones which are potentially warnable, vs ones that
simply silently create the wrong answer.

For instance, getting rid of $* as a variable means that any code which
does

$* = 1;

simply does not compile, which is a fast, noisy failure. Of the kinds
of failure that is the one we'd most like to have.

In the middle ground is __SUB__, because as Dan points out it's
slightly possible that maybe someone has defined it as a function
elsewhere and if they did so maybe our code would compile fine; but
we'd likely discover at runtime that it didn't yield a CODE reference
so would fail with some sort of complaint about not being invokable.

Finally the bitwise operators are that final set, where if we happen to
pick the wrong one then it's unlikely a warning happens even at
runtime. The program silently continues and just produces incorrect
results.

While I don't think I'd say we "can easily" make any sort of
non-backward compatible change very lightly, we can certainly consider
this classification when deciding if the change is justified. I'd feel
happier about making changes that would cause existing programs to fail
to *compile* and give obvious error messages, and less happy about ones
that cause silent changes in behaviour to the running of
otherwise-valid ones.

Possibly this bias comes from the fact that I'm a big fan of
unit-testing everything - from the smallest of helper modules up to the
largest of full-scale systems. Everything I run at the very least has a
t/00use.t which checks if every file is `use_ok()`. This means I bias
towards putting a lot of faith in compiletime checking. If we deprecate
or remove features that the compiler can warn about in these files, I
would feel more comfortable about them.

--
Paul "LeoNerd" Evans

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

We talk about new users and having a better language to better serve them.
But there are no new users! I used to mentor people in Python and Perl.
But there is no longer any demand for Perl mentoring. Every time a change
is made to better serve the new user it conveniences no-one but
inconveniences many people who have displayed long term loyalty to Perl and
drives a few more of them away. Just as: "adding new programmers to a late
project makes it later" adding incremental new features to a dying language
simply hastens the date of its demise.

The parable of the dereferencing operators illustrates this all too well:
what was wanted was *a push 1 *but what we got was: *push $a->@*, 1 *.
Please go and explain how that works to a new programmer and see if they
prefer it to *a.append(1)*

We are too far behind the curve for incremental changes to have any
significant effect other than annoying more people so that they leave too.
Only the most radical of changes can help us now. Radical change is
entirely possible if we have guards for every feature in the language so
that each user can customize the language to their exact, unique
requirements by unplugging all the stuff they do not want and enabling just
the stuff they do want to free them from the bloat induced by other
people's ideas of what is best for them. This is why we came to Perl in
the first place to be free from the illogical constraints that the
"designers" of other languages forced upon us.

Now, when I can switch off all the cruft I do not want it might be possible
to generate AVX512 machine code directly from the remainder and have it run
faster than C. That would be compelling for me.

On Sat, Mar 27, 2021 at 8:49 PM Ricardo Signes <perl.p5p@rjbs.manxome.org>
wrote:

> Hi! I said I would try to start going through, piece by piece, what I
> think is a viable way to plan for the future of Perl. I think this topic
> is way too big to eat in one bite, and that we need to break it down into
> pieces. It's a thing that can be broken down in a lot of different ways,
> but I have kind of an idea of how I'd like to go through it all. Please
> bear with me. If I end up saying, "Let's come back to that," I promise
> I'll put it on a list, and that I think we really come back to it, but that
> it would be a problem or distraction at the moment. Again: I think if we
> try to talk about everything all at once with everybody on the list, it'll
> be a lot of noise. Let's see how we can do!
>
> For as long as I've been on perl5-porters, there's been a tension between
> reliability and improvement. I wrote about this about six years ago in the
> "perlpolicy v2 thread <http://markmail.org/thread/syv7ls43bzhzuvjc>".
> Here's part of what I said:
>
> The two priority that are at opposition here are something like this:
>
> - Perpetual reliability, because it's infuriating when a documented
> behavior goes away, after you've had code using it quietly and
> productively for years
> - Continual improvement, because when you learn lessons about what
> doesn't work, you want to benefit from them without throwing away the
> entire project.
>
>
> I stand by what I wrote in that email, and I won't rehash it. You can
> read it yourself, if you like. My point, though, was that we should have a
> policy that acknowledged this tension, and we should review changes to the
> language in light of it.
>
> That thread also talks about what it means for a changes to be lack
> backward compatibility. It means that your program changes behavior when
> you upgrade the language without changing the program. Adding a new
> warning is an incompatible change. Removing a feature is an incompatible
> change. Even adding a feature can be an incompatible change. Let's
> consider the lifespan of $*.
>
> Way back in v5.8 and earlier, $* was a global variable. Roughly, setting
> it to true made all regex act like /m was applied.
>
> As you can imagine, this was sort of a common footgun, and was deprecated
> for ages. It was diasbled in v5.10.0 — but actually in v5.9.0, very early
> on in the (very long) v5.10.0 development cycle. Referencing $* at all got
> you a compile time warning: "$* is no longer supported".
>
> This remained true in v5.20, when we introduced postfix dereferencing.
> Given a globref, you might write $globref->$* but this would emit a warning
> about $* and act like you tried to call a method named "". You had to turn
> on the postderef feature to get a glob deref.
>
> A few years later, we turned on postderef by default, meaning that ->$*
> did not mean "a method call with the empty-named method", but meant
> "dereference as glob." This *would* have broken code that might have
> worked before:
>
> ~$ perl -le 'print $];' \
> -e 'sub Foo::AUTOLOAD { print "Auto: <$Foo::AUTOLOAD>" }' \
> -e '$x = bless {}, "Foo";' \
> -e '$x->$*'
> $* is no longer supported at -e line 4.
> 5.020003
> Auto: <Foo::>
>
>
> …then…
>
> ~$ perl -le 'print $];' \
> -e 'sub Foo::AUTOLOAD { print "Auto: <$Foo::AUTOLOAD>" }' \
> -e '$x = bless {}, "Foo";' \
> > -e '$x->$*'
> 5.024004
> Not a SCALAR reference at -e line 4.
>
>
> Turning off postfix deref was no longer even possible. In other
> circumstances, $* was treated normally, acting like a normal global
> variable, but warning when used.
>
> Finally, in v5.30, using $* became a fatal compile-time error.
>
> These are a bunch of backward incompatible changes, all more or less
> motivated by "make the language easier to use" and, as incompatible
> changes, with some baggage of "someone out there will be inconvenienced."
> I was both inconvenienced *and* helped by possibly all of these changes.
> Some people might fall into only one of those groups, or neither.
>
> $* is a nice example because it's connected to so many changes, but it's
> not the only place we've changed defaults, either to deprecate things, to
> remove deprecated things, or to just change behavior. (For example, the
> meaning of "scalar %hash" changed between v5.24 and v5.26.) Some of these
> changes change runtime behavior of the code, some change the legal syntax
> of Perl. The "only perl can parse Perl" rule will apply to these in
> different amounts.
>
> I think that was Perl moves forward, we need to continue to evaluate what
> changes like these are, on the whole, beneficial. That's a complicated
> problem to measure, and it won't be something I think we can properly
> quantify but I think it's something we can actually look at, think about,
> and come to consensus on when it comes to individual changes. We need to
> consider what the benefit is, who benefits, who gets inconvenienced, how it
> could improve the language over time, and how inconvenient the
> inconvenience is.
>
> The current feature bundle contains: bitwise, current_sub, evalbytes, fc,
> indirect, postderef_qq, say, state, switch (good grief), unicode_eval, and
> unicode_strings. I think some of these are things that should become
> default parts of the language. It's helpful to people who write code to a
> recent version of perl only. It makes it possible to eventually make the
> feature always-on.
>
> Not every feature is likely to work that way. The road to turning on
> unicode_strings by default is unclear. While it'd be nice to fix the
> semantics of string operations once and for all, the inconvenience is quite
> high, because we easily provide a single helpful warning about what to do,
> or whether the user is going to see things change, and whether it'd be for
> the worse.
>
> So I think, after saying all this, the first big question is: Is there a
> general agreement that there are kinds of changes we've made (or will make)
> to the language that we can ease into making the default, through some
> multi-step process? We may need to hash out individual changes' paths
> forward, but if there is an overwhelming opposition to changing these sorts
> of defaults *at all*, then I think a lot of this conversation has to be
> entirely reconsidered.
>
> --
> rjbs
>


--
Thanks,

Phil <https://metacpan.org/author/PRBRENAN>

Philip R Brenan <https://metacpan.org/author/PRBRENAN>

On Sat, Mar 27, 2021 at 04:49:15PM -0400, Ricardo Signes wrote:
> Hi! I said I would try to start going through, piece by piece, what I think is a viable way to plan for the future of Perl.


> So I think, after saying all this, the first big question is: Is there a general agreement that there are kinds of changes we've made (or will make) to the language that we can ease into making the default, through some multi-step process? We may need to hash out individual changes' paths forward, but if there is an overwhelming opposition to changing these sorts of defaults *at all*, then I think a lot of this conversation has to be entirely reconsidered.

I would agree with that, and $* is a good complex example.

--
Andy Dougherty doughera@lafayette.edu

On Sat, Mar 27, 2021 at 8:51 PM Philip R Brenan <philiprbrenan@gmail.com>
wrote:

> We talk about new users and having a better language to better serve
> them. But there are no new users! I used to mentor people in Python and
> Perl. But there is no longer any demand for Perl mentoring. Every time a
> change is made to better serve the new user it conveniences no-one but
> inconveniences many people who have displayed long term loyalty to Perl and
> drives a few more of them away. Just as: "adding new programmers to a late
> project makes it later" adding incremental new features to a dying language
> simply hastens the date of its demise.
>

I almost entirely agree with the premise here. For as long as I can
remember as a Perl programmer, we've chased the dragon of developer market
share. In the beginning of my career (late 90s, early 2000s) it was coffee
cup throwing and hand wringing about how Java and PHP were taking our
natural niche on the web; later it was Python, then Ruby, then Javascript,
and now Python (again): we need a killer app, we need a killer feature, we
need a unique selling proposition. After 21 years, I'm pretty sure that
there isn't a silver bullet (to borrow from Philip's allusion).

Yet, I've come to the conclusion: Not evolving with the needs of the people
who are currently writing new Perl code on a regular basis — the people
either maintaining existing applications or building new ones — gives them
little incentive to continue writing new code in Perl on a regular basis.


> The parable of the dereferencing operators illustrates this all too well:
> what was wanted was *a push 1 *but what we got was: *push $a->@*, 1 *.
> Please go and explain how that works to a new programmer and see if they
> prefer it to *a.append(1)*
>

This wasn't the first conversation about postfix dereference, but
https://www.nntp.perl.org/group/perl.perl5.porters/2013/06/msg203763.html
is pretty whole cloth about the syntax. I assume this isn't an attempt to
re-litigate the past but to make a point about features being added to the
language. While the comment here is focused on just this one feature, I
think the history of references in Perl is a better illustration.

Perl 4 only had symbolic references. To create a multidimensional array
you'd use an associative array where keys were joined by $;, which defaults
to a nonprinting character (\034, the ASCII file separator?). So `$foo{qw(a
b c)}++` would increment the value of `$foo{join($;, qw(a b c)}`.

I assume that adding "hard" references in Perl5 caused a reasonable amount
of conversation, the feature at the least caused compatibility issues
similar to $* and following was noted in `perltrap.pod`: *The construct
"this is $$x" used to interpolate the pid at that point, but now tries to
dereference $x. $$ by itself still works fine, however.*

Porters made changes to Perl's referencing again in 5.001 by legalizing `${
foo }` as equivalent to `$foo` even outside of string interpolation. I
assume this was to ease the writing of the still recent and likely popular
Perl 4 style of symbolic references, in "perl-as-a-better-shell" style
programming.

The next major change that I'm aware of is David Golden's patch to "auto
dereference" in the case of push/pop/keys etc. The rational David provided
was (quoting from
https://www.nntp.perl.org/group/perl.perl5.porters/2010/10/msg165411.html
): *In various venues and forums, I've heard people express the desire for
perl do the "obvious thing" when providing a reference directly to such
functions that act on containers.*

The feature was provided because David was attempting to listen to users
and add features to respond to them. Yes, the history of auto-deref is
long, and tumultuous; the feature, eventually explicitly labeled
"experimental", was ultimately removed in 5.24. It wasn't removed entirely
because of it's failure to deal with the complexities of Perl's ...
flexible ... syntax, but also because a new feature had been added to the
language.

Rik was pretty explicit, in the link above, about his reasoning for postfix
dereference syntax: *Perl 5's references are fine, but sometimes
dereferencing them is not. We end up switching between postfix and
circumfix syntax to dereference structures. [...] Blech.*

Taking the example of `a push 1`, the right hand side would still need
circumfix dereferencing `a push @{ $one->{thing} }`: exactly one of the
problems Rik identifies as lacking in auto-deref. Postfix dereferencing
wasn't designed to attract new developers to Perl; it was designed to solve
a problem that had been identified 3 years earlier for existing Perl
developers, the need to deal with at least two different syntaxes for
dereferencing complex data structures in certain contexts, that hadn't been
adequately solved yet.

Rik is one of the most prolific Perl developers I know; Rik is also one of
the most conscientious authors of Perl I know. He thinks strongly about
readability and coherence in his code. The postfix dereference syntax is
admittedly much more Perl-ish in the ways Perl is notoriously impervious to
MD5 decryption with. But is in my opinion a more elegant solution than
auto-deref because it: exposes rather than obscures that a behavior is
happening, is discoverable by mirroring existing constructs, and operates
in a more consistent and universal way.

We are too far behind the curve for incremental changes to have any
> significant effect other than annoying more people so that they leave too.
> Only the most radical of changes can help us now.
>

As far as chasing the dragon of market share, then I entirely agree that
incremental change has no benefit. I don't think Radical change would
benefit us with that either. *I don't think people who don't currently use
Perl have any commercially compelling reason to use Perl.* I disagree that
incremental change will only serve to annoy people into leaving too, I
think people are going to leave no matter what. Our only option is to
understand the people who are staying with Perl and make sure we serve
their needs.

*"Now, here, you see, it takes all the running you can do, to keep in the
same place. If you want to get somewhere else, you must run at least twice
as fast as that!" -- *The Red Queen, Alice Through the Looking Glass

I think there is a solid point about the nature of `/usr/bin/perl` and the
need for consistency there. Perl cannot break applications like `apt-get`
which have worked for decades, it needs to at least maintain the status
quo. Maintaining the status quo isn't enough either, we need to improve the
lives of the people who are currently writing Perl code so that there's a
compelling reason to keep Perl around. Otherwise when the current
developers hand things off, the new developers won't be as ready to keep
Perl around.

Rik writes:

> [T]he first big question is: Is there a general agreement that there are
> kinds of changes we've made (or will make) to the language that we can ease
> into making the default, through some multi-step process?
>

I think the only possible answer to this for perl5-porters is yes, because
if the language can't stay relevant to the evolving needs of Perl
developers, then eventually the choice of defaults won't matter.

-Chris

On Sat, 27 Mar 2021 23:27:26 +0100, <neilb@neilb.org> wrote:

> Christian,
>
> While there are specific points in your email I’d like to respond to, the bigger issue is your tone and language.
>
> That is not how members of a community talk to each other. Please acknowledge that and apologise to Rik, and >the list.
>
> Neil

Yesterday i was using GMail for hardware migration reasons and as such, a reply i sent to this wasn't sent public but private. I'll reprise it now.


I apologize to Rik and the list for "whatever the fuck". That part was out of line.


The rest may not have been spoken calmly, but i did not insult or disrespect anyone. This is however in the face of people opposing the strict-by-default plan having repeatedly been at the receiving end of denigrations, insults, and (worse) this:

Calm but unkind behavior. (Regardless of whether the person being unkind knows they're being so.)

I won't throw other people in front of the wolves here because they have received enough insults already, but i am not remotely alone in thinking this and in fact i only consciously realized this from their words.


Neil thought my email indicated i am angry because i am not being heard. I sincerely and honestly couldn't care less about being heard. What i am asking for has been asked by many. This is not about me. The problem is that there is information that is not being communicated, leading to a situation of fear and uncertainty.

Fear that decisions are being made without full knowledge.

Uncertainty as to how to speak persuasively given: The recipients may hold either of two diametrically opposed positions; or completely unknown ones; and are in positions of power.


There is information that is missing, and has been missing since last summer. In order to decouple the explanations in this email from the questions at hand, i will state the questions on their own thread so them and their answers can live on their own merits.

We can't speak to you usefully if you won't tell us openly and clearly what you think. We can only guess and pray. I don't want to have fight. I want to move forward with effectiveness and confidence that can only be born from having accurate information.

Maybe the other thread will provide illumination.

--
With regards,
Christian Walde

On Sat, Mar 27, 2021 at 5:11 PM Dan Book <grinnz@gmail.com> wrote:

> On Sat, Mar 27, 2021 at 4:49 PM Ricardo Signes <perl.p5p@rjbs.manxome.org>
> wrote:
>
>> So I think, after saying all this, the first big question is: Is there a
>> general agreement that there are kinds of changes we've made (or will make)
>> to the language that we can ease into making the default, through some
>> multi-step process? We may need to hash out individual changes' paths
>> forward, but if there is an overwhelming opposition to changing these sorts
>> of defaults *at all*, then I think a lot of this conversation has to be
>> entirely reconsidered.
>>
>
> I am not opposed to considering what a path may be for a specific feature,
> but I do not believe it is worth the cost for any of the currently existing
> features.
>

I also would expand on this sentiment aside from the specific features
we're considering via the "Optimizing for New" and "A New Culture" sections
in my blog post "Perl 7 By Default":
http://blogs.perl.org/users/grinnz/2020/08/perl-7-by-default.html

TLDR: I think of course we *can* but in the specific cases we are talking
about we *should not*.

-Dan

On Sat, 27 Mar 2021 16:49:15 -0400, "Ricardo Signes"
<perl.p5p@rjbs.manxome.org> wrote:

> So I think, after saying all this, the first big question is: Is
> there a general agreement that there are kinds of changes we've made
> (or will make) to the language that we can ease into making the
> default, through some multi-step process?

+1 from me

> We may need to hash out individual changes' paths forward, but if
> there is an overwhelming opposition to changing these sorts of
> defaults *at all*, then I think a lot of this conversation has to be
> entirely reconsidered.

--
H.Merijn Brand https://tux.nl Perl Monger http://amsterdam.pm.org/
using perl5.00307 .. 5.33 porting perl5 on HP-UX, AIX, and Linux
https://tux.nl/email.html http://qa.perl.org https://www.test-smoke.org

On Sat, 27 Mar 2021 17:31:53 -0400, Dan Book <grinnz@gmail.com> wrote:

> On Sat, Mar 27, 2021 at 4:49 PM Ricardo Signes
> <perl.p5p@rjbs.manxome.org> wrote:
>
> > $* is a nice example because it's connected to so many changes, but
> > it's not the only place we've changed defaults, either to deprecate
> > things, to remove deprecated things, or to just change behavior.
> > (For example, the meaning of "scalar %hash" changed between v5.24
> > and v5.26.) Some of these changes change runtime behavior of the
> > code, some change the legal syntax of Perl. The "only perl can
> > parse Perl" rule will apply to these in different amounts.
> >
>
> They are nice examples for specific instances, but they each have
> their own unique circumstances and aren't great for informing a
> "general case" of any sort.
>
> $* was used by almost nobody while it existed, for its part.
>
> scalar %hash was already a weird return value, so even code that used
> it rarely cared what it actually contained.
>
> The current feature bundle contains: bitwise, current_sub, evalbytes,
> fc,
> > indirect, postderef_qq, say, state, switch (good grief),
> > unicode_eval, and unicode_strings. I think some of these are
> > things that should become default parts of the language. It's
> > helpful to people who write code to a recent version of perl only.
> > It makes it possible to eventually make the feature always-on.
> >
>
> We can split the features into roughly two categories: features that
> change the meaning of existing constructs, and features that add new
> keywords (which could clash with custom subs or keywords).
>
> Changing behavior:
> *bitwise: splits "smart" bitwise operators into two sets, potential to
> break any code using these operators, difficult to determine if it
> has been broken
> *indirect: we'd want to remove this, it's already default; but doing
> so would break a lot of existing code and the nature of the parser
> change makes it difficult to warn nicely about
> *unicode_eval: changes the behavior of string eval to make it more
> consistent, but existing string evals could be relying on the
> inconsistent interpretation
> *unicode_strings: similar to unicode_eval but much more wide reaching
> risk for a variety of string operations
> *postderef_qq: would break currently valid strings
> In my opinion, none of these are reasonably doable as it stands
> currently, aside from deprecating the behavior that they would change.
>
> New keywords:
> *current_sub: probably the lowest risk/highest reward of the
> features, use of the token __SUB__ outside of this feature is
> unlikely, but possible *evalbytes: adds the evalbytes keyword, low
> risk but not commonly used anyway
> *fc: adds the fc keyword, both useful and risky
> *say: useful and very risky
> *state: useful and very risky
>
> -Dan

Personally I am willing to accept these breaking changes

* as long as I have a way to make the script valid to run under all
versions I support *

I really like the soft-feature thingy proposed

I just recently ran into my first fail with unicode_strings, as tests
started to FAIL when I replaced a "use strict" with "use 5.14.2". That
specific test was testing all kind of strings with different encodings
to see how the module's functionality would cope with it.

For that specific file 'no "unicode_strings";' was sufficient to make
everything PASS again, but if a script needs syntax to disable new
functionality that would make it impossible to run in an older version,
that would make life harder to stay backward compatible.

So, new defaults: YES PLEASE! (but not if it is impossible to have
(parts of) the code run on older pers. Extra statements and conditions
are ok, as long as it is possible).

--
H.Merijn Brand https://tux.nl Perl Monger http://amsterdam.pm.org/
using perl5.00307 .. 5.33 porting perl5 on HP-UX, AIX, and Linux
https://tux.nl/email.html http://qa.perl.org https://www.test-smoke.org

On 3/28/21 2:32 AM, Chris Prather wrote:
>
> On Sat, Mar 27, 2021 at 8:51 PM Philip R Brenan <philiprbrenan@gmail.com
> <mailto:philiprbrenan@gmail.com>> wrote:
>
> We talk about new users and having a better language to better serve
> them.  But there are no new users!  I used to mentor people in
> Python and Perl.  But there is no longer any demand for Perl
> mentoring.  Every time a change is made to better serve the new user
> it conveniences no-one but inconveniences many people who have
> displayed long term loyalty to Perl and drives a few more of them
> away.  Just as: "adding new programmers to a late project makes it
> later" adding incremental new features to a dying language simply
> hastens the date of its demise.
>
>
> I almost entirely agree with the premise here. For as long as I can
> remember as a Perl programmer, we've chased the dragon of developer
> market share. In the beginning of my career (late 90s, early 2000s) it
> was coffee cup throwing and hand wringing about how Java and PHP were
> taking our natural niche on the web; later it was Python, then Ruby,
> then Javascript, and now Python (again): we need a killer app, we need a
> killer feature, we need a unique selling proposition. After 21 years,
> I'm pretty sure that there isn't a silver bullet (to borrow from
> Philip's allusion).
>
> Yet, I've come to the conclusion: Not evolving with the needs of the
> people who are currently writing new Perl code on a regular basis — the
> people either maintaining existing applications or building new ones —
> gives them little incentive to continue writing new code in Perl on a
> regular basis.
>

I am one of those. I use Perl because it DWIM, gets out of the way, and
in most cases can accept `fork` over lightweight threading (as in
pthreads) for utilizing hardware on bare metal - oh and it is
everywhere, or can be at a moments notice. For small tools/scripts, if I
can get away with it, I write Bourne compatible shell scripts - that's
my "other language". Perl is my "large" application language. Nothing
else comes close to just being there and working. Nothing.

In my eyes, Perl is in the "what can we take away" phase. It is my very
strong opinion that additional language features are not going to make
Perl "popular". Not a new OOP in core, not a "tromp/trim" function. Not
a "say" method. None of these provide any power nor are they going to
make it popular. Stop chasing other languages and market share. Chase
application domains, or at least let's create an additional vector to
chase things like tooling (as I mentioned before). I say this having
been an astute observer of Perl for some 20 years, and while not a
"polyglot" because nothing comes close to Perl for me; I am a student of
the history of PLs and follow them on a higher level. Perl is unique in
all aspects. Do not lose this.

Java, PHP, and JS were a threat to Perl because Perl was filling that
gaps because it could. Perl is more "XP" than Java up to the point you
wish to have a GUI app. Think about that. JavaScript is a powerful tool
because of fiat browser support. No wonder nodejs is popular, some
browser UI jockies woke up one morning and decided they wanted to work
on more interesting things. It makes sense no-browser JS would be
popular; Perl has far better modules, frameworks, package management,
and environmental switching tools (perlbrew vs nvm). So what, server
side if Perl's turf. Tomcat? Joke compared to mod_perl even (and yet
there's an attempt to bury it alive.)

Focus on making Perl stronger for distributing applications or embedded
uses (I don't hear anyone saying, look how great Lua is for blah blah
blah; focus on closing the "last mile" for XP. All these other languages
have endless funding from corporations and monopolistic distribution.
The browser will be dead before anything is released anyway, and by that
time we will have recreated JavaScript? Fight the next war, not the last
one.

At the end of the day: getting Perl in the most hands possible using it
in as many ways as possible is going to necessarily drive language
development - and it will.

Finding significant, compatible changes to Perl that will bring people
in *and* make current users happy is not possible. Perl is what it is,
for better or for worse. Is awk worrying about chasing Rust? Does TCL
care about nodejs? Is C losing sleep over any of this?

> The parable of the dereferencing operators illustrates this all too
> well: what was wanted was *a push 1 *but what we got was: *push
> $a->@*, 1 *.  Please go and explain how that works to a new
> programmer and see if they prefer it to *a.append(1)*
>
>
> This wasn't the first conversation about postfix dereference, but
> https://www.nntp.perl.org/group/perl.perl5.porters/2013/06/msg203763.html is
> pretty whole cloth about the syntax. I assume this isn't an attempt to
> re-litigate the past but to make a point about features being added to
> the language. While the comment here is focused on just this one
> feature, I think the history of references in Perl  is a better
> illustration.

Listen, I am not trying to dissuade language design decisions or
discussions, but my Sweet Lord, please wake up anyone who thinks stuff
like this ^^ is going to steal 25% of the Rust mind share. The minutia
of this is invisible to even seasoned Perl programmers.

In additional to fostering (at a high level) tooling around distributing
Perl applications, has anyone taken a serious look at what's going on
with perl and linux/BSD distros?

* OpenBSD is the only one that keeps it base (that should tell you
something - good)
* FreeBSD took it out of base YEARS ago
* FreeBSD is the only freenix that supports more than one version of
perl (4 at least count) and has a means to have them all installed at
once; even if the /usr/local/bin/perl is symliked to only one at a time
(they do the same for python2,3 and ruby, etc)
* pkgsrc (NetBSD) supports a LARGE number of systems, yet provides only
one version of Perl (fairly up to day)
* Ubuntu - omg, the way it breaks up perl-doc, libperl-dev, etc, etc -
not good for Perl at all
* RH/Centos - idk even know any more, I think it breaks up the perl
stuff like Ubuntu but I have not checked

This is definitely going into the Perl advocacy realm, who among us is
"officially" in charge of nagging Canonical about the way it breaks up
Perl? Who was on the horn with FBSF when they ripped perl out of their
base? Is anyone working with Strawberry Perl or wx-widgets? You want
Perl apps on Windows? There's your core team, and one of them might even
be economically viable.

You can see where this is going. My main point: please, for the love of
God and all that is Holy - stop banking the future of Perl on making it
more familiar to Language X developers, especially at the rejection of
your most loyal and fruitful users. You will never capture the former;
you will forever lost or completely demoralize the latter. Cater to the
loyal, avoid language whores and immature developers who still jump on
the JavaScriptFrameworkOfTheWeek^tm or whatever language
MozillaGoogleUSAgov is funding at the moment.

So where do these discussions and leadership belong? Is P5P the defacto
outlet for the PSC? E.g., I don't expect what I said above to really get
anywhere because it's not technical in nature; it's long term strategic.

So who is supposed to be thinking about things like:

* long term vision (high level)
* thanking FreeBSD for supporting several versions of perl (important
when it comes to "perl7.0.0" as they will add it), etc
* identifying players in "Perl on Windows", "XP GUI", "application
distribution" and working to support them?

And lastly, while I don't think it is P5P's responsibility to "save"
things like mod_perl; who is on the phone right now ASF to figure out if
this really is an issue and what can be done to mitigate the damage done
by merely questioning if it should be "retired"? As if.

The burden of this list or the main players seems great enough on the
"technical front" - I hope moving ahead the PSC (or whomever) gets
ruthlessly strategic about the future of Perl. "Language design" is sure
one aspect, but so are the things I mentioned above and many more. You
guys want to fight for the future of Perl? Treat this as a real war and
don't focus strictly on gold plating your bullets.

Thanks,
Brett

>
> Perl 4 only had symbolic references. To create a multidimensional array
> you'd use an associative array where keys were joined by $;, which
> defaults to a nonprinting character (\034, the ASCII file separator?).
> So `$foo{qw(a b c)}++` would increment the value of `$foo{join($;, qw(a
> b c)}`.
>
> I assume that adding "hard" references in Perl5 caused a reasonable
> amount of conversation, the feature at the least caused compatibility
> issues similar to $* and following was noted in `perltrap.pod`: /The
> construct "this is $$x" used to interpolate the pid at that point, but
> now tries to dereference $x. |$$| by itself still works fine, however./
>
> Porters made changes to Perl's referencing again in 5.001 by legalizing
> `${ foo }` as equivalent to `$foo` even outside of  string
> interpolation. I assume this was to ease the writing of the still recent
> and likely popular Perl 4 style of  symbolic references, in
> "perl-as-a-better-shell" style programming.
>
> The next major change that I'm aware of is David Golden's patch to "auto
> dereference" in the case of push/pop/keys etc. The rational David
> provided was (quoting from
> https://www.nntp.perl.org/group/perl.perl5.porters/2010/10/msg165411.html ):
> /In various venues and forums, I've heard people express the desire for
> perl do the "obvious thing" when providing a reference directly to such
> functions that act on containers./
>
> The feature was provided because David was attempting to listen to users
> and add features to respond to them. Yes, the history of auto-deref is
> long, and tumultuous; the feature, eventually explicitly labeled
> "experimental", was ultimately removed in 5.24. It wasn't removed
> entirely because of it's failure to deal with the complexities of Perl's
> ... flexible ... syntax, but also because a new feature had been added
> to the language.
>
> Rik was pretty explicit, in the link above, about his reasoning for
> postfix dereference syntax: /Perl 5's references are fine, but sometimes
> dereferencing them is not. We end up switching between postfix and
> circumfix syntax to dereference structures. [...] Blech./
>
> Taking the example of `a push 1`, the right hand side would still need
> circumfix dereferencing `a push @{ $one->{thing} }`: exactly one of the
> problems Rik identifies as lacking in auto-deref. Postfix dereferencing
> wasn't designed to attract new developers to Perl; it was designed to
> solve a problem that had been identified 3 years earlier for existing
> Perl developers, the need to deal with at least two different syntaxes
> for dereferencing complex data structures in certain contexts, that
> hadn't been adequately solved yet.
>
> Rik is one of the most prolific Perl developers I know; Rik is also one
> of the most conscientious authors of Perl I know. He thinks strongly
> about readability and coherence in his code. The postfix dereference
> syntax is admittedly much more Perl-ish in the ways Perl is notoriously
> impervious to MD5 decryption with. But is in my opinion a more elegant
> solution than auto-deref because it: exposes rather than obscures that a
> behavior is happening, is discoverable by mirroring existing
> constructs, and operates in a more consistent and universal way.
>
> We are too far behind the curve for incremental changes to have any
> significant effect other than annoying more people so that they
> leave too.  Only the most radical of changes can help us now.
>
>
> As far as chasing the dragon of market share, then I entirely agree that
> incremental change has no benefit. I don't think Radical change would
> benefit us with that either. *I don't think people who don't currently
> use Perl have any commercially compelling reason to use Perl.* I
> disagree that incremental change will only serve to annoy people into
> leaving too, I think people are going to leave no matter what. Our only
> option is to understand the people who are staying with Perl and make
> sure we serve their needs.
>
> /"Now, here, you see, it takes all the running you can do, to keep in
> the same place. If you want to get somewhere else, you must run at least
> twice as fast as that!" -- /The Red Queen, Alice Through the Looking Glass
> //
>
> I think there is a solid point about the nature of `/usr/bin/perl` and
> the need for consistency there. Perl cannot break applications like
> `apt-get` which have worked for decades, it needs to at least maintain
> the status quo. Maintaining the status quo isn't enough either, we need
> to improve the lives of the people who are currently writing Perl code
> so that there's a compelling reason to keep Perl around. Otherwise when
> the current developers hand things off, the new developers won't be as
> ready to keep Perl around.
>
> Rik writes:
>
> [T]he first big question is: Is there a general agreement that there
> are kinds of changes we've made (or will make) to the language that
> we can ease into making the default, through some multi-step process?
>
> I think the only possible answer to this for perl5-porters is yes,
> because if the language can't stay relevant to the evolving needs of
> Perl developers, then eventually the choice of defaults won't matter.
>
> -Chris

On Mon, Mar 29, 2021 at 09:48:06AM -0500, B. Estrade wrote:
> In additional to fostering (at a high level) tooling around distributing
> Perl applications, has anyone taken a serious look at what's going on with
> perl and linux/BSD distros?
>
> * OpenBSD is the only one that keeps it base (that should tell you something
> - good)
> * FreeBSD took it out of base YEARS ago
> * FreeBSD is the only freenix that supports more than one version of perl (4
> at least count) and has a means to have them all installed at once; even if
> the /usr/local/bin/perl is symliked to only one at a time (they do the same
> for python2,3 and ruby, etc)
> * pkgsrc (NetBSD) supports a LARGE number of systems, yet provides only one
> version of Perl (fairly up to day)
> * Ubuntu - omg, the way it breaks up perl-doc, libperl-dev, etc, etc - not
> good for Perl at all
> * RH/Centos - idk even know any more, I think it breaks up the perl stuff
> like Ubuntu but I have not checked
>
> This is definitely going into the Perl advocacy realm, who among us is
> "officially" in charge of nagging Canonical about the way it breaks up Perl?
> Who was on the horn with FBSF when they ripped perl out of their base? Is
> anyone working with Strawberry Perl or wx-widgets? You want Perl apps on
> Windows? There's your core team, and one of them might even be economically
> viable.

I'm not sure how this relates to the topic to hand, but... I'm one of the
current co-maintainers of perl in Debian (and by extension Ubuntu). We
enjoy a fruitful relation with the upstream perl community with the
occasional upstream contribution and many more downstream contributions
arising from issues we face (including helping to support older perls
in our stable releases). I don't believe we have ever been nagged about
the way that perl is split into different binary packages in Debian
in the decade since I got involved from anyone involved in upstream
perl development.

Those splits are all there to support perl being smoothly installed as
part of the base system (where there are strict size constraints, and
strict "this must always work even the middle of upgrade" constraints)
as well as to support perl running on a dozen different architectures,
and to support various upgrade paths for XS modules. All if which is
mostly invisible to the regular user who just wants to apt-get install perl
and have it work.

But you haven't explained what you find so offensive about this
situation. Why is this not good for Perl?

Dominic

On 3/29/21 6:16 PM, Dominic Hargreaves wrote:
> On Mon, Mar 29, 2021 at 09:48:06AM -0500, B. Estrade wrote:
>> In additional to fostering (at a high level) tooling around distributing
>> Perl applications, has anyone taken a serious look at what's going on with
>> perl and linux/BSD distros?
>>
>> * OpenBSD is the only one that keeps it base (that should tell you something
>> - good)
>> * FreeBSD took it out of base YEARS ago
>> * FreeBSD is the only freenix that supports more than one version of perl (4
>> at least count) and has a means to have them all installed at once; even if
>> the /usr/local/bin/perl is symliked to only one at a time (they do the same
>> for python2,3 and ruby, etc)
>> * pkgsrc (NetBSD) supports a LARGE number of systems, yet provides only one
>> version of Perl (fairly up to day)
>> * Ubuntu - omg, the way it breaks up perl-doc, libperl-dev, etc, etc - not
>> good for Perl at all
>> * RH/Centos - idk even know any more, I think it breaks up the perl stuff
>> like Ubuntu but I have not checked
>>
>> This is definitely going into the Perl advocacy realm, who among us is
>> "officially" in charge of nagging Canonical about the way it breaks up Perl?
>> Who was on the horn with FBSF when they ripped perl out of their base? Is
>> anyone working with Strawberry Perl or wx-widgets? You want Perl apps on
>> Windows? There's your core team, and one of them might even be economically
>> viable.
>
> I'm not sure how this relates to the topic to hand, but... I'm one of the
> current co-maintainers of perl in Debian (and by extension Ubuntu). We
> enjoy a fruitful relation with the upstream perl community with the
> occasional upstream contribution and many more downstream contributions
> arising from issues we face (including helping to support older perls
> in our stable releases). I don't believe we have ever been nagged about
> the way that perl is split into different binary packages in Debian
> in the decade since I got involved from anyone involved in upstream
> perl development.
>
> Those splits are all there to support perl being smoothly installed as
> part of the base system (where there are strict size constraints, and
> strict "this must always work even the middle of upgrade" constraints)
> as well as to support perl running on a dozen different architectures,
> and to support various upgrade paths for XS modules. All if which is
> mostly invisible to the regular user who just wants to apt-get install perl
> and have it work.
>
> But you haven't explained what you find so offensive about this
> situation. Why is this not good for Perl?

I suppose this is fair given I broached the subject. I don't want to
distract from the larger topic at hand. Although I must admit I am
rather mentally exhausted from my latest spate of emails. :)

In this specific case, this happens to me, every time:

1. docker run -it ubuntu sh

[.note: just checked /usr/bin/perl is there for both ubuntu:latest,
debian:latest, and debian:stretch-slim 'out of box'; perldoc is not.
alpine (just as another example requires the 'apk add perl' to start;
but perldoc is there as expected after `perl` is installed; anyway...]

2. /me starts coding, oops! how do I use Getopts::Long again?
3. perldoc Getopts::Long
4. ubuntu: "boooomp! wrong gotta install perl-doc package" (how I take
it, not what it actually says)
5. /me (head hits desk), whimpers something about why is so

But that's me. My goal is not to change your mind. It was just an
example asking if anyone tracks these things - that I added a personal
comment was actually out of line and wouldn't be part of any type of
tracking document I would expect to see. So, apologies if I caused
confusion.

That said, I would love to see some sort of PSC steering document that
simply tracked how linux distros, BSD, etc provided perl (minus personal
comments) with a mind towards ensuring it be distributed as widely and
completely as possible.

Thank you for providing me an opportunity to explain. And thank you for
your hard work, don't think I don't appreciate it.

Cheers,
Brett

>
> Dominic
>

On 3/29/21 7:11 PM, B. Estrade wrote:
>
>
> On 3/29/21 6:16 PM, Dominic Hargreaves wrote:
>> On Mon, Mar 29, 2021 at 09:48:06AM -0500, B. Estrade wrote:
>>> In additional to fostering (at a high level) tooling around distributing
>>> Perl applications, has anyone taken a serious look at what's going on
>>> with
>>> perl and linux/BSD distros?
>>>
>>> * OpenBSD is the only one that keeps it base (that should tell you
>>> something
>>> - good)
>>> * FreeBSD took it out of base YEARS ago
>>> * FreeBSD is the only freenix that supports more than one version of
>>> perl (4
>>> at least count) and has a means to have them all installed at once;
>>> even if
>>> the /usr/local/bin/perl is symliked to only one at a time (they do
>>> the same
>>> for python2,3 and ruby, etc)
>>> * pkgsrc (NetBSD) supports a LARGE number of systems, yet provides
>>> only one
>>> version of Perl (fairly up to day)
>>> * Ubuntu - omg, the way it breaks up perl-doc, libperl-dev, etc, etc
>>> - not
>>> good for Perl at all
>>> * RH/Centos - idk even know any more, I think it breaks up the perl
>>> stuff
>>> like Ubuntu but I have not checked
>>>
>>> This is definitely going into the Perl advocacy realm, who among us is
>>> "officially" in charge of nagging Canonical about the way it breaks
>>> up Perl?
>>> Who was on the horn with FBSF when they ripped perl out of their
>>> base?  Is
>>> anyone working with Strawberry Perl or wx-widgets? You want Perl apps on
>>> Windows? There's your core team, and one of them might even be
>>> economically
>>> viable.
>>
>> I'm not sure how this relates to the topic to hand, but... I'm one of the
>> current co-maintainers of perl in Debian (and by extension Ubuntu). We
>> enjoy a fruitful relation with the upstream perl community with the
>> occasional upstream contribution and many more downstream contributions
>> arising from issues we face (including helping to support older perls
>> in our stable releases). I don't believe we have ever been nagged about
>> the way that perl is split into different binary packages in Debian
>> in the decade since I got involved from anyone involved in upstream
>> perl development.
>>
>> Those splits are all there to support perl being smoothly installed as
>> part of the base system (where there are strict size constraints, and
>> strict "this must always work even the middle of upgrade" constraints)
>> as well as to support perl running on a dozen different architectures,
>> and to support various upgrade paths for XS modules. All if which is
>> mostly invisible to the regular user who just wants to apt-get install
>> perl
>> and have it work.
>>
>> But you haven't explained what you find so offensive about this
>> situation. Why is this not good for Perl?
>
> I suppose this is fair given I broached the subject. I don't want to
> distract from the larger topic at hand. Although I must admit I am
> rather mentally exhausted from my latest spate of emails. :)
>
> In this specific case, this happens to me, every time:
>
> 1. docker run -it ubuntu sh
>
> [.note: just checked /usr/bin/perl is there for both ubuntu:latest,
> debian:latest, and debian:stretch-slim 'out of box'; perldoc is not.
> alpine (just as another example requires the 'apk add perl' to start;
> but perldoc is there as expected after `perl` is installed; anyway...]
>
> 2. /me starts coding, oops! how do I use Getopts::Long again?
> 3. perldoc Getopts::Long
> 4. ubuntu: "boooomp! wrong gotta install perl-doc package" (how I take
> it, not what it actually says)
> 5. /me (head hits desk), whimpers something about why is so
>
> But that's me. My goal is not to change your mind. It was just an
> example asking if anyone tracks these things - that I added a personal
> comment was actually out of line and wouldn't be part of any type of
> tracking document I would expect to see. So, apologies if I caused
> confusion.
>
> That said, I would love to see some sort of PSC steering document that
> simply tracked how linux distros, BSD, etc provided perl (minus personal
> comments) with a mind towards ensuring it be distributed as widely and
> completely as possible.
>
> Thank you for providing me an opportunity to explain. And thank you for
> your hard work, don't think I don't appreciate it.

Oh! And I did forgot one other thing I use perldoc for - a lot of times
I need to take a look at module source, and I find using `perldoc -l
Module::Name` to give me the /path/to/Module/Name.pm (or at least .pod)
extremely helpful. So there you go, that's about as completely as I can
address the issue you raised.

Brett

>
> Cheers,
> Brett
>
>>
>> Dominic
>>

On Sat, Mar 27, 2021, at 4:49 PM, Ricardo Signes wrote:
> So I think, after saying all this, the first big question is: Is there a general agreement that there are kinds of changes we've made (or will make) to the language that we can ease into making the default, through some multi-step process? We may need to hash out individual changes' paths forward, but if there is an overwhelming opposition to changing these sorts of defaults *at all*, then I think a lot of this conversation has to be entirely reconsidered.

I don't think we've had enough responses, especially from core team members, to say we have some kind of clear consensus. But that's fine with me, and basically expected. So I'm just going to try to keep moving forward on the topic. (I would, of course, love to hear some chiming-in from more of the core team, too, though!)

Of those who responded, I think there is *generally* an agreement that sometimes changing defaults in the language is justified. There's also not a lot of agreement that any existing feature-guarded feature is worth the trouble.

So, I want to go through a bit of what *I* know are some of the good and bad things going on here. All of these are part of a big complicated set of trade-offs. I am not suggesting that any of these is a single guiding principle to be followed as the ultimate concern. Also, I get it. This list is both long *and* incomplete, which is an obnoxious combination. Still, I think it's worth putting it down:
* Needing to writing boilerplate to get a good programming language is bad. The more you have to write, the worse. The least you might have to write is *nothing*. That would be best. The second least you might have to write is "use vX;". Anything less than "use vX;" but more than nothing is just golf.
* Needing to edit your source code when you upgrade from one version of the language to another is bad. The more you have to edit, the worse. The smallest likely edit is to add "use vY;" at the top. Not every change can be like that. When $* went away, adding "use v4" was not going to help.
* Getting advance notice that your program is going to break in the future is good. The ideal length long enough that you see warnings when you upgrade telling you that things will be broken in your next upgrade. (Astute readers will realize that this is a pretty hard target to actually guess at.)
* When "your program will break" notices are given, it's good when it can tell you how long you have (largely, I think, as a motivator!) and specifically how to fix your problem.
* Needing to edit *somebody else's* source code when you upgrade from one version of the language to another is bad, and specifically worse than having to edit your own. There are pieces of software on the CPAN that haven't been updated for years, but run fine. If you rely on them, and they break, and they have no clear maintainer, you have a new problem.
* Finding out that code samples in the documentation you're looking at no longer work because the language has moved on is bad. It's another form of "needing to edit somebody else's source code", but if we're talking about a printed book, "patches welcome" is not really applicable.
* Making Perl harder to parse is bad. When perl is parsing Perl, it knows what kind of semantics are in play. Other things, like PPI or perl.vim, do not. They already suffer because of the many ways that Perl's execution can alter parse semantics. Making Perl harder to parse makes it less likely that we get good tools for working with Perl documents.
* Making Perl easier to parse is good. This is not the same as the previous point! Consider the ambiguity between "sub foo ($) {...}" whether prototypes or signatures are enabled. Determining the enabled-ness of signatures statically is a fool's errand. Because writing boilerplate is bad, there exist numerous helper pragmata <https://metacpan.org/pod/rjbs> that turn on a bunch of features, warnings, and so on all at once. The static analyzer won't see this. Having fewer options, rather than more, makes Perl easier to parse — if you write off parsing old documents.
* 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.

I'll stop this list there. I'm sure it's not complete, but it's long enough, contains at least most of what I'm thinking about, and also it's getting late here.

[. At this point I wrote a few paragraphs, deleted them, decided I was too tired, and went to bed. Now it's morning and I'm picking back up. ]

I think a lot of the above circles around the idea that what we want is to feel like everyone has one Perl, and that it's the best one we can provide. Since there is already more than one Perl (for example, "default feature bundle" perl and "use v5.32 perl"), the question is how (and whether) we can resolve that.

One way to do it is to gradually alter the default to continue to approach the current best practice, dropping old behaviors from the default bundle, possibly replacing them with new ones. The way I imagine this is that right now, we have a window of "best Perls" that have existed. It was originally defined with two values: one close to v5.8's behavior, one with the v5.10 behavior. Then, every few years, we have been adding new values "at the right", defining the "best Perl" for each new version. At the same time, we've been minimally shaving off bits at the left, with the most notable example probably being dropping the "arybase" feature.

There are at least a few futures that have been discussed:

1. The default bundle is always the most-compatible-with-v5.8 bundle. (This is our current reality.)
2. The default bundle is occasionally reset to point to a recent version. Some of the warning for this is "warnings" and some is just in the release notes.
3. The default bundle is continuously trailing behind "the best," trying to target a recent version of what is best while also warn-ing about the changes to the default bundle in the next release.

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.

One question here is "what are the costs incurred by changing the default group", and that ground has been trod a lot, and I think we should tread it some more, but for now I want to put it aside. The other question is: Who benefits from "boilerplate zero" and how?

I think it's something like this:

*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." Of course, "don't have to remember the invocation" begs the question. Did they have to before? No, but the invocations get them: typo protection, catching probable (or possible) errors, using the most-likely (says me) encoding for their source document, and turning on features that they're likely going to want. A lot of it is footgun removal.

On the other hand, in many case, people who write new code turn into people with old code to maintain. Later, that code may run up against changes in defaults in a later version. It won't include "use vX" — the avoidance of which was the whole point — so the author can assume some amount of warnings to be issued in interim versions, then a release that breaks things. This is where "writing boilerplate is bad" bumps up into "having to edit your program on upgrade is bad."

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

Sometimes we posit another group of people as having benefit from shifting the defaults toward modernity:

*Maintainers of perl* get benefits from the defaults shifting. If the only way to get an old behavior is to opt in, then opting in can be made fatal. "You have asked to enable array_base, but it was removed in v5.30. DIE." With that done, there's a built-in mechanism for locating code using dead features: they had to be opted in to, and the opt-in can now trigger a warning, and later an error.

I'm not sure this works. For example, array_base was always implicitly on in the default and v5.10 - v5.14 bundles. When it was removed, even though users thought they had been opting in (by using the bundle), the opt-in was silently removed. We could do this because the use of the array_base feature was a detectable event. "Sure, you were asking for this feature, before, but you weren't using it, so we can safely remove it." Expressly asking for array_base is now fatal in v5.30, but the implicit ask for it in old bundles is not.

This implies that we can only safely kill off features that are included in version bundles only if the use of the feature can *also* be detected so that a warning can be issued. Otherwise, we'd have to say "sorry, use v5.10 is no longer possible, because it turns on feature invisible_benefit, which has been removed and cannot be detected." And, since the default bundle isn't even expressly requested, this gets even thornier.

*A digression on the three kinds of features:* (and by "feature" I mean "thing governed by pragma)

1. a feature that changes compile time behavior (like turning on try/catch blocks or "my sub")
2. a feature that changes detectable runtime behavior (like "strict refs")
3. a feature that changes "undetectable" runtime behavior (like unicode_strings) — detecting the change is possible, but fairly pointless

Of these, I think the truth is probably that it's the third category that would be the most beneficial to fix, both for new users and core maintainers. They constitute footgun removal, but also eliminate code paths in the implementation that are there entirely to service footguns! But you can't practically issue warnings for many of these, so it's not clear that there is a path to fixing them without a shock to the system.

*I'm getting to the end of this email.* Sorry, I know it's been long. I have a lot more I want to say, but: I think the biggest question from this email (apart from the implicit "Did I make a massive error somewhere?") is the thing I flagged out with the pointy finger, above: Having *entirely* put aside the question of the initial cost of changing defaults the first time — assuming that we make "no boilerplate" act a lot like v5.34, without incident, somehow — can we reach a state where a cycle of warning-then-change can be reliably made on a scale larger than the sorts of deprecations that we've made up until now?

I'll come back to my other thoughts on a bunch of parts of this problem in two or three days.

--
rjbs

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.

-Dan

On Mon, 29 Mar 2021 19:11:21 -0500, "B. Estrade" <brett@cpanel.net>
wrote:

> In this specific case, this happens to me, every time:
>
> 1. docker run -it ubuntu sh
>
> [.note: just checked /usr/bin/perl is there for both ubuntu:latest,
> debian:latest, and debian:stretch-slim 'out of box'; perldoc is not.
> alpine (just as another example requires the 'apk add perl' to start;
> but perldoc is there as expected after `perl` is installed; anyway...]
>
> 2. /me starts coding, oops! how do I use Getopts::Long again?
> 3. perldoc Getopts::Long
> 4. ubuntu: "boooomp! wrong gotta install perl-doc package" (how I
> take it, not what it actually says)
> 5. /me (head hits desk), whimpers something about why is so

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.

I see no reason to install manual pages and help/info stuff inside a
docker. I really don't, unless it is part of the *goal* for that
docker: a help application or the like.

However I sympathize with your /headdesk, the world has moved on and
new working environments made new criteria and requirements. If a
system starts 40 docker images with microservices, I (with my sysadmin
hat on) really appreciate that those images are lean and mean, start
swiftly and don't take tons of diskspace that are unlikely to be ever
used.

Likewise for a file missing on a target system. The way package
managers are unable to tell me what I should install to get the
file/functionality I require, and the overly complicated combination of
options sometimes needed makes me go to a system where that file *is*
installed and just ask 'rpm -qf /path/to/file' and I have the answer I
need. (replace with package manger of choice syntax, but you get the
drift).

Do not expect a docker to have all your heart desires. Ever.

Just my view (being someone why has the opinion that docker is overused
in many situations).

--
H.Merijn Brand https://tux.nl Perl Monger http://amsterdam.pm.org/
using perl5.00307 .. 5.33 porting perl5 on HP-UX, AIX, and Linux
https://tux.nl/email.html http://qa.perl.org https://www.test-smoke.org

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.

To my knowledge both DaveM and LeoNerd have opined that deprecating old behaviors gains little to none for the code Perl actually has at the moment.

I recommend double-checking with them on that point.

--
With regards,
Christian Walde

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.

--
With regards,
Christian Walde

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

> 3. a feature that changes "undetectable" runtime behavior (like unicode_strings) — >detecting the change is possible, but fairly pointless
> Of these, I think the truth is probably that it's the third category that would be the >most beneficial to fix, both for new users and core maintainers.

I've been wanting to comment something like this, which in my mind coalesces to:

Defaults should only be changed in terms of critical bugfixes or bugfixes that can be applied with very little harm.

This primarily means situations where security considerations are involved (most every maintainer will bow to a CVE), or situations where most of the time the code does what most users want, but occasionally does something most users won't want (thinking unmatched braces).

--
With regards,
Christian Walde

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

On Tue, Mar 30, 2021 at 09:54:48AM +0200, 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.
>
> To my knowledge both DaveM and LeoNerd have opined that deprecating old behaviors gains little to none for the code Perl actually has at the moment.

I'm neither of the above but yes, generally, existing behaviour doesn't
"get in the way". In that

* most things that folks are interested in (and are achievable) are better
syntax for existing fundamental operations
* (obscure) existing runtime behaviour rarely gets in the way of this

(So I think even for try/catch which is more than just compile time, there
isn't much in the existing runtime that gets in the way of implementing it -
it's mostly figuring out syntax and semantics, and then *extending* the
existing runtime to support it.)

Existing expectations for emergent behaviour *do* get in the way of
refactoring things - but these are rarely about syntax, or at least
documented syntax. It's hard to refactor things without discovering that
two (or more) subtle implementation details interact to create runtime
behaviour that wasn't documented or tested, but it turns out something
relies on it. That last part seemingly is "Hyrum's Law":

With a sufficient number of users of an API,
it does not matter what you promise in the contract:
all observable behaviors of your system
will be depended on by somebody.



Anyway, the substantive part of this message was meant to be the tale of
three punctuation variables $#, $* and $[, and how removing them had
different implications. All from memory:

$# The output format for printed numbers. This variable is a
half-hearted attempt to emulate awk's OFMT variable. There are
times, however, when awk and Perl have differing notions of
what counts as numeric. The initial value is "%.ng", where n
is the value of the macro DBL_DIG from your system's float.h.
This is different from awk's default OFMT setting of "%.6g", so
you need to set $# explicitly to get awk's value. (Mnemonic: #
is the number sign.)


So the problem with $# is that (like all the rest) it's a global, and its
value can be changed at runtime. (Yes, technically not $[ since 5.000)

And this ability to be changed at runtime interferes with caching the string
values of scalars with floating point values - the caching is part of the
scalar, whereas the "correct" formatting is for the current scope.
(Strictly dynamic scope, but making it lexical scope wouldn't have changed
this).

So it was deprecated, and eventually removed, and all was good. I think
that this reduced a bit of complexity in just one place in sv.c

Oh pants, except for numeric locales, which have the same basic problem -
your formatting of 3.14 might be "3,14" in some places (or some calls)
depending on your locale.

So in the end, this wasn't a win.


$* Set to a non-zero integer value to do multi-line matching
within a string, 0 (or undefined) to tell Perl that it can
assume that strings contain a single line, for the purpose of
optimizing pattern matches. Pattern matches on strings con?
taining multiple newlines can produce confusing results when $*
is 0 or undefined. Default is undefined. (Mnemonic: * matches
multiple things.) This variable influences the interpretation
of only "^" and "$". A literal newline can be searched for even
when "$* == 0".

Use of $* is deprecated in modern Perl, supplanted by the "/s"
and "/m" modifiers on pattern matching.

Assigning a non-numerical value to $* triggers a warning (and
makes $* act if "$* == 0"), while assigning a numerical value


As featured in Ricardo's example.

Again, dynamic, needs to be checked everywhere at runtime - qr// compiles
regexps that can be passed to different scopes, hence unlike the /s and /m
modifiers one can't just attach it to the compiled representation and be
done.

So removing this remove several small instances of code.


$[ The index of the first element in an array, and of the first
character in a substring. Default is 0, but you could theoret?
ically set it to 1 to make Perl behave more like awk (or For?
tran) when subscripting and when evaluating the index() and
substr() functions. (Mnemonic: [ begins subscripts.)

As of release 5 of Perl, assignment to $[ is treated as a com?
piler directive, and cannot influence the behavior of any other
file. (That's why you can only assign compile-time constants
to it.) Its use is highly discouraged.

Note that, unlike other compile-time directives (such as
strict), assignment to $[ can be seen from outer lexical scopes
in the same file. However, you can use local() on it to
strictly bind its value to a lexical block.


OK, not strictly dynamic, but that's not the problem.

*This* one hides a bunch of "fun". Given that substring and array offsets
can be expressed as negative values, how does "1" interact with that?

That was actually reasonably well defined. The real fun was *implementing*
it. The naïve approach is something like `$len + 1 + abs($offset)`.

Problem was that's fine in Perl where values are floating point*, but in C
this needs to be done with integers. Which are probably the largest integer
on the system, and so "largest value plus one" can't be represented.
Hence (IIRC) there was a security bug about this, and then a lot of care
was taken by someone (sorry, I forget whom) to re-write the implementation
to avoid overflow in the corner cases.

And even after this and a lot of staring at it by several others it was
still "no obvious bugs" and not "obviously no bugs"

So getting rid of $[ meant that all this code could go.


So the point that I'd like to make is that there are *some* things that
might be removed to simplify the internals and reduce the support burden,
but *most* existing things don't get in the way, at least at runtime.

Nicholas Clark

* or fake it like they are

On Wed, 07 Apr 2021 15:26:55 +0200, Nicholas Clark <nick@ccl4.org> wrote:

> So the point that I'd like to make is that there are *some* things that
> might be removed to simplify the internals and reduce the support burden,
> but *most* existing things don't get in the way, at least at runtime.

Thanks for adding more detail. I really appreciate that effort to provide tangible evidence for this. :)

A small addendum:

I think it's fine to change the defaults in these cases:

1. when the behavior is a security risk
2. when the behavior is outright broken and subverts expectations and optimally also documentation
3. when actually finding examples of anybody using the behavior is nearly impossible

I think your examples all fall under 3.?

Outside of that, when a huge win can be demonstrated, stuff should be removed, but then i'd prefer it be done by way of deprecating that specific dialect.

--
With regards,
Christian Walde

Op 07-04-2021 om 02:23 schreef Yuki Kimoto:
> 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.


That is my feeling too. "use v7" will be the way to get modern Perl. It
should be and will be a major step in evolving the language and will be
the standard for new Perl code world wide. Using minor versions may take
off, or it may not after that, but that is actually not that important.
As long as v7, v8, etc define a well thought out step forward, that is
probably what people will use, and that will be a boon to Perl.


M4

> On Apr 7, 2021, at 10:31 AM, Christian Walde <walde.christian@gmail.com> wrote:
>
> On Wed, 07 Apr 2021 15:26:55 +0200, Nicholas Clark <nick@ccl4.org> wrote:
>
>> So the point that I'd like to make is that there are *some* things that
>> might be removed to simplify the internals and reduce the support burden,
>> but *most* existing things don't get in the way, at least at runtime.
>
> Thanks for adding more detail. I really appreciate that effort to provide tangible evidence for this. :)
>
> A small addendum:
>
> I think it's fine to change the defaults in these cases:
>
> 1. when the behavior is a security risk
> 2. when the behavior is outright broken and subverts expectations and optimally also documentation
> 3. when actually finding examples of anybody using the behavior is nearly impossible
>
> I think your examples all fall under 3.?
>
> Outside of that, when a huge win can be demonstrated, stuff should be removed, but then i'd prefer it be done by way of deprecating that specific dialect.


I would argue (though it's hard to search for "format" in the issues list) that being able to close 50+ cases would be nice if we could just say: "Formats are removed. this issue is now irrelevant."

For me all of that would fall under #2.

Todd

On Thu, Apr 8, 2021, at 5:18 PM, Todd Rinaldo wrote:
>> Outside of that, when a huge win can be demonstrated, stuff should be removed, but then i'd prefer it be done by way of deprecating that specific dialect.
>
> I would argue (though it's hard to search for "format" in the issues list) that being able to close 50+ cases would be nice if we could just say: "Formats are removed. this issue is now irrelevant."

I think that's true, strictly speaking, but: of the people who use formats, how many would be impacted, and how, if we removed formats? Well, 100% of them would be impacted, and the impact would be "I had to rewrite some code" which (given how formats work) would probably be kind of a pain in the butt. Sometimes a big one, sometimes pretty tiny.

On the other hand, the benefit of closing tickets that we were ignoring *anyway* is pretty darn low.

Christian's #2, changing defaults when they confound users, should be weighed against users confounded. I think we'd find that in general, new users are not reaching for formats. If users say "I'm using formats, and this part was confusing," and we say, "okay, we have ripped out formats," I don't think anybody's going to thank us for that.

--
rjbs

On 4/8/21 9:23 PM, Ricardo Signes wrote:
> On Thu, Apr 8, 2021, at 5:18 PM, Todd Rinaldo wrote:
>>> Outside of that, when a huge win can be demonstrated, stuff should be
>>> removed, but then i'd prefer it be done by way of deprecating that
>>> specific dialect.
>>
>> I would argue (though it's hard to search for "format" in the issues
>> list) that being able to close 50+ cases would be nice if we could
>> just say: "Formats are removed. this issue is now irrelevant."
>
> I think that's true, strictly speaking, but:  of the people who use
> formats, how many would be impacted, and how, if we removed formats?
> Well, 100% of them would be impacted, and the impact would be "I had to
> rewrite some code" which (given how formats work) would probably be kind
> of a pain in the butt.  Sometimes a big one, sometimes pretty tiny.
>
> On the other hand, the benefit of closing tickets that we were ignoring
> /anyway/ is pretty darn low.

Might you have a sampling of such tickets? Please don't read into the
request, I am more curious than anything.

Thank you,
Brett

>
> Christian's #2, changing defaults when they confound users, should be
> weighed against users confounded.  I think we'd find that in general,
> new users are not reaching for formats.  If users say "I'm using
> formats, and this part was confusing," and we say, "okay, we have ripped
> out formats," I don't think anybody's going to thank us for that.
>
> --
> rjbs

On Friday, 9 April 2021, 04:24:34 CEST, Ricardo Signes <perl.p5p@rjbs.manxome.org> wrote:

On Thu, Apr 8, 2021, at 5:18 PM, Todd Rinaldo wrote:


Outside of that, when a huge win can be demonstrated, stuff should be removed, but then i'd prefer it be done by way of deprecating that specific dialect.


Christian's #2, changing defaults when they confound users, should be weighed against users confounded.  I think we'd find that in general, new users are not reaching for formats.  If users say "I'm using formats, and this part was confusing," and we say, "okay, we have ripped out formats," I don't think anybody's going to thank us for that.

Late to the party, not a core dev, and probably shouldn't wade into the lion's den, but I'd like to offer my (obviously biased) thoughts.

I have read and written on the subject of emigration for many years and I having been thinking that those issues are relevant to Perl. Why do people leave a country? There are push factors (war, famine, lack of jobs, discrimination, etc.) and pull factors (climate, jobs, culture, etc.). When push factors are the primary motivation (think "Somalia"), refugees will flee to just about any place that will take them. When pull factors are the primary motivation, people want to go there. The US and France, for example, both have plenty of (very different) pull factors and lots of people want to move to those countries.
It's even stronger for programming languages because there's not mcuh barrier to entry to other languages.
Perl has a lot of push factors (fewer jobs, old-fashioned language, frequently cryptic syntax), but what are the pull factors? I don't mean the pull factors for us. We're not the target audience here. I mean "pull factors for new developers." It's not the CPAN. It's not unicode support. PCRE is nice by most regexes I encounter in the wild aren't much more complicated than /ab(c*)de/. It's a nice glue language, but DevOps chose Ruby instead (why? push factors).

I can name push factors for Perl all day long, but pull factors? And pull factors that overcome the push factors? And make Perl more enticing than alternative languages? I could start listing push/pull factors for Python, but I don't want to start the day silently weeping into my coffee.

So, some points that I think are important:


- If we break back-compat silently, people won't blame the sysadmin who upgraded without checking. They'll blame Perl. That's a new push factor.

- I don't hear other devs saying I won't use Perl because of <insert unpopular feature here>. They say "I won't use Perl because it's Perl." We could use this bullet point to list many, many push factors.

- Perl will die unless we give people a reason to try it again (and I agree that new OOP isn't the solution, but I contend that it's part of it). We need lots of pull factors.


Saying we should just keep Perl as "Perl", maybe remove some cruft is ignoring pull factors. It's saying "I want to go gentle into that good night." Perl will continue it's long slide into irrelevancy and people who enjoy Perl will have to find other ways of paying the bills. Make developers sit up and say "I want that!" When I give intro Raku talks, developers sit up and say "I want that.!" They say that about numerous features. They don't say that about Perl. (That's not saying anything about whether or not Raku will be successful)
So, given the assumption that Perl's push/pull ratio is poor, I contend that only a wholesale, radical upgrade of the language is the only way to save it.

Best,Ovid

On Fri, 09 Apr 2021 10:07:31 +0200, Ovid via perl5-porters <perl5-porters@perl.org> wrote:

> On Friday, 9 April 2021, 04:24:34 CEST, Ricardo Signes <perl.p5p@rjbs.manxome.org> wrote:
>
> On Thu, Apr 8, 2021, at 5:18 PM, Todd Rinaldo wrote:
>>> Outside of that, when a huge win can be demonstrated, stuff should be removed, >>>but then i'd prefer it be done by way of deprecating that specific dialect.
>>
>> Christian's #2, changing defaults when they confound users, should be weighed against users >>confounded. I think we'd find that in general, new users are not reaching for formats. If users >>say "I'm using formats, and this part was confusing," and we say, "okay, we have ripped out >>formats," I don't think anybody's going to thank us for that.
>
> Late to the party, not a core dev, and probably shouldn't wade into the lion's den, but I'd like to offer my >(obviously biased) thoughts.
[...]
> So, given the assumption that Perl's push/pull ratio is poor, I contend that only a wholesale, radical upgrade >of the language is the only way to save it.

Less of a den of lions matter it's a question of what was already discussed. :)

It sounds like you're agreeing with noises made previously, to cite myself here:

"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 to cite Leonerd:

We need to look at who is, and isn't, using Perl currently and
consider whether actually `use VERSION` would help us provide a
better Perl for both of these use-cases, as well as give us a
great way to build a lot of marketing and promotion around that
by pointing out that both kinds of Perl even exist.


Source for both: https://www.nntp.perl.org/group/perl.perl5.porters/2021/03/msg259585.html


--
With regards,
Christian Walde

On Fri, 09 Apr 2021 04:23:43 +0200, Ricardo Signes <perl.p5p@rjbs.manxome.org> wrote:

> On Thu, Apr 8, 2021, at 5:18 PM, Todd Rinaldo wrote:
>>> Outside of that, when a huge win can be demonstrated, stuff should be removed, but >>>then i'd prefer it be done by way of deprecating that specific dialect.
>>
>> I would argue (though it's hard to search for "format" in the issues list) that being able to close 50+ >>cases would be nice if we could just say: "Formats are removed. this issue is now irrelevant."
>
> I think that's true, strictly speaking, but: of the people who use formats, how many would be impacted, and how, if >we removed formats? Well, 100% of them would be impacted, and the impact would be "I had to rewrite some >code" which (given how formats work) would probably be kind of a pain in the butt. Sometimes a big one, >sometimes pretty tiny.
>
> On the other hand, the benefit of closing tickets that we were ignoring anyway is pretty darn low.
>
> Christian's #2, changing defaults when they confound users, should be weighed against users confounded. I think >we'd find that in general, new users are not reaching for formats. If users say "I'm using formats, and this part was >confusing," and we say, "okay, we have ripped out formats," I don't think anybody's going to thank us for that.

100% agree with this, and to add a little more:

My first three points were for changed defaults.

"remove behavior" is a separate concern, as removing behavior only very rarely results in fixed bugs, but usually explicitly in WONTFIX.

--
With regards,
Christian Walde

On Thu, 08 Apr 2021 23:18:43 +0200, Todd Rinaldo <toddr@cpanel.net> wrote:

> I would argue (though it's hard to search for "format" in the issues list) that being able to close 50+ cases would be nice if we could just say: "Formats are removed. this issue is now irrelevant."

One more addendum here.

There's a way to make everyone happy.



Define `use 7;` and up as: "doesn't provide format-related things".

Define missing `use $v;` or one with $v < 7 as: "provides format-related things as they were pre-7".



That way we don't step on any toes of format users, and Leonerd can create new syntax using format-danglies in v7+.

--
With regards,
Christian Walde

On Friday, 9 April 2021, 11:32:55 CEST, Christian Walde <walde.christian@gmail.com> wrote:

> There's a way to make everyone happy.
>
> Define `use 7;` and up as: "doesn't provide format-related things".
>
> Define missing `use $v;` or one with $v < 7 as: "provides format-related things as they were pre-7".
>
> That way we don't step on any toes of format users, and Leonerd can create new syntax using format-danglies in v7+.

I am not sure I understand. Are you suggesting that if you want the benefit of v7 and you want formats, you're out of luck? Or are you suggesting you have to learn more boilerplate by explicitly not using "v7" but writing the boilerplate to get the benefits of v7+formats? That isn't better than what we have, so I think I've misunderstood you.

Best,Ovid
-- IT consulting, training, specializing in Perl, databases, and agile developmenthttp://www.allaroundtheworld.fr/. 
Buy my book! - http://bit.ly/beginning_perl

On Fri, 09 Apr 2021 11:51:33 +0200, Ovid <curtis_ovid_poe@yahoo.com> wrote:

> On Friday, 9 April 2021, 11:32:55 CEST, Christian Walde <walde.christian@gmail.com> wrote:
>
>> There's a way to make everyone happy.
>>
>> Define `use 7;` and up as: "doesn't provide format-related things".
>>
>> Define missing `use $v;` or one with $v < 7 as: "provides format-related things as they were pre-7".
>>
>> That way we don't step on any toes of format users, and Leonerd can create new syntax using format-danglies in v7+.
>
> I am not sure I understand. Are you suggesting that if you want the benefit of v7 and you want formats, you're out of luck? Or are you suggesting you have to learn more boilerplate by explicitly not using "v7" but writing the boilerplate to get the benefits of v7+formats? That isn't better than what we have, so I think I've misunderstood you.

As long as Perl dialects $v < 7 are still implemented in the interpreter you can do:

use 7;

sub do_format {
use 5;
format ...;
write;
}

or

sub do_format {
format ...;
write;
}

use 7;

do_format();

Only once it is decided that dialects $v < 7 be deprecated would those stop to work.

--
With regards,
Christian Walde

On Thu, 08 Apr 2021 22:23:43 -0400
"Ricardo Signes" <perl.p5p@rjbs.manxome.org> wrote:

> On Thu, Apr 8, 2021, at 5:18 PM, Todd Rinaldo wrote:
> >> Outside of that, when a huge win can be demonstrated, stuff should
> >> be removed, but then i'd prefer it be done by way of deprecating
> >> that specific dialect.
> >
> > I would argue (though it's hard to search for "format" in the
> > issues list) that being able to close 50+ cases would be nice if we
> > could just say: "Formats are removed. this issue is now
> > irrelevant."
>
> I think that's true, strictly speaking, but: of the people who use
> formats, how many would be impacted, and how, if we removed formats?
> Well, 100% of them would be impacted, and the impact would be "I had
> to rewrite some code" which (given how formats work) would probably
> be kind of a pain in the butt. Sometimes a big one, sometimes pretty
> tiny.

In terms of eating into syntax we'd like to use for other things,
formats consume two keywords that aren't *that* interesting (`format`
and `write`), and a bunch of variables; some of which we'd quite like
to reclaim for syntax purposes.

I have a branch that provides a (default-on) feature for parsing of the
format-related variables, so that a future perl can simply

no feature 'format_vars';

to get all those back.

https://github.com/Perl/perl5/tree/leonerd/feature-format-vars

--
Paul "LeoNerd" Evans

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

Op 09-04-2021 om 12:09 schreef Christian Walde:
> On Fri, 09 Apr 2021 11:51:33 +0200, Ovid <curtis_ovid_poe@yahoo.com>
> wrote:
>
>> ?? On Friday, 9 April 2021, 11:32:55 CEST, Christian Walde
>> <walde.christian@gmail.com> wrote:
>>
>>> There's a way to make everyone happy.
>>>
>>> Define `use 7;` and up as: "doesn't provide format-related things".
>>>
>>> Define missing `use $v;` or one with $v < 7 as: "provides
>>> format-related things as they were pre-7".
>>>
>>> That way we don't step on any toes of format users, and Leonerd can
>>> create new syntax using format-danglies in v7+.
>>
>> I am not sure I understand. Are you suggesting that if you want the
>> benefit of v7 and you want formats, you're out of luck? Or are you
>> suggesting you have to learn more boilerplate by explicitly not using
>> "v7" but writing the boilerplate to get the benefits of v7+formats?
>> That isn't better than what we have, so I think I've misunderstood you.
>
> As long as Perl dialects $v < 7 are still implemented in the
> interpreter you can do:
>
> ?? use 7;
>
> ?? sub do_format {
> ?????? use 5;
> ?????? format ...;
> ?????? write;
> ?? }
>
> or
>
> ?? sub do_format {
> ?????? format ...;
> ?????? write;
> ?? }
>
> ?? use 7;
>
> ?? do_format();

Or simply

?? use 7;
?? use feature 'format';

?? sub do_format {
?????? format ...;
?????? write;
?? }


> Only once it is decided that dialects $v < 7 be deprecated would those
> stop to work.


Which is decoupled if it is a feature.


HTH,

M4

On Fri, 09 Apr 2021 15:51:02 +0200, Martijn Lievaart <m@rtij.nl> wrote:

> Op 09-04-2021 om 12:09 schreef Christian Walde:
>> On Fri, 09 Apr 2021 11:51:33 +0200, Ovid <curtis_ovid_poe@yahoo.com>
>> wrote:
>>
>>> On Friday, 9 April 2021, 11:32:55 CEST, Christian Walde
>>> <walde.christian@gmail.com> wrote:
>>>
>>>> There's a way to make everyone happy.
>>>>
>>>> Define `use 7;` and up as: "doesn't provide format-related things".
>>>>
>>>> Define missing `use $v;` or one with $v < 7 as: "provides
>>>> format-related things as they were pre-7".
>>>>
>>>> That way we don't step on any toes of format users, and Leonerd can
>>>> create new syntax using format-danglies in v7+.
>>>
>>> I am not sure I understand. Are you suggesting that if you want the
>>> benefit of v7 and you want formats, you're out of luck? Or are you
>>> suggesting you have to learn more boilerplate by explicitly not using
>>> "v7" but writing the boilerplate to get the benefits of v7+formats?
>>> That isn't better than what we have, so I think I've misunderstood you.
>>
>> As long as Perl dialects $v < 7 are still implemented in the
>> interpreter you can do:
>>
>> use 7;
>>
>> sub do_format {
>> use 5;
>> format ...;
>> write;
>> }
>>
>> or
>>
>> sub do_format {
>> format ...;
>> write;
>> }
>>
>> use 7;
>>
>> do_format();
>
> Or simply
>
> use 7;
> use feature 'format';
>
> sub do_format {
> format ...;
> write;
> }
>
>> Only once it is decided that dialects $v < 7 be deprecated would those
>> stop to work.
>
> Which is decoupled if it is a feature.

Also nice, yes. :)

Or LeoNerd's work here. https://www.nntp.perl.org/group/perl.perl5.porters/2021/04/msg259769.html

Many ways to slice this carrot. :D

--
With regards,
Christian Walde

Everyone is talking on the assumption that Perl is declining.

The feeling I get in Japan is that Perl has been recovering little by
little since around 2018.

The loud voice on the surface of the web may not be what it really is.

2021?4?9?(?) 23:30 Christian Walde <walde.christian@gmail.com>:

> On Fri, 09 Apr 2021 15:51:02 +0200, Martijn Lievaart <m@rtij.nl> wrote:
>
> > Op 09-04-2021 om 12:09 schreef Christian Walde:
> >> On Fri, 09 Apr 2021 11:51:33 +0200, Ovid <curtis_ovid_poe@yahoo.com>
> >> wrote:
> >>
> >>> On Friday, 9 April 2021, 11:32:55 CEST, Christian Walde
> >>> <walde.christian@gmail.com> wrote:
> >>>
> >>>> There's a way to make everyone happy.
> >>>>
> >>>> Define `use 7;` and up as: "doesn't provide format-related things".
> >>>>
> >>>> Define missing `use $v;` or one with $v < 7 as: "provides
> >>>> format-related things as they were pre-7".
> >>>>
> >>>> That way we don't step on any toes of format users, and Leonerd can
> >>>> create new syntax using format-danglies in v7+.
> >>>
> >>> I am not sure I understand. Are you suggesting that if you want the
> >>> benefit of v7 and you want formats, you're out of luck? Or are you
> >>> suggesting you have to learn more boilerplate by explicitly not using
> >>> "v7" but writing the boilerplate to get the benefits of v7+formats?
> >>> That isn't better than what we have, so I think I've misunderstood you.
> >>
> >> As long as Perl dialects $v < 7 are still implemented in the
> >> interpreter you can do:
> >>
> >> use 7;
> >>
> >> sub do_format {
> >> use 5;
> >> format ...;
> >> write;
> >> }
> >>
> >> or
> >>
> >> sub do_format {
> >> format ...;
> >> write;
> >> }
> >>
> >> use 7;
> >>
> >> do_format();
> >
> > Or simply
> >
> > use 7;
> > use feature 'format';
> >
> > sub do_format {
> > format ...;
> > write;
> > }
> >
> >> Only once it is decided that dialects $v < 7 be deprecated would those
> >> stop to work.
> >
> > Which is decoupled if it is a feature.
>
> Also nice, yes. :)
>
> Or LeoNerd's work here.
> https://www.nntp.perl.org/group/perl.perl5.porters/2021/04/msg259769.html
>
> Many ways to slice this carrot. :D
>
> --
> With regards,
> Christian Walde
>

On Sat, 27 Mar 2021 16:49:15 -0400, "Ricardo Signes"
<perl.p5p@rjbs.manxome.org> wrote:

> So I think, after saying all this, the first big question is: Is
> there a general agreement that there are kinds of changes we've made
> (or will make) to the language that we can ease into making the
> default, through some multi-step process? We may need to hash out
> individual changes' paths forward, but if there is an overwhelming
> opposition to changing these sorts of defaults *at all*, then I think
> a lot of this conversation has to be entirely reconsidered.

I already gave a +1 earlier, but I like to add

"Considering deprecation of an existing feature/function is beneficial
to a new feature/function, check if it possible to provide a clear
path that can be used to replace the old functionality."

The best way (imho) would be a clear warning/error message showing the
cause and the alternative. An imaginary example

say $foo.method ($arg);

Syntax error: You are using "." after object ?$foo?, but ?$foo? does
not support stringification. Maybe you meant to use "->"

--
H.Merijn Brand https://tux.nl Perl Monger http://amsterdam.pm.org/
using perl5.00307 .. 5.33 porting perl5 on HP-UX, AIX, and Linux
https://tux.nl/email.html http://qa.perl.org https://www.test-smoke.org

* "H.Merijn Brand via perl5-porters" <perl5-porters@perl.org> [2021-04-12T10:39:22]
> I already gave a +1 earlier, but I like to add
>
> "Considering deprecation of an existing feature/function is beneficial
> to a new feature/function, check if it possible to provide a clear
> path that can be used to replace the old functionality."
>
> The best way (imho) would be a clear warning/error message showing the
> cause and the alternative. An imaginary example

I completely agree. You called out, recently, the exemplary diagnostic output
of Raku. We should strive to provide better diagnostics *in general*, but also
especially when we're bringing change that isn't opt-in.

We'll reduce inconvenience if we can always provide something like, at minimum,
"We are deprecating Perl's support for foozles. Consider using the new blorts
system. You can find more at [this] resource."

--
rjbs

On Saturday, 17 April 2021, 19:35:57 CEST, Ricardo Signes <perl.p5p@rjbs.manxome.org> wrote:
> I completely agree.  You called out, recently, the exemplary diagnostic output
> of Raku.  We should strive to provide better diagnostics *in general*, but also
> especially when we're bringing change that isn't opt-in.

If that's to be done, it might be interesting to rethink diagnostics in terms of the larger context and not just the messages. For example, a core exception system would be good. First pass could be converting all diagnostics to exceptions and when we get a "use of uninitialized value in $foo" it would be interest if the developer could rerun the program:
    PERL_DIAG=verbose,trace perl path/to/fail.pl
Note that I'm not suggesting that as an interface! It's the concept which I think is important here. Different developers have different needs and I almost  never want extra info in diagnostics (though I'd often kill for a stacktrace). But if I get a "bizarre copy of array in list assignment" error, I absolutely want more info.

Best,Ovid
-- IT consulting, training, specializing in Perl, databases, and agile developmenthttp://www.allaroundtheworld.fr/. 
Buy my book! - http://bit.ly/beginning_perl

On Sun, Apr 18, 2021, at 2:28 AM, Ovid wrote:
> On Saturday, 17 April 2021, 19:35:57 CEST, Ricardo Signes <perl.p5p@rjbs.manxome.org> wrote:
>
>> I completely agree. You called out, recently, the exemplary diagnostic output
>> of Raku. We should strive to provide better diagnostics *in general*, but also
>> especially when we're bringing change that isn't opt-in.
>
> If that's to be done, it might be interesting to rethink diagnostics in terms of the larger context and not just the messages.

I agree, but I'd rather not let the better be the enemy of the "good enough for now." I put in some work, ages ago, to try to move us toward more structured errors and diagnostics, and it more or less went nowhere. While I'm happy to make another go of it, improving the text of text warnings is an interim good.

--
rjbs