develooper Front page | perl.perl5.porters | Postings from March 2021

Re: on changing perl's behavior Perl 5 Porters<perl5-porters@perl.org>

Thread Previous | Thread Next
From:
Philip R Brenan
Date:
March 30, 2021 16:07
Subject:
Re: on changing perl's behavior Perl 5 Porters<perl5-porters@perl.org>
Message ID:
CALhwFRmr8QxhUPOvp=O5rXku_EKiwfdZ=zH-2ssd4FER-E6f0w@mail.gmail.com
It is only perl if it runs CPAN and all other existing code out of the box.
  If it does not it is an attempt to foist another language onto users by
pretending it is perl. Our existing user base, including all the
contributors to CPAN,  will never forgive us when such changes break things
that were not broken before. If we use feature guards all will be well:

If you are going to sin, sin against God, not the bureaucracy. God will
forgive you but the bureaucracy won't.

Hyman Rickover <https://www.brainyquote.com/authors/hyman-rickover-quotes>

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

> On Tue, 30 Mar 2021 11:18:26 +0200, Salvador FandiƱo <sfandino@gmail.com>
> wrote:
>
> > On 30/3/21 5:07, Ricardo Signes wrote:
> >> On Sat, Mar 27, 2021, at 4:49 PM, Ricardo Signes wrote:
> >
> >> 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.
> >
> > IMO, the "no boilerplate" is an illusion. You need to tell the computer
> > in some way or another with language version you want.
>
> I agree on this extremely hard.
>
> I asked several proponents these questions over time:
>
>
> You're given a script/module. You run it on perl 5. It misbehaves. How do
> you tell whether it's buggy or written for perl 11?
>
> Note that the version numbers are not that important. The problem is
> identical for all other combinations.
>
> You're given a script/module. You run it on perl 8. It misbehaves. How do
> you tell whether it's buggy or written for perl 13?
> You're given a script/module. You run it on perl 10. It misbehaves. How do
> you tell whether it's buggy or written for perl 5?
> You're given a script/module. You run it on perl 9. It misbehaves. How do
> you tell whether it's buggy or written for perl 7?
>
>
> And the answers i got were variations on "have the version in the
> filename" or "include a metadata file" or "read the documentation" or "ask
> the person you got it from", and all constituted a reality of "declare the
> version anyways".
>
> At which point the question becomes: If you need to declare it anyways,
> why not just do it IN the code.
>
> --
> With regards,
> Christian Walde
>


-- 
Thanks,

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

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

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About