Re: [PHP-DEV] Internals "camps"

  107488
October 11, 2019 05:40 walterp@gmail.com (Walter Parker)
G

On Thu, Oct 10, 2019 at 10:10 PM Stephen Reay <stephen@koalephant.com>
wrote:

> > > > On 11 Oct 2019, at 02:59, Walter Parker <walterp@gmail.com> wrote: > > > > On Thu, Oct 10, 2019 at 10:36 AM Chase Peeler <chasepeeler@gmail.com> > wrote: > > > >> > >> > >> On Thu, Oct 10, 2019 at 1:30 PM Walter Parker <walterp@gmail.com> > wrote: > >> > >>>> > >>>> > >>>> No. The compromise is funding a ferry system. Or laying Internet > between > >>>> them. Or a passenger pigeon mail route. > >>>> > >>>> Sometimes compromise requires deep discussion about the motivations > for > >>>> each side and coming to a lateral, mutually acceptable, solution. > >>>> > >>>> But we'd rather not discuss motivations and just bicker about the > >>> surface > >>>> results. I.e., argue the X, rather than the Y, of these little XY > >>> problems > >>>> we're solving. > >>>> > >>>> > >>>> > >>> Build a ferry system is alternative to building bridge. I can see that > as > >>> a > >>> compromise, I can also see that as a separate project created to serve > >>> demand after the the bridge project is rejected. Where a ferry system > is > >>> started because there is still demand for transit, just not enough > demand > >>> to pay for a bridge. > >>> > >>> With respect to the backtick proposal, what is the "ferry" project? Do > we > >>> have to come up with one before we can cancel the "bridge" project or > can > >>> we cancel the "bridge" project on its own merits and then discuss a > future > >>> project that solves the actual underlying problem? > >>> > >>> "Ferry" projects might be: more/better training on PHP, better > >>> documentation so that the backtick is no longer an "obscure" feature to > >>> those that don't have a shell/Unix/Perl background, tooling to warn > people > >>> when they misuse this feature. > >>> > >>> > >>> > >> To the side that says "There is absolutely no reason we need to go to, > or > >> communicate with, the island in the first place," a ferry project isn't > a > >> compromise. The position of the "anti-bridge" builders isn't because > they > >> are against building bridges - it's because they are against spending > >> resources on attempts to get to the island in the first place. The other > >> side might have valid arguments on why we need to get to the island, > but, > >> just proposing different ways to get there isn't compromising with the > side > >> that doesn't want to go there. > >> > > > > I think you may have just created a strawman for the anti-bridge > position. > > There are famous anti-bridge cases, like the Bridge to Nowhere in Alaska > > (if you don't remember, there was an island in Alaska that had 50 people > > and Senator Stevens wanted to replace the existing ferry system with a > $398 > > million bridge). People complained about the bridge not because they > wanted > > the islanders to to isolated, but because it was poor use of money when > > there where bigger and more urgent problems. > > > > To bring this back to PHP, is the backtick really a urgent problem of > > enough magnitude that it justifies the cost of a BC break in unknown > amount > > of PHP code that has been functional for years. If this proposal passes > > (and the follow up to remove it which I'm certain will be proposed), then > > this is one that leaves people on the island as they will either be stuck > > on an old version of PHP or have to pay to update the code. This pushes > the > > costs on them to solve a an existing issue that 20 years after it was > > created and is now an issue because a new generation of coders, unaware > of > > history, find the existing syntax not to there taste/a poor design. Why > are > > we giving priority to people that haven't taken the time to educate > > themselves over people that did and used programming style that used to > > common? > > > > > >> > >> > >>> Walter > >>> > >>> -- > >>> The greatest dangers to liberty lurk in insidious encroachment by men > of > >>> zeal, well-meaning but without understanding. -- Justice Louis D. > >>> Brandeis > >>> > >> > >> > >> -- > >> Chase Peeler > >> chasepeeler@gmail.com > >> > > > > > > -- > > The greatest dangers to liberty lurk in insidious encroachment by men of > > zeal, well-meaning but without understanding. -- Justice Louis D. > Brandeis > > > Hi Walter, > > The RFC at the centre of this ridiculous string of analogies is about one > thing: deprecate (i.e. show a deprecation message) about the backtick > operator. > > The RFC specifically doesn’t lay out a timeline for actual removal, it > doesn’t even hint at “well it’ll just be automatically removed”. > I find disingenuous, the author of the RFC has said more than once that
removal is a goal of his. I think it is perfectly fair to look ahead and view the process as a whole (the end goal). When walking to the edge of a cliff, we don’t have to wait until we get to the edge to understand that waking off the cliff is a mistake.
> So this RFC breaks *nothing*. > > Yes, it does lead to the situation where it’s likely that a followup RFC > will propose removing the (then) deprecated feature - perhaps 9.0, perhaps > it’ll be discussed pre-9.0, and held off until 10.0? But any such change > will then require *another* vote, with another round of discussions and no > doubt ridiculous analogies. > > And at that time, after several years of warnings about deprecation, > Nikita or someone else will likely pop up with some analysis of projects to > show usage *at the time*. > > If the only reason to keep a dangerous operator is “well a small subset of > people use it”, marking it as *deprecated* is how you signal to those > people that the feature will likely be removed in a future version. > > Now you are assuming the conclusion. Once of the main debates here is if
the backtick is a dangerous thing. That has still to to be proven to many people.
> The argument about “shell style scripts” that are on a server which > constantly gets updated to the newest release but never gets any > maintenance to the scripts is a ridiculous fantasy. > > There is zero chance someone is dist-upgrading from one release to the > next through enough versions that they get to one where the distro-provided > php is such that backticks are actually removed, and yet the only thing > that breaks is the backticks. > > > > To be honest, what I really care about is people not breaking the PHP applications that I’m currently using (Roundcube, phpmyadmin, Wordpress ).
I know that in the past I spent enough time fixing PHP code that stopped working because of yet another BC change. That pace has slowed down in recent years. If you and others really don’t think this is a problem, I’ll let you and those others fix the issues in the future as they are unlikely to effect me. Just don’t say “we didn’t see it coming”. If I’m wrong, them I’m wrong and feel to follow up with me in the last 2020’s when we know what has actually happened. Personally, I’m thinking of moving my backend work to something else, like Go. Rob and his team seem to have a good handle on things. Cheers
> > > Stephen
Good luck, hope you don’t eventually cause too much pain and trouble with the BC breaks over the next few years. Walter
> -- The greatest dangers to liberty lurk in insidious encroachment by men of
zeal, well-meaning but without understanding. -- Justice Louis D. Brandeis