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

Re: on changing perl's behavior

Thread Previous | Thread Next
From:
Ricardo Signes
Date:
April 5, 2021 02:45
Subject:
Re: on changing perl's behavior
Message ID:
b50b7bf8-7db0-4ef4-b743-69dfeeb16fc8@beta.fastmail.com
On Sun, Apr 4, 2021, at 5:58 PM, Dan Book wrote:
> On Sat, Apr 3, 2021 at 11:08 PM Ricardo Signes <perl.p5p@rjbs.manxome.org> wrote:
>> 
>> "users don't want to use vX because they don't know what it does"
> 
> This seems like a non-concern to me unless there is evidence people commonly make this decision - in my experience, it's more often specifically because "use warnings" is not included. People use Mojo::Base with no qualms, even if they may not know everything it does (it does a lot, and what it does is well documented), but because they want its benefits. Major versions give us a platform to list out the benefits of such a declaration in an easily referenced manner.

So, I called that line out because it was originally given to me as significant component of how changing the out-of-the-box behavior of perl would be of benefit.  I think it's something like this:
 * having to add boilerplate to get the best practical Perl language is bad
 * having a large corpus of Perl code with different boilerplates is bad
 * when you find you have code that doesn't have "house standard boilerplate", you want to be able to add it safely
In some conversations recently, I found myself saying, "The thing is, Perl isn't C.  When we ship a new compiler, it's all the programs are recompiled before their next run, whether or not you're looking when it happens."  This is (in my mind) a good reason to minimize the breakage shipped out with a new compiler.

It also influences the decision of what can go in standard boilerplate.  If boilerplate may be added later, adding "use v5.30" starting from nothing is a nightmare.  If the behavior is a runtime exception (use strict refs) or runtime behavior change (use feature unicode_strings) it's not "obviously safe."

I can imagine an "adds compile-time failures only" boilerplate that would be safe to add freely.  You'd add it to your code, run "perl -c", and know you're now in line with house practices.

If we further imagine that "notice that boilerplate is present" is too much to ask, then I think we reach a big part of the "change the defaults by adding the 'obviously needed' stuff, but not the less safe changes."  I think in this scenario, the way one would change defaults would be to turn on more compile-time warnings, to turn on compile-time strictures, to disable compile-time-detectable syntax, and so on and, further, to do it by changing the default language.

A big problem, though, is that this isn't a safe change for code already out in production.  It requires a "compile test all code with new perl" before you install the new perl.  But so does any upgrade of perl, in theory.  It's just that in practice, we're used to surprise breakage being pretty small.

At any rate, where this train of thought led me was:  imagine a pragma, which I'll call "xyz", that works like this:
use xyz ':5.34';
# enables strict vars, compile time warnings
# disables indirect, bareword filehandles, etc.

Setting this up "everywhere" in sitecustomize would "safely" let you lift up the baseline expectations.  But it gets at the question I asked — do you want to affect only the code you *wrote* or *all the code you run* (including CPAN code).  I would presume that for most people the answer is "the code you wrote."  Otherwise you're stuck trying to edit code that comes from upstream for very unclear benefit.

That means your sitecustomize will have to distinguish between your code and external dependencies, which gets us to this:
 
>> "I want to know that all my code follows the same rules out of the gate without chasing up any set of use statements everywhere."
> 
> Better to have use statements declare such rules than have them invisibly applied by the environment.

If the user believes that absolutely *all* of their code should have the same rules, then *eliminating *use statements to reach the preferred base state is the way to get there… but if it isn't totally universal, then now there are (at least) two distinct sets of baseline languages at play, and by definition you can't look at the source code and know which one you get.

That's where, I think, we get to rules being applied invisibly, as you say!

So we throw that rule out, we accept the need to push changes back out into the CPAN, and we arrive at "to ensure that all code can assume a better common Perl, we should change the defaults for all code to add a compile-time-checkable subset of behavior changes that make the language better, then work to lift up the whole existing corpus of existing code to meet those guidelines."

I think the primary objection to this tactic is "the amount of work required to make existing public code work under these new rules is large, and then there's the work required to make existing unpublished code work;  meanwhile, the code was working, and the benefit pales in comparison to what would be available by adding a more comprehensive set of pragmas."


>> *Anyway:*  I'm not going to address all of that now and act like I have an answer that will please everyone.  I do think it's at least a bunch of the "new defaults" argument broken down into pieces.
>> 
>> My question is more like this:  We assume that "just start all code with use vX" is workable for new code.  What can we do to encourage users to feel good about how they take their existing, running code and get it up closer to "the best perl we know" options?  Here, I'm assuming that there's a lower cost of ownership to your code if you can know that all your code can be skimmed the same way, because it's got the same set of options.  But you now want to take your older code and stick the same use vX at the top as you have in your new code.  How do we help users feel confident in staying up to date with the "use vX" of their current perl-X?
> 
> Provide guidance and good documentation, publicize the new bundle well, and accept that some code is better off without it.

I think that's a big part of it, and will try to write more about specifics.  But not tonight!  Maybe tomorrow, but I might spend the day loafing and reading.  We'll see how I feel in 12 hours…

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