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

Re: on changing perl's behavior

Thread Previous | Thread Next
From:
Dan Book
Date:
March 30, 2021 05:00
Subject:
Re: on changing perl's behavior
Message ID:
CABMkAVV8wsmCyVKtWaLaSkN-rYqD7m_ZAKi-Jp1HGHSJADUnRw@mail.gmail.com
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

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