Mailing List Archive

The Purpose of P5P
The purpose of P5P is "the development and maintenance of Perl" — easy, right? The "perlpolicy" doc expands on this in some areas, but in PSC discussions we still found ourselves revisiting this, and I tried various times to write up our thoughts.

Various points related to this have come up in discussions on P5P, so I think it might be helpful to see how much of this we agree on. Think of this as P5P's mission statement, or manifesto.

We think our priorities are, in decreasing order:

  1. Deal with security issues promptly (Security).
  2. Keep perl code running (Reliability).
  3. Improve the language for developers who are maintaining existing code or writing new code (Effectiveness).
  4. Provide reasons for people to return to Perl, or to start writing Perl (Growth).

One of the points of contention is the priority of Reliability vs Effectiveness: there's a lot of old code out there that no-one cares about (any more) – do we really think keeping that code running is more important than extending the language to support today's active developers? Let's look at the priorities in turn, and then revisit this question.


Security

If security bugs are reported or discovered, then they are given appropriate priority, and they will often outweigh other considerations. When addressing security issues, we hope that the fix won't impact the other considerations. Sometimes that's not possible though, and security wins out. For example, "no . in @INC".

This is not only "fix security bugs", but also "try and prevent security bugs in Perl".


Reliability

Once someone has written Perl code and it has been "put into production", we should do our best to ensure that it continues to work when they upgrade to a new version of Perl.  Perl has a reputation for backward compatibility, earned over decades.  That reputation is valuable, and we should only spend that capital in return for something sufficiently valuable to warrant it.

  - Aim for backwards compatibility when introducing new features.
  - Fix bugs, while remembering that sometimes bugs become relied upon, and fixing those ones can break code.
  - Be mindful of the breakage of CPAN code, which is our best proxy for how proprietary code may break.

This doesn't mean that we must be 100% backwards compatible and never break any CPAN modules, but that we should only deviate from that when we've carefully considered the impact. If a change would break three twenty-year old modules on CPAN that no-one seems to use, that's a different proposition from breaking a module that's far up the CPAN River.

Furthermore, if we do decide that it's ok to break something, we should try to reduce the inconvenience it causes by providing advance notice, clear documentation, and, when possible, tooling or other assistance.

It's easy to think that perl is just about what you do in perl, but over the years perl has been used, and is still being used for a broad range of things. I think it would help us to have a shared picture of those, but that's for another day.


Effectiveness

This is about continuously evolving and improving Perl, to make the lives of active Perl developers better: increase productivity, prevent common bugs, improve performance, etc.

Some of this is about filling gaps in the features provided by Perl, which developers may be used to from other languages.

This can also be small incremental improvements in the language, particularly where we have the evidence to support them, for example where people regularly make the same mistake, or there's an commonly used idiom. To borrow a phrase from Nicholas, if we think something should be in the FAQ, then we should also consider whether it's something the language should provide.

This might also be by including additional modules in the core. There are differing thoughts here: some want to see more batteries included, but every additional core module is additional maintenance and release work.

When adding new features or feature bundles, we also need to think about all the existing code out there and how we help it bridge the gap without requiring a stressful flag-day effort.


Growth

Many of the features that we'd like to see in Perl are things that have been provided by plenty of other languages for years. We're playing catch-up. Many of these features aren't likely to attract significant numbers of new developers, but the aggregate effect of them will hopefully bring us up to par.

Considering the leaky bucket model, some of the things we can do for growth are really about reducing leakage.

That said, there are no doubt changes we could make to give Perl an edge over other languages, some of which have been called for in recent discussions. But we have to remember the resources we have available and that we're a volunteer organisation.

What will really attract new Perl developers in greater numbers is CPAN distributions for emerging domains. Lots of people have learned Python because of the machine learning support. There's a chicken and egg problem here, but it's not one for P5P to try and solve.

It's also tempting to bundle Effectiveness and Growth together, but I think it's worth separating them, as (a) I think the things that will attract significant numbers of developers aren't the language, and (b) some significant changes to the language possibly would attract new developers, but at the cost of existing developers, which in general isn't a trade-off I think we should make.


Final Thoughts

These aren't gates, but an order in which we should consider things. It doesn't mean that we can't consider changes that will break things, but that we have to make an informed decision, and that some considerations are more important than others. A sexy new feature that might attract hordes of new developers won't be acceptable if it makes Perl less secure, or inconveniences significant numbers of our existing users or current developers.

None of this is surprising or new. It's an attempt to write down what I think most people feel. Some of these ideas are already built-in to how new capabilities are rolled out, with feature guards, for example, and the "use vN" version bundles.

So, should reliability of old code come ahead of the e of current developers? There's surely some existing perl code in the wild that no one cares about any more (let's call it "abandoned code"), and if we broke it, its owners wouldn't care. But we've no way of identifying all the abandoned code, so it's unrealistic that we could define changes that would only break abandoned code. And if we tried this, then people would naturally worry that at some point in the future we might sacrifice their code's reliability to the new feature gods, and we'd lose perhaps the strongest pillar of Perl's reputation.

In addition to the priorities outlined here, we think there are principles that we apply as well. For example, in designing new language features, we should ensure they are consistent with the existing language.
Re: The Purpose of P5P [ In reply to ]
Another comprehensive report from NeilB!

I say that we can have wildly new capabilities that completely break the
existing language if they are safely controlled by a *use* and *no*
pragama. As in: *no sigils; use autoderef; * Developers care deeply about
the language they use. We will not attract new developers with the existing
antiquated syntax. Nor should we be allow some small group to dictate what
the language is when the *use* and *no* pragmata can safely allow new
lexers, parsers and code generators to be slotted seamlessly into position
without disrupting existing users*. *We can have the best of both worlds:
stability and simultaneously the "more than one way to do it ness" that
brought people to Perl in the first place. Software represents the
organization that produces it: we seem to be incapable as an organization
of exploiting the good work already done with pragmata as effectively as we
should because we get endlessly bogged down in use *v7*. Are we really
saying that our only ambition is to fade securely and reliably away into
the very last syllable of recorded time?

On Sat, Apr 10, 2021 at 9:14 PM Neil Bowers <neilb@neilb.org> wrote:

> The purpose of P5P is "the development and maintenance of Perl" — easy,
> right? The "perlpolicy" doc expands on this in some areas, but in PSC
> discussions we still found ourselves revisiting this, and I tried various
> times to write up our thoughts.
>
> Various points related to this have come up in discussions on P5P, so I
> think it might be helpful to see how much of this we agree on. Think of
> this as P5P's mission statement, or manifesto.
>
> We think our priorities are, in decreasing order:
>
> 1. Deal with security issues promptly (Security).
> 2. Keep perl code running (Reliability).
> 3. Improve the language for developers who are maintaining existing code
> or writing new code (Effectiveness).
> 4. Provide reasons for people to return to Perl, or to start writing
> Perl (Growth).
>
> One of the points of contention is the priority of Reliability vs
> Effectiveness: there's a lot of old code out there that no-one cares about
> (any more) – do we really think keeping that code running is more important
> than extending the language to support today's active developers? Let's
> look at the priorities in turn, and then revisit this question.
>
>
> *Security*
>
> If security bugs are reported or discovered, then they are given
> appropriate priority, and they will often outweigh other considerations.
> When addressing security issues, we hope that the fix won't impact the
> other considerations. Sometimes that's not possible though, and security
> wins out. For example, "no . in @INC".
>
> This is not only "fix security bugs", but also "try and prevent security
> bugs in Perl".
>
>
> *Reliability*
>
> Once someone has written Perl code and it has been "put into production",
> we should do our best to ensure that it continues to work when they upgrade
> to a new version of Perl. Perl has a reputation for backward
> compatibility, earned over decades. That reputation is valuable, and we
> should only spend that capital in return for something sufficiently
> valuable to warrant it.
>
> - Aim for backwards compatibility when introducing new features.
> - Fix bugs, while remembering that sometimes bugs become relied upon,
> and fixing those ones can break code.
> - Be mindful of the breakage of CPAN code, which is our best proxy for
> how proprietary code may break.
>
> This doesn't mean that we must be 100% backwards compatible and never
> break any CPAN modules, but that we should only deviate from that when
> we've carefully considered the impact. If a change would break three
> twenty-year old modules on CPAN that no-one seems to use, that's a
> different proposition from breaking a module that's far up the CPAN River.
>
> Furthermore, if we do decide that it's ok to break something, we should
> try to reduce the inconvenience it causes by providing advance notice,
> clear documentation, and, when possible, tooling or other assistance.
>
> It's easy to think that perl is just about what you do in perl, but over
> the years perl has been used, and is still being used for a broad range of
> things. I think it would help us to have a shared picture of those, but
> that's for another day.
>
>
> *Effectiveness*
>
> This is about continuously evolving and improving Perl, to make the lives
> of active Perl developers better: increase productivity, prevent common
> bugs, improve performance, etc.
>
> Some of this is about filling gaps in the features provided by Perl, which
> developers may be used to from other languages.
>
> This can also be small incremental improvements in the language,
> particularly where we have the evidence to support them, for example where
> people regularly make the same mistake, or there's an commonly used idiom.
> To borrow a phrase from Nicholas, if we think something should be in the
> FAQ, then we should also consider whether it's something the language
> should provide.
>
> This might also be by including additional modules in the core. There are
> differing thoughts here: some want to see more batteries included, but
> every additional core module is additional maintenance and release work.
>
> When adding new features or feature bundles, we also need to think about
> all the existing code out there and how we help it bridge the gap without
> requiring a stressful flag-day effort.
>
>
> *Growth*
>
> Many of the features that we'd like to see in Perl are things that have
> been provided by plenty of other languages for years. We're playing
> catch-up. Many of these features aren't likely to attract significant
> numbers of new developers, but the aggregate effect of them will hopefully
> bring us up to par.
>
> Considering the leaky bucket model, some of the things we can do for
> growth are really about reducing leakage.
>
> That said, there are no doubt changes we could make to give Perl an edge
> over other languages, some of which have been called for in recent
> discussions. But we have to remember the resources we have available and
> that we're a volunteer organisation.
>
> What will really attract new Perl developers in greater numbers is CPAN
> distributions for emerging domains. Lots of people have learned Python
> because of the machine learning support. There's a chicken and egg problem
> here, but it's not one for P5P to try and solve.
>
> It's also tempting to bundle Effectiveness and Growth together, but I
> think it's worth separating them, as (a) I think the things that will
> attract significant numbers of developers aren't the language, and (b) some
> significant changes to the language possibly would attract new developers,
> but at the cost of existing developers, which in general isn't a trade-off
> I think we should make.
>
>
> *Final Thoughts*
>
> These aren't gates, but an order in which we should consider things. It
> doesn't mean that we can't consider changes that will break things, but
> that we have to make an informed decision, and that some considerations are
> more important than others. A sexy new feature that might attract hordes of
> new developers won't be acceptable if it makes Perl less secure, or
> inconveniences significant numbers of our existing users or current
> developers.
>
> None of this is surprising or new. It's an attempt to write down what I
> think most people feel. Some of these ideas are already built-in to how new
> capabilities are rolled out, with feature guards, for example, and the "use
> vN" version bundles.
>
> So, should reliability of old code come ahead of the e of current
> developers? There's surely some existing perl code in the wild that no one
> cares about any more (let's call it "abandoned code"), and if we broke it,
> its owners wouldn't care. But we've no way of identifying all the abandoned
> code, so it's unrealistic that we could define changes that would only
> break abandoned code. And if we tried this, then people would naturally
> worry that at some point in the future we might sacrifice their code's
> reliability to the new feature gods, and we'd lose perhaps the strongest
> pillar of Perl's reputation.
>
> In addition to the priorities outlined here, we think there are principles
> that we apply as well. For example, in designing new language features, we
> should ensure they are consistent with the existing language.
>


--
Thanks,

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

Philip R Brenan <https://metacpan.org/author/PRBRENAN>
Re: The Purpose of P5P [ In reply to ]
On Sat, 10 Apr 2021 22:14:13 +0200, Neil Bowers <neilb@neilb.org> wrote:

> For example, in designing new language features, we should ensure they are consistent with the existing language.

You know, thinking about this ...

I find it interesting that certain desires regarding trim appear to be diametrically opposed to the desires regarding changed-defaults, despite coming from roughly the same source.

For trim the conclusion appeared to be: Make sure trim is maximally consistent with the past, even if it would end up surprising some newbies.

For changed-defaults it appeared to be: Disregard consistency with the past, and change it, for the sake of the newbies.

I'm not drawing any conclusion regarding intent here, it just popped out to me while reading.



Also, i absolutely enjoy these things you write together and while i don't have a lot to comment on as they're mostly "what we think" and i see very little objectionable ... i feel it's not quite right to let them be only on the mailing list and let them drift in the past.

I'd like to see them preserved in a form that is more referrable and that is more likely to be stumbled upon when interacting with the perl source code and p5p.

Maybe something like putting them in pod files and including links to them in mailing list welcome mails?


--
With regards,
Christian Walde
Re: The Purpose of P5P [ In reply to ]
On Sat, 10 Apr 2021 22:44:27 +0200, Philip R Brenan <philiprbrenan@gmail.com> wrote:

> Another comprehensive report from NeilB!
>
> I say that we can have wildly new capabilities that completely break the existing language if they are safely >controlled by a use and no pragama. As in: no sigils; use autoderef; Developers care deeply about the >language they use. We will not attract new developers with the existing antiquated syntax. Nor should we be allow >some small group to dictate what the language is when the use and no pragmata can safely allow new lexers, >parsers and code generators to be slotted seamlessly into position without disrupting existing users. We can have >the best of both worlds: stability and simultaneously the "more than one way to do it ness" that brought people to >Perl in the first place. Software represents the organization that produces it: we seem to be incapable as an >organization of exploiting the good work already done with pragmata as effectively as we should because we get >endlessly bogged down in use v7. Are we really saying that our only ambition is to fade
> securely and reliably away >into the very last syllable of recorded time?


Most, if not all, of what you speak to already exists as feature.pm.



Please do note that the "bogging down" around `use 7;` hasn't been the question of "what's in it", but "do we do it or not?"

Some people have tentatively poked at what to put into new defaults, but the tension there stems from a simple fact:

If you want to change the details without versioning, you must keep the defaults changing as little as possible, on account of possible damage by changing defaults under people's butts.

If you agree to do it via versioning you can throw the whole kitchen into `use 7;`, and you actually must, in order to entice people to use it. Another good aspect of versioning is also that you *can* throw everything in because you can easily disable things again if they turn out bad.



Putting features behind pragmata is orthogonal to that, an extra feature, and already has prior work via feature.pm, and can even modify the settings activated by `use 7;`.
Re: The Purpose of P5P [ In reply to ]
The absence of trim() in Perl is a powerful incentive to the new Perl
programmer to explore CPAN to find and choose a function that meets their
exact
needs or to start learning about regular expressions. Closing off these
segways
to some of the most important parts of Perl would be a pedagogical disaster.

The discovery of:

use Data::Dump qw(dump);

amongst a number of variants on the theme on CPAN changed my attitude to
Perl from "this is a complete waste of time when we have PL1" to "this can
save
me a lot of time" and "I wonder if they have anything else this useful on
CPAN?"
- I have been using dump daily ever since as it is so much easier than using
the debugger.

dump should set the minimum bar for changes to the Perl language as
delineated
in the latest PSC report distributed by NeilB. For something to be
included in
the base language it needs to be way better than dump. If dump can live on
CPAN
then so can trim. Likewise try/catch. Both set the bar too low - if they
should be included then so should many other much more deserving
capabilities
present in CPAN. The argument "people have asked for it" should be countered
with "we look forward to seeing their contribution to CPAN soon".

Some features cannot be implemented reliably on CPAN. For example making
sigils into operators so they can become optional. Such features will
require
the use of new orthogonal capabilities in the base language. AUTOLOAD lets
us
have several competing OO systems while being useful in many other contexts
as
well - all for the price of one small extension to Perl - one giant leap
forward
for all Perl kind.

On Sat, Apr 10, 2021 at 9:14 PM Neil Bowers <neilb@neilb.org> wrote:

> The purpose of P5P is "the development and maintenance of Perl" — easy,
> right? The "perlpolicy" doc expands on this in some areas, but in PSC
> discussions we still found ourselves revisiting this, and I tried various
> times to write up our thoughts.
>
> Various points related to this have come up in discussions on P5P, so I
> think it might be helpful to see how much of this we agree on. Think of
> this as P5P's mission statement, or manifesto.
>
> We think our priorities are, in decreasing order:
>
> 1. Deal with security issues promptly (Security).
> 2. Keep perl code running (Reliability).
> 3. Improve the language for developers who are maintaining existing code
> or writing new code (Effectiveness).
> 4. Provide reasons for people to return to Perl, or to start writing
> Perl (Growth).
>
> One of the points of contention is the priority of Reliability vs
> Effectiveness: there's a lot of old code out there that no-one cares about
> (any more) – do we really think keeping that code running is more important
> than extending the language to support today's active developers? Let's
> look at the priorities in turn, and then revisit this question.
>
>
> *Security*
>
> If security bugs are reported or discovered, then they are given
> appropriate priority, and they will often outweigh other considerations.
> When addressing security issues, we hope that the fix won't impact the
> other considerations. Sometimes that's not possible though, and security
> wins out. For example, "no . in @INC".
>
> This is not only "fix security bugs", but also "try and prevent security
> bugs in Perl".
>
>
> *Reliability*
>
> Once someone has written Perl code and it has been "put into production",
> we should do our best to ensure that it continues to work when they upgrade
> to a new version of Perl. Perl has a reputation for backward
> compatibility, earned over decades. That reputation is valuable, and we
> should only spend that capital in return for something sufficiently
> valuable to warrant it.
>
> - Aim for backwards compatibility when introducing new features.
> - Fix bugs, while remembering that sometimes bugs become relied upon,
> and fixing those ones can break code.
> - Be mindful of the breakage of CPAN code, which is our best proxy for
> how proprietary code may break.
>
> This doesn't mean that we must be 100% backwards compatible and never
> break any CPAN modules, but that we should only deviate from that when
> we've carefully considered the impact. If a change would break three
> twenty-year old modules on CPAN that no-one seems to use, that's a
> different proposition from breaking a module that's far up the CPAN River.
>
> Furthermore, if we do decide that it's ok to break something, we should
> try to reduce the inconvenience it causes by providing advance notice,
> clear documentation, and, when possible, tooling or other assistance.
>
> It's easy to think that perl is just about what you do in perl, but over
> the years perl has been used, and is still being used for a broad range of
> things. I think it would help us to have a shared picture of those, but
> that's for another day.
>
>
> *Effectiveness*
>
> This is about continuously evolving and improving Perl, to make the lives
> of active Perl developers better: increase productivity, prevent common
> bugs, improve performance, etc.
>
> Some of this is about filling gaps in the features provided by Perl, which
> developers may be used to from other languages.
>
> This can also be small incremental improvements in the language,
> particularly where we have the evidence to support them, for example where
> people regularly make the same mistake, or there's an commonly used idiom.
> To borrow a phrase from Nicholas, if we think something should be in the
> FAQ, then we should also consider whether it's something the language
> should provide.
>
> This might also be by including additional modules in the core. There are
> differing thoughts here: some want to see more batteries included, but
> every additional core module is additional maintenance and release work.
>
> When adding new features or feature bundles, we also need to think about
> all the existing code out there and how we help it bridge the gap without
> requiring a stressful flag-day effort.
>
>
> *Growth*
>
> Many of the features that we'd like to see in Perl are things that have
> been provided by plenty of other languages for years. We're playing
> catch-up. Many of these features aren't likely to attract significant
> numbers of new developers, but the aggregate effect of them will hopefully
> bring us up to par.
>
> Considering the leaky bucket model, some of the things we can do for
> growth are really about reducing leakage.
>
> That said, there are no doubt changes we could make to give Perl an edge
> over other languages, some of which have been called for in recent
> discussions. But we have to remember the resources we have available and
> that we're a volunteer organisation.
>
> What will really attract new Perl developers in greater numbers is CPAN
> distributions for emerging domains. Lots of people have learned Python
> because of the machine learning support. There's a chicken and egg problem
> here, but it's not one for P5P to try and solve.
>
> It's also tempting to bundle Effectiveness and Growth together, but I
> think it's worth separating them, as (a) I think the things that will
> attract significant numbers of developers aren't the language, and (b) some
> significant changes to the language possibly would attract new developers,
> but at the cost of existing developers, which in general isn't a trade-off
> I think we should make.
>
>
> *Final Thoughts*
>
> These aren't gates, but an order in which we should consider things. It
> doesn't mean that we can't consider changes that will break things, but
> that we have to make an informed decision, and that some considerations are
> more important than others. A sexy new feature that might attract hordes of
> new developers won't be acceptable if it makes Perl less secure, or
> inconveniences significant numbers of our existing users or current
> developers.
>
> None of this is surprising or new. It's an attempt to write down what I
> think most people feel. Some of these ideas are already built-in to how new
> capabilities are rolled out, with feature guards, for example, and the "use
> vN" version bundles.
>
> So, should reliability of old code come ahead of the e of current
> developers? There's surely some existing perl code in the wild that no one
> cares about any more (let's call it "abandoned code"), and if we broke it,
> its owners wouldn't care. But we've no way of identifying all the abandoned
> code, so it's unrealistic that we could define changes that would only
> break abandoned code. And if we tried this, then people would naturally
> worry that at some point in the future we might sacrifice their code's
> reliability to the new feature gods, and we'd lose perhaps the strongest
> pillar of Perl's reputation.
>
> In addition to the priorities outlined here, we think there are principles
> that we apply as well. For example, in designing new language features, we
> should ensure they are consistent with the existing language.
>


--
Thanks,

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

Philip R Brenan <https://metacpan.org/author/PRBRENAN>
Re: The Purpose of P5P [ In reply to ]
On Sun, Apr 11, 2021, at 7:00 PM, Philip R Brenan wrote:
> For example making sigils into operators so they can become optional.

This is not happening.

--
rjbs
Re: The Purpose of P5P [ In reply to ]
On Sat, Apr 10, 2021, at 6:41 PM, Christian Walde wrote:
> For trim the conclusion appeared to be: Make sure trim is maximally consistent with the past, even if it would end up surprising some newbies.

That's not really the sentiment. Whether or not it's *correct*, it was more like: it will be easy to know chop or chomp, then encounter trim, and be surprised. This is about surprise to both new and longstanding programmers. Similarly, to learn trim, then encounter chomp, and to be surprised could befall new Perl programmers. So the concern was not direct for either old or new, but rather about minimizing surprise given the constraints of existing parts of the language.

--
rjbs
Re: The Purpose of P5P [ In reply to ]
On Mon, 12 Apr 2021 01:46:17 +0200, Ricardo Signes <perl.p5p@rjbs.manxome.org> wrote:

> On Sat, Apr 10, 2021, at 6:41 PM, Christian Walde wrote:
>> For trim the conclusion appeared to be: Make sure trim is maximally consistent with the past, even if it >>would end up surprising some newbies.
>
> That's not really the sentiment. Whether or not it's correct, it was more like: it will be easy to know chop or >chomp, then encounter trim, and be surprised. This is about surprise to both new and longstanding programmers. >Similarly, to learn trim, then encounter chomp, and to be surprised could befall new Perl programmers. So the >concern was not direct for either old or new, but rather about minimizing surprise given the constraints of existing >parts of the language.
>
> --rjbs

That makes more sense, thanks for explaining. :)

--
With regards,
Christian Walde
Re: The Purpose of P5P [ In reply to ]
On Mon, 12 Apr 2021 00:00:16 +0100, Philip R Brenan
<philiprbrenan@gmail.com> wrote:

> The absence of trim() in Perl is a powerful incentive to the new Perl
> programmer to explore CPAN to find and choose a function that meets
> their exact needs or to start learning about regular expressions.

That is personal. I'm working with perl as from version 4.016 and I
never missed trim, nor did I ever write a sub to do so.

So I doubt if "powerful incentive" is correct in that sentence

New users (IMHO) would be more invited to use our language if we
supported full-threading, signatures, catch and other features people
are working on.

Developers did not leave perl because we did not have trim.

maybe that is just my view

One reason I like raku is because it has the best error messages I have
ever seen, which is an enormous help when learning a new language. Try
to compare that to the stack traces in java.

> Closing off these segways to some of the most important parts of Perl
> would be a pedagogical disaster.
>
> The discovery of:
>
> use Data::Dump qw(dump);
>
> amongst a number of variants on the theme on CPAN changed my attitude
> to Perl from "this is a complete waste of time when we have PL1" to
> "this can save me a lot of time" and "I wonder if they have anything
> else this useful on CPAN?"

Ask the community and you will get many answers. Note that there are
many dumper modules on CPAN which also shows that not everyone expects
the same from a Dumper module. That is the power of perl too.

> - I have been using dump daily ever since as it is so much easier
> than using the debugger.

Using Data::Peek::DDumper for debugging, I have to agree with you. But
there are many different problems to solve in programming land, and
sometimes a debugger is the best tool, and sometimes a print/dump
statement is the preferred way.

e.g If a script would need 3 hours to *start* processing, I would
consider a method for debugging that allows me to connect to a running
process as gdb provides over adding a print/dump line and starting all
over.

> dump should set the minimum bar for changes to the Perl language as
> delineated in the latest PSC report distributed by NeilB. For
> something to be included in the base language it needs to be way
> better than dump.

As I described above: you cannot define "better" for something as
low-level as dump, as there are too many opinions. Besides, all
possible alternatives already live on CPAN (well, you could write your
own (n+1)th).

> If dump can live on CPAN then so can trim.

True

> Likewise try/catch.

But not this. This hooks into deep core business and requires a lot of
knowledge (trim does not). You are comparing a firecracker to a moon
missile.

> Both set the bar too low - if they should be included then so should
> many other much more deserving capabilities present in CPAN.

That is for the PSC to decide on. Not you.

> The argument "people have asked for it" should be countered with "we
> look forward to seeing their contribution to CPAN soon".

arguably, yes, but many things are not possible on CPAN (yet)

> Some features cannot be implemented reliably on CPAN. For example
> making sigils into operators so they can become optional.

I sincerely hope that this will never happen. I would even be in favor
of building a core guard to prevent that. If that is something you
really want, choose a different language.

> Such features will require the use of new orthogonal capabilities in
> the base language. AUTOLOAD lets us have several competing OO systems
> while being useful in many other contexts as well - all for the price
> of one small extension to Perl - one giant leap forward for all Perl
> kind.
>
> On Sat, Apr 10, 2021 at 9:14 PM Neil Bowers <neilb@neilb.org> wrote:
>
> > The purpose of P5P is "the development and maintenance of Perl" —
> > easy, right? The "perlpolicy" doc expands on this in some areas,
> > but in PSC discussions we still found ourselves revisiting this,
> > and I tried various times to write up our thoughts.
> >
> > Various points related to this have come up in discussions on P5P,
> > so I think it might be helpful to see how much of this we agree on.
> > Think of this as P5P's mission statement, or manifesto.
> >
> > We think our priorities are, in decreasing order:
> >
> > 1. Deal with security issues promptly (Security).
> > 2. Keep perl code running (Reliability).
> > 3. Improve the language for developers who are maintaining
> > existing code or writing new code (Effectiveness). 4. Provide
> > reasons for people to return to Perl, or to start writing Perl
> > (Growth).
> >
> > One of the points of contention is the priority of Reliability vs
> > Effectiveness: there's a lot of old code out there that no-one
> > cares about (any more) – do we really think keeping that code
> > running is more important than extending the language to support
> > today's active developers? Let's look at the priorities in turn,
> > and then revisit this question.
> >
> >
> > *Security*
> >
> > If security bugs are reported or discovered, then they are given
> > appropriate priority, and they will often outweigh other
> > considerations. When addressing security issues, we hope that the
> > fix won't impact the other considerations. Sometimes that's not
> > possible though, and security wins out. For example, "no . in @INC".
> >
> > This is not only "fix security bugs", but also "try and prevent
> > security bugs in Perl".
> >
> >
> > *Reliability*
> >
> > Once someone has written Perl code and it has been "put into
> > production", we should do our best to ensure that it continues to
> > work when they upgrade to a new version of Perl. Perl has a
> > reputation for backward compatibility, earned over decades. That
> > reputation is valuable, and we should only spend that capital in
> > return for something sufficiently valuable to warrant it.
> >
> > - Aim for backwards compatibility when introducing new features.
> > - Fix bugs, while remembering that sometimes bugs become relied
> > upon, and fixing those ones can break code.
> > - Be mindful of the breakage of CPAN code, which is our best
> > proxy for how proprietary code may break.
> >
> > This doesn't mean that we must be 100% backwards compatible and
> > never break any CPAN modules, but that we should only deviate from
> > that when we've carefully considered the impact. If a change would
> > break three twenty-year old modules on CPAN that no-one seems to
> > use, that's a different proposition from breaking a module that's
> > far up the CPAN River.
> >
> > Furthermore, if we do decide that it's ok to break something, we
> > should try to reduce the inconvenience it causes by providing
> > advance notice, clear documentation, and, when possible, tooling or
> > other assistance.
> >
> > It's easy to think that perl is just about what you do in perl, but
> > over the years perl has been used, and is still being used for a
> > broad range of things. I think it would help us to have a shared
> > picture of those, but that's for another day.
> >
> >
> > *Effectiveness*
> >
> > This is about continuously evolving and improving Perl, to make the
> > lives of active Perl developers better: increase productivity,
> > prevent common bugs, improve performance, etc.
> >
> > Some of this is about filling gaps in the features provided by
> > Perl, which developers may be used to from other languages.
> >
> > This can also be small incremental improvements in the language,
> > particularly where we have the evidence to support them, for
> > example where people regularly make the same mistake, or there's an
> > commonly used idiom. To borrow a phrase from Nicholas, if we think
> > something should be in the FAQ, then we should also consider
> > whether it's something the language should provide.
> >
> > This might also be by including additional modules in the core.
> > There are differing thoughts here: some want to see more batteries
> > included, but every additional core module is additional
> > maintenance and release work.
> >
> > When adding new features or feature bundles, we also need to think
> > about all the existing code out there and how we help it bridge the
> > gap without requiring a stressful flag-day effort.
> >
> >
> > *Growth*
> >
> > Many of the features that we'd like to see in Perl are things that
> > have been provided by plenty of other languages for years. We're
> > playing catch-up. Many of these features aren't likely to attract
> > significant numbers of new developers, but the aggregate effect of
> > them will hopefully bring us up to par.
> >
> > Considering the leaky bucket model, some of the things we can do for
> > growth are really about reducing leakage.
> >
> > That said, there are no doubt changes we could make to give Perl an
> > edge over other languages, some of which have been called for in
> > recent discussions. But we have to remember the resources we have
> > available and that we're a volunteer organisation.
> >
> > What will really attract new Perl developers in greater numbers is
> > CPAN distributions for emerging domains. Lots of people have
> > learned Python because of the machine learning support. There's a
> > chicken and egg problem here, but it's not one for P5P to try and
> > solve.
> >
> > It's also tempting to bundle Effectiveness and Growth together, but
> > I think it's worth separating them, as (a) I think the things that
> > will attract significant numbers of developers aren't the language,
> > and (b) some significant changes to the language possibly would
> > attract new developers, but at the cost of existing developers,
> > which in general isn't a trade-off I think we should make.
> >
> >
> > *Final Thoughts*
> >
> > These aren't gates, but an order in which we should consider
> > things. It doesn't mean that we can't consider changes that will
> > break things, but that we have to make an informed decision, and
> > that some considerations are more important than others. A sexy new
> > feature that might attract hordes of new developers won't be
> > acceptable if it makes Perl less secure, or inconveniences
> > significant numbers of our existing users or current developers.
> >
> > None of this is surprising or new. It's an attempt to write down
> > what I think most people feel. Some of these ideas are already
> > built-in to how new capabilities are rolled out, with feature
> > guards, for example, and the "use vN" version bundles.
> >
> > So, should reliability of old code come ahead of the e of current
> > developers? There's surely some existing perl code in the wild that
> > no one cares about any more (let's call it "abandoned code"), and
> > if we broke it, its owners wouldn't care. But we've no way of
> > identifying all the abandoned code, so it's unrealistic that we
> > could define changes that would only break abandoned code. And if
> > we tried this, then people would naturally worry that at some point
> > in the future we might sacrifice their code's reliability to the
> > new feature gods, and we'd lose perhaps the strongest pillar of
> > Perl's reputation.
> >
> > In addition to the priorities outlined here, we think there are
> > principles that we apply as well. For example, in designing new
> > language features, we should ensure they are consistent with the
> > existing language.


--
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
Re: The Purpose of P5P [ In reply to ]
On 4/12/21 9:17 AM, H.Merijn Brand wrote:
> On Mon, 12 Apr 2021 00:00:16 +0100, Philip R Brenan
> <philiprbrenan@gmail.com> wrote:
>
>> The absence of trim() in Perl is a powerful incentive to the new Perl
>> programmer to explore CPAN to find and choose a function that meets
>> their exact needs or to start learning about regular expressions.
>
> That is personal. I'm working with perl as from version 4.016 and I
> never missed trim, nor did I ever write a sub to do so.
>
> So I doubt if "powerful incentive" is correct in that sentence
>
> New users (IMHO) would be more invited to use our language if we
> supported full-threading, signatures, catch and other features people
> are working on.
>
> Developers did not leave perl because we did not have trim.
>
> maybe that is just my view
>
> One reason I like raku is because it has the best error messages I have
> ever seen, which is an enormous help when learning a new language. Try
> to compare that to the stack traces in java.
>
>> Closing off these segways to some of the most important parts of Perl
>> would be a pedagogical disaster.
>>
>> The discovery of:
>>
>> use Data::Dump qw(dump);
>>
>> amongst a number of variants on the theme on CPAN changed my attitude
>> to Perl from "this is a complete waste of time when we have PL1" to
>> "this can save me a lot of time" and "I wonder if they have anything
>> else this useful on CPAN?"
>
> Ask the community and you will get many answers. Note that there are
> many dumper modules on CPAN which also shows that not everyone expects
> the same from a Dumper module. That is the power of perl too.
>
>> - I have been using dump daily ever since as it is so much easier
>> than using the debugger.
>
> Using Data::Peek::DDumper for debugging, I have to agree with you. But
> there are many different problems to solve in programming land, and
> sometimes a debugger is the best tool, and sometimes a print/dump
> statement is the preferred way.
>
> e.g If a script would need 3 hours to *start* processing, I would
> consider a method for debugging that allows me to connect to a running
> process as gdb provides over adding a print/dump line and starting all
> over.
>
>> dump should set the minimum bar for changes to the Perl language as
>> delineated in the latest PSC report distributed by NeilB. For
>> something to be included in the base language it needs to be way
>> better than dump.
>
> As I described above: you cannot define "better" for something as
> low-level as dump, as there are too many opinions. Besides, all
> possible alternatives already live on CPAN (well, you could write your
> own (n+1)th).
>
>> If dump can live on CPAN then so can trim.
>
> True
>
>> Likewise try/catch.
>
> But not this. This hooks into deep core business and requires a lot of
> knowledge (trim does not). You are comparing a firecracker to a moon
> missile.
>
>> Both set the bar too low - if they should be included then so should
>> many other much more deserving capabilities present in CPAN.
>
> That is for the PSC to decide on. Not you.

Just a point of clarification. Question, really...

I was under the impression that PSC was for "steering" and not for
making these kinds of decisions. So far they've shown *much* fairness
regarding the comments they clearly read here. I suppose I am confused
about the different roles among:

"perl core", "PSC", and "p5p". Really the first one I am not sure what
it wrt to the others.

That said, I don't think any of us want to see bureaucracy over take
technical decisions. This cuts both ways; I'd rather support a
reasonable technical consensus that I didn't necessarily agree with than
hand the mediation over to a governing body. That's not happening, I am
just suggesting that any "appeal to authority". It's a slippery slope.

Brett

>
>> The argument "people have asked for it" should be countered with "we
>> look forward to seeing their contribution to CPAN soon".
>
> arguably, yes, but many things are not possible on CPAN (yet)
>
>> Some features cannot be implemented reliably on CPAN. For example
>> making sigils into operators so they can become optional.
>
> I sincerely hope that this will never happen. I would even be in favor
> of building a core guard to prevent that. If that is something you
> really want, choose a different language.
>
>
>> Such features will require the use of new orthogonal capabilities in
>> the base language. AUTOLOAD lets us have several competing OO systems
>> while being useful in many other contexts as well - all for the price
>> of one small extension to Perl - one giant leap forward for all Perl
>> kind.
>>
>> On Sat, Apr 10, 2021 at 9:14 PM Neil Bowers <neilb@neilb.org> wrote:
>>
>>> The purpose of P5P is "the development and maintenance of Perl" —
>>> easy, right? The "perlpolicy" doc expands on this in some areas,
>>> but in PSC discussions we still found ourselves revisiting this,
>>> and I tried various times to write up our thoughts.
>>>
>>> Various points related to this have come up in discussions on P5P,
>>> so I think it might be helpful to see how much of this we agree on.
>>> Think of this as P5P's mission statement, or manifesto.
>>>
>>> We think our priorities are, in decreasing order:
>>>
>>> 1. Deal with security issues promptly (Security).
>>> 2. Keep perl code running (Reliability).
>>> 3. Improve the language for developers who are maintaining
>>> existing code or writing new code (Effectiveness). 4. Provide
>>> reasons for people to return to Perl, or to start writing Perl
>>> (Growth).
>>>
>>> One of the points of contention is the priority of Reliability vs
>>> Effectiveness: there's a lot of old code out there that no-one
>>> cares about (any more) – do we really think keeping that code
>>> running is more important than extending the language to support
>>> today's active developers? Let's look at the priorities in turn,
>>> and then revisit this question.
>>>
>>>
>>> *Security*
>>>
>>> If security bugs are reported or discovered, then they are given
>>> appropriate priority, and they will often outweigh other
>>> considerations. When addressing security issues, we hope that the
>>> fix won't impact the other considerations. Sometimes that's not
>>> possible though, and security wins out. For example, "no . in @INC".
>>>
>>> This is not only "fix security bugs", but also "try and prevent
>>> security bugs in Perl".
>>>
>>>
>>> *Reliability*
>>>
>>> Once someone has written Perl code and it has been "put into
>>> production", we should do our best to ensure that it continues to
>>> work when they upgrade to a new version of Perl. Perl has a
>>> reputation for backward compatibility, earned over decades. That
>>> reputation is valuable, and we should only spend that capital in
>>> return for something sufficiently valuable to warrant it.
>>>
>>> - Aim for backwards compatibility when introducing new features.
>>> - Fix bugs, while remembering that sometimes bugs become relied
>>> upon, and fixing those ones can break code.
>>> - Be mindful of the breakage of CPAN code, which is our best
>>> proxy for how proprietary code may break.
>>>
>>> This doesn't mean that we must be 100% backwards compatible and
>>> never break any CPAN modules, but that we should only deviate from
>>> that when we've carefully considered the impact. If a change would
>>> break three twenty-year old modules on CPAN that no-one seems to
>>> use, that's a different proposition from breaking a module that's
>>> far up the CPAN River.
>>>
>>> Furthermore, if we do decide that it's ok to break something, we
>>> should try to reduce the inconvenience it causes by providing
>>> advance notice, clear documentation, and, when possible, tooling or
>>> other assistance.
>>>
>>> It's easy to think that perl is just about what you do in perl, but
>>> over the years perl has been used, and is still being used for a
>>> broad range of things. I think it would help us to have a shared
>>> picture of those, but that's for another day.
>>>
>>>
>>> *Effectiveness*
>>>
>>> This is about continuously evolving and improving Perl, to make the
>>> lives of active Perl developers better: increase productivity,
>>> prevent common bugs, improve performance, etc.
>>>
>>> Some of this is about filling gaps in the features provided by
>>> Perl, which developers may be used to from other languages.
>>>
>>> This can also be small incremental improvements in the language,
>>> particularly where we have the evidence to support them, for
>>> example where people regularly make the same mistake, or there's an
>>> commonly used idiom. To borrow a phrase from Nicholas, if we think
>>> something should be in the FAQ, then we should also consider
>>> whether it's something the language should provide.
>>>
>>> This might also be by including additional modules in the core.
>>> There are differing thoughts here: some want to see more batteries
>>> included, but every additional core module is additional
>>> maintenance and release work.
>>>
>>> When adding new features or feature bundles, we also need to think
>>> about all the existing code out there and how we help it bridge the
>>> gap without requiring a stressful flag-day effort.
>>>
>>>
>>> *Growth*
>>>
>>> Many of the features that we'd like to see in Perl are things that
>>> have been provided by plenty of other languages for years. We're
>>> playing catch-up. Many of these features aren't likely to attract
>>> significant numbers of new developers, but the aggregate effect of
>>> them will hopefully bring us up to par.
>>>
>>> Considering the leaky bucket model, some of the things we can do for
>>> growth are really about reducing leakage.
>>>
>>> That said, there are no doubt changes we could make to give Perl an
>>> edge over other languages, some of which have been called for in
>>> recent discussions. But we have to remember the resources we have
>>> available and that we're a volunteer organisation.
>>>
>>> What will really attract new Perl developers in greater numbers is
>>> CPAN distributions for emerging domains. Lots of people have
>>> learned Python because of the machine learning support. There's a
>>> chicken and egg problem here, but it's not one for P5P to try and
>>> solve.
>>>
>>> It's also tempting to bundle Effectiveness and Growth together, but
>>> I think it's worth separating them, as (a) I think the things that
>>> will attract significant numbers of developers aren't the language,
>>> and (b) some significant changes to the language possibly would
>>> attract new developers, but at the cost of existing developers,
>>> which in general isn't a trade-off I think we should make.
>>>
>>>
>>> *Final Thoughts*
>>>
>>> These aren't gates, but an order in which we should consider
>>> things. It doesn't mean that we can't consider changes that will
>>> break things, but that we have to make an informed decision, and
>>> that some considerations are more important than others. A sexy new
>>> feature that might attract hordes of new developers won't be
>>> acceptable if it makes Perl less secure, or inconveniences
>>> significant numbers of our existing users or current developers.
>>>
>>> None of this is surprising or new. It's an attempt to write down
>>> what I think most people feel. Some of these ideas are already
>>> built-in to how new capabilities are rolled out, with feature
>>> guards, for example, and the "use vN" version bundles.
>>>
>>> So, should reliability of old code come ahead of the e of current
>>> developers? There's surely some existing perl code in the wild that
>>> no one cares about any more (let's call it "abandoned code"), and
>>> if we broke it, its owners wouldn't care. But we've no way of
>>> identifying all the abandoned code, so it's unrealistic that we
>>> could define changes that would only break abandoned code. And if
>>> we tried this, then people would naturally worry that at some point
>>> in the future we might sacrifice their code's reliability to the
>>> new feature gods, and we'd lose perhaps the strongest pillar of
>>> Perl's reputation.
>>>
>>> In addition to the priorities outlined here, we think there are
>>> principles that we apply as well. For example, in designing new
>>> language features, we should ensure they are consistent with the
>>> existing language.
>
>
Re: The Purpose of P5P [ In reply to ]
> On Apr 12, 2021, at 10:17 AM, H.Merijn Brand <perl5@tux.freedom.nl> wrote:
>
> On Mon, 12 Apr 2021 00:00:16 +0100, Philip R Brenan
> <philiprbrenan@gmail.com> wrote:
>
>> The absence of trim() in Perl is a powerful incentive to the new Perl
>> programmer to explore CPAN to find and choose a function that meets
>> their exact needs or to start learning about regular expressions.
>
> That is personal. I'm working with perl as from version 4.016 and I
> never missed trim, nor did I ever write a sub to do so.
>
> So I doubt if "powerful incentive" is correct in that sentence
>
> New users (IMHO) would be more invited to use our language if we
> supported full-threading, signatures, catch and other features people
> are working on.
>
> Developers did not leave perl because we did not have trim.
>
> maybe that is just my view

It’s mine as well, FWIW.

With no disrespect intended to the folks pushing for it in core, I still hope trim stays in CPAN. In web applications, anyway, its utility seems moot now that forms generally submit via XHR/JavaScript, which means the server-side code can (should?) consider untrimmed input to be invalid.

I recognize that it’s useful for, e.g., parsing config files, CLI input, and such, but I don’t think it would exactly be the killer feature that reclaims Perl’s erstwhile prominence. If anything, putting something like this as a “root-namespace” function would further the (mis?)perception that Perl is mostly just meant as a quickie text-munging tool rather than a platform for serious enterprise applications.

-FG