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:
B. Estrade
Date:
March 30, 2021 16:51
Subject:
Re: on changing perl's behavior Perl 5 Porters<perl5-porters@perl.org>
Message ID:
532ee093-a24a-0503-e0d8-79da46538f3a@cpanel.net


On 3/30/21 11:06 AM, Philip R Brenan wrote:
> 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

Is that true? I know Perl 6 had their specification conformity suite (as 
do other "languages"); but I've always accepted the notion that the 
ultimate judge of "what is perl" was the perl interpreter itself. Sort 
of related to "only perl can parse perl"; but not the same thing at all.

I agree it would be totally stupid to "break" modules in CPAN, and in 
fact precedence dictates that some classes of changes utilize CPAN quite 
heavily to identify issues (be they in the module or in the perl 
implementation). Of course, "which" modules get broken are also part of 
that consideration.

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

Well, I mean you have to actually be *contrite*; which to me means you 
are faced with only sinful choices if you feel you have to sin. Is that 
last part true, that there are only 'sinful' choices here? (Idk the 
answer mind you, but this does beg the question of what are the actual 
full set of choices). Maybe better to look at it as do your best and try 
not to sin, but understand we're are all sinners. And that the only 
control each one of us has is in pardoning another. What does that mean, 
(again) do your best with best intentions; if you upset someone and they 
can't forgive you, that's not your problem. It's also fitting to mention 
that "perfection is the enemy of good" - it may as well be read, "the good".

A decision has to made to move ahead at some point; all the debate in 
the world will not replace seeing what happens. Failing quickly and 
humbly is much more efficient (and ingratiating), observe, adjust, move 
on. Mistakes *will* be made. Perfection is not the goal here, clearing 
the path for practical and future development is. And it doesn't really 
matter how you get past the rock in our path - over it, under it, around 
it - maybe even by collectively moving it. What does that look like? 
Probably the option that makes everyone a little upset rather than a 
specific portion extremely upset.

Brett

> 
> 
> On Tue, Mar 30, 2021 at 10:26 AM Christian Walde 
> <walde.christian@gmail.com <mailto:walde.christian@gmail.com>> wrote:
> 
>     On Tue, 30 Mar 2021 11:18:26 +0200, Salvador Fandiño
>     <sfandino@gmail.com <mailto: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