On Friday, April 9th, Neil, Ricardo, and I met for our 15th Perl
Steering Council meeting.
We discussed the trim() function and the plan for a modern baseline to Perl.
On trim():
While we were interested in all the feedback on trim(), we were not
fully convinced by the arguments to change the behavior of functions
that trim a string's end. There are already two such functions
(chop/chomp) that behave in one way. We still consider it more
reasonable to have the next function that also trims the end of
strings stay within the same behavior. This might be an unfortunate
API but we value consistency here (string trimming functions being
in-place) than partially good behavior (one works correctly, the other
two do not - the user having to remember which is which).
However, as we are interested in making the best decision here, we
decided to reach out to those we think are better at deciding how
confusing it is for developers to learn. We reached out to people who
we think have the most experience in teaching Perl: Tom Christiansen,
brian d foy, Damian Conway, Curtis (Ovid) Poe, and Randal Schwartz. We
requested feedback on what they think would be easy to teach, rather
than necessarily consistent.
We started receiving feedback (and our thanks goes out to these
respected experts) and we are reviewing their responses (and the
conversation thread) and will make a decision once this thread is
resolved.
On the Future for Perl:
After countless conversations (at planned meetings, ad-hoc meetings,
email threads, conversation threads, and more), having reviewed all
the available options between ourselves, the Perl core, p5p, and more,
we have come to the conclusion that **the way forward for Perl
providing a better baseline is via the `use v` mechanism.** In other
words, using `use v7.0` will be the way to move forward.
This does not mean we are done by just putting `use warnings` behind
`use v7.0`. Unfortunately, `use v` is not as highly used as it needs
to be to make this plan a success. To make it a useful mechanism, we
will need to help people understand it, work on its image, and promote
its use on CPAN and beyond.
If we want developers to declare the version of Perl they're writing
to, and in particular to use v7, then we have to encourage it on CPAN
as well. Toolchain modules and those up-river have a good reason for
supporting 5.8+. But authors of high-level applications and new
modules should feel not only able, but encouraged, to develop to a
much more recent baseline. People have felt pressured to downgrade
their personal coding style when releasing to CPAN, discouraging
further contribution.
We'd like to see CPAN Perl Versioning guidelines, which balance the
different forces at play, make everyone aware of the trade-offs, and
reflect that when people release their code, it's our choice whether
or not to use it.
Outside CPAN, we need to promote `use v` as beneficial to developers -
whether individuals, self-employed, or companies. It will allow them
to make use of the best the language has to offer and provide both a
one-statement baseline as well as a moving target (where the `X` in
`use vX` can continue moving forward). We will need to provide
recommendations on how to best use this mechanism and update it as
desired and necessary.
We also wish to underline that deciding to make the modern Perl an
opt-in with `use v` does not mean that the Perl core will continue to
support every misfeature of Perl ad infinitum. We will continue to
review existing misfeatures (and misbehaviors) as candidates for
revision or removal if they stand in the way of larger gains on a
case-by-case basis, as we have done so far.
It is also worth noting when discussing behaviors and misbehaviors
that we consider both `strict ` and `warnings` to be *features*, not
*misfeatures*, though their value is in a developer being able to turn
them off for individual cases, rather than to turn them on, even if
this is the default in Perl.
We want to extend our thanks and our gratitude to all those involved
in this process. It's been long, tiring, and difficult - both mentally
and emotionally. We greatly appreciate this effort and - in many cases
- sacrifice.
-- Neil, Ricardo, and Sawyer.
Steering Council meeting.
We discussed the trim() function and the plan for a modern baseline to Perl.
On trim():
While we were interested in all the feedback on trim(), we were not
fully convinced by the arguments to change the behavior of functions
that trim a string's end. There are already two such functions
(chop/chomp) that behave in one way. We still consider it more
reasonable to have the next function that also trims the end of
strings stay within the same behavior. This might be an unfortunate
API but we value consistency here (string trimming functions being
in-place) than partially good behavior (one works correctly, the other
two do not - the user having to remember which is which).
However, as we are interested in making the best decision here, we
decided to reach out to those we think are better at deciding how
confusing it is for developers to learn. We reached out to people who
we think have the most experience in teaching Perl: Tom Christiansen,
brian d foy, Damian Conway, Curtis (Ovid) Poe, and Randal Schwartz. We
requested feedback on what they think would be easy to teach, rather
than necessarily consistent.
We started receiving feedback (and our thanks goes out to these
respected experts) and we are reviewing their responses (and the
conversation thread) and will make a decision once this thread is
resolved.
On the Future for Perl:
After countless conversations (at planned meetings, ad-hoc meetings,
email threads, conversation threads, and more), having reviewed all
the available options between ourselves, the Perl core, p5p, and more,
we have come to the conclusion that **the way forward for Perl
providing a better baseline is via the `use v` mechanism.** In other
words, using `use v7.0` will be the way to move forward.
This does not mean we are done by just putting `use warnings` behind
`use v7.0`. Unfortunately, `use v` is not as highly used as it needs
to be to make this plan a success. To make it a useful mechanism, we
will need to help people understand it, work on its image, and promote
its use on CPAN and beyond.
If we want developers to declare the version of Perl they're writing
to, and in particular to use v7, then we have to encourage it on CPAN
as well. Toolchain modules and those up-river have a good reason for
supporting 5.8+. But authors of high-level applications and new
modules should feel not only able, but encouraged, to develop to a
much more recent baseline. People have felt pressured to downgrade
their personal coding style when releasing to CPAN, discouraging
further contribution.
We'd like to see CPAN Perl Versioning guidelines, which balance the
different forces at play, make everyone aware of the trade-offs, and
reflect that when people release their code, it's our choice whether
or not to use it.
Outside CPAN, we need to promote `use v` as beneficial to developers -
whether individuals, self-employed, or companies. It will allow them
to make use of the best the language has to offer and provide both a
one-statement baseline as well as a moving target (where the `X` in
`use vX` can continue moving forward). We will need to provide
recommendations on how to best use this mechanism and update it as
desired and necessary.
We also wish to underline that deciding to make the modern Perl an
opt-in with `use v` does not mean that the Perl core will continue to
support every misfeature of Perl ad infinitum. We will continue to
review existing misfeatures (and misbehaviors) as candidates for
revision or removal if they stand in the way of larger gains on a
case-by-case basis, as we have done so far.
It is also worth noting when discussing behaviors and misbehaviors
that we consider both `strict ` and `warnings` to be *features*, not
*misfeatures*, though their value is in a developer being able to turn
them off for individual cases, rather than to turn them on, even if
this is the default in Perl.
We want to extend our thanks and our gratitude to all those involved
in this process. It's been long, tiring, and difficult - both mentally
and emotionally. We greatly appreciate this effort and - in many cases
- sacrifice.
-- Neil, Ricardo, and Sawyer.