http://www.perlmonks.org?node_id=11131653


in reply to Re^5: Pumpking resignation
in thread Pumpking resignation

You could substitute "offside" for "balls and strikes" for a footie analogy. And I think your contradiction may have been in saying that there was (a) no discussion but (b) many people with vested interests trying to point out ...


The way forward always starts with a minimal test.

Replies are listed 'Best First'.
Re^7: Pumpking resignation
by marto (Cardinal) on Apr 23, 2021 at 12:04 UTC

    I'm aware offside is a 'bad' thing, but not familiar with that either, but I really appreciate you trying to clear that up for me :) In terms of what I said this is a chain of events. An announcement was made by a manager without discussion with the people who'd have to do the work, after which continued comms (for what, almost a year now) to have some back and forth from the people who'd actually be doing the work, many of whom were apparently ignored when raising various types of issue with the announced course of action.

      An announcement was made by a manager without discussion with the people who'd have to do the work, after which continued comms (for what, almost a year now) to have some back and forth from the people who'd actually be doing the work, many of whom were apparently ignored when raising various types of issue with the announced course of action.

      You wonder why I think you are not on the level? It's because you sound like Conway, not Damian, but Kellyanne. What gives with the passive voice and this anonymous manager? Is that to be Sawyer X? If not, what relevance? If so, did you miss this:

      From: Sawyer X Date: June 26, 2020 19:42 Subject: Re: Announcing Perl 7 Message ID: CAMvkq_QXi1pxaRGwZEqkJgYzf=h3WoB2AJaK4b5c3zQmNWLXJw@mail.gmail.com On Thu, Jun 25, 2020 at 11:16 AM Dave Mitchell <davem@iabyn.com> wrote +: > > On Wed, Jun 24, 2020 at 11:49:30PM +0300, Sawyer X wrote: > > * Major versions will be used for two purposes: 1. Turn on feature +s > > and pragmas by default, 2. Remove syntax from the language. > > I want to be on the record that I extremely strongly oppose this cha +nge. Noted. I'm sorry you feel this way, but I hope to turn this around, or at least to change that your vehement disagreement will be accompanied by understanding why this decision was made. I have given very brief responses below, but at the bottom, I go at more length on what I think is the main topic you object to. It doesn't cover everything in email, but it's not easy for me to address everything you wrote in one go, so please bear with me. > I think if people want to use the new modern perl, they just put thi +s > one simple line at the top of their code: > > use v7; This cannot achieve what we want. I don't believe it even achieves what you suggest. As explained below, "use v" is not practically useful. > this makes everything forward and backwards compatible, and eases th +e > transition. The thing is that old perl binaries back to at least 5.8 +.x > recognise this syntax and will produce a helpful error message: > > $ perl589 -e'use v7' > Perl v7.0.0 required--this is only v5.8.9, stopped at -e line 1. We are not removing "use v" but we are recognizing that it doesn't provide what we need. I would venture that while you can still use "use v", you probably don't want it anyway, even in 5.32.0. I know I couldn't use it in any code I have, whether professionally or on CPAN. > this helps everyone: writers of perl7 code will know what the proble +m > is when they accidentally run their code on an old perl binary, rath +er > than getting some obscure error message. > > Older code continues to run without modification - you don't > have edit every source file to add a 'use compat::perl5' line. > You don't have to update every existing perl installation to add the > compat::perl5 module just so that existing code will continue to run +. > CPAN continues to work. If you have numerous files, they each have to have "use v". Your proposal doesn't change the fact that a use statement needs to be added by someone. You suggest that this particular someone not be those keep their code static, but those who want to actively write code. That's a fair position, but it's only another coin of the plan's argument. You say "New users add 'use v'" and I say "Old users update or add 'use compat::perl5'". The same idea of adding lines of code, just the question is who. > 'use v7' also allows the new stuff to be scoped to a single source f +ile; > other .pm files can still be included unmodified using the old perl > syntax. That's actually far worse and is a major reason "use v" is not suitabl +e. > Look, we've got this great built-in mechanism, 'use vx.y.z' that's b +een > around forever. It hasn't seen much use yet, because frankly there's > been very little call for it, since there hasn't been much new > non-backcompat stuff so far. But its been sitting there waiting for +use to > use it. This mechanism isn't in use because it does not work. > In 5 years or whatever, it will also save our bacon when perl8 is > released; suddenly all that source code with 'use v7;' at the top wi +ll > continue to work on the perl8 interpreter running in perl7 mode. Rat +her > than suddenly all breaking. This isn't the scenario. It's the scenario you are painting in the email. Why would all code suddenly break when we release version 8? > It helps IDEs as well - now they can look at a source file and know > instantly what major release of perl this file was written against, +and > so how to syntax highlight etc. Are you suggesting that IDEs create different parsers for the Perl syntax based on pragmas turned on in scopes? Can you give an example of an IDE that does this now? > [...] I'm cutting the rest because it is both too long and includes several points raised which makes it difficult to respond to each section separately at length in one email. Instead, I will focus on one particular aspect: "use v" does not work +for us. 1. People do not actually use "use v". This is what we've seen with it so far. CPAN is an example, and every code-base I touched and discussed with peers had rarely used it. It is true that this is anecdotal because I haven't touched or discussed every code-base, but I am in touch with a few major Perl shops. It is rarely used by any of them. This has to account for a fair portion of active Perl code and this anecdote does means something. We have a mechanism we believe is superior and gives our users what we think we want. Our users don't use it. Aergo, our mechanism isn't the gift to developers we thought it is. 2. "use v" turns on *everything* till this version. With 7.0, we do not intend to turn on everything. If you were to take a large code-base, you will not be able to easily transition it to *everything* in feature.pm. It's impossible, even with an exhaustive set of tests, because the number of changes, both to syntax and semantics, will require a lot of updating and probably tests you haven't even thought of. A good example is unicode_strings. If I had written 10K lines assuming my strings are bytes, I'm screwed. Will I get the time to actually go ahead and change all of my code to assume otherwise? Probably not. For 7.0, we will turn on very few pragmas and features, to allow people to make a relatively seamless update. This is already being tested with a few stakeholders and is proving fairly doable. 3. "use v" being lexically scoped is even worse in this respect. Different code within the same code-base that touches the same data (a fairly common occurrence) will now have some lines of code that assume the string is bytes and some assume it is Unicode characters. This makes the code nearly impossible to work with. If in #2, I expressed I can't move a large code-base to every possible feature and pragma at once, the fact that it's lexical can only make it worse for me because I don't know if a line of code that has it enabled will trigger a line of code in a different package which doesn't have it enabled. 4. "use v" is meant to make "use feature" easier. Using feature.pm indefinitely makes it impossible to ever remove code, which is also something we are actively trying to change. This means that "use v" does even more to cement feature guards' infinite existence. Why remove crufty features in the code when we can just keep it on by default and force all developers to indicate they don't want it? An example of this situation is as follows: package Foo { use feature qw< unicode_strings >; sub match { print $_[0] =~ /ss/i ? "Foo: match\n" : "Foo: no match +\n" } sub match_with_bar { Bar::match(@_) } } package Bar { sub match { print $_[0] =~ /ss/i ? "Bar: match\n" : "Bar: no match +\n" } } my $x = "\xDF"; Foo::match($x); # works Foo::match_with_bar($x); # doesn't work To summarize: * With "use v" I need to add this *everywhere*. * With "use v" I need to deal with even significantly breaking changes and I need to deal with all of them at once. (Like within a single-but-large file.) * With "use v" I need to add this to all files and deal with all of it at once because due to it being in a package scope, it can create a vast action-at-a-distance behavior. I could trigger code within my code-base which wasn't updated or code in a module which wasn't updated. * With "use v" the code will not get removed, which is the opposite of what we want "use v" is effectively a non-starter. It doesn't allow people to progressively update their code, only gives them an all-or-nothing "solution." That's not a real solution. As much as it doesn't help them, it doesn't allow us to remove any code, ever.

      This was a political situation where the "king" was removed by backstabs, and you seem to champion the folks with the bloody blades.

        'This was a political situation where the "king" was removed by backstabs, and you seem to champion the folks with the bloody blades.'

        Neither of these are true, you can't have read and understood what I've written in this thread. You've selectively posted one long reply, from a thread full of posts from people I've quoted elsewhere in the thread, or that have been linked to in the other conversations on this topic linked to elsewhere in the thread.