Re: [PHP-DEV] [RFC] Reclassifying engine warnings

  106729
August 28, 2019 14:20 gertp93@gmail.com (Gert)
Maybe i'm misunderstanding something here, but what does turning
notices into deprecations achieve? Because if you have deprecation
notices being logged then it shouldn't be extra work to log
notices/warnings as well right?

On Wed, 28 Aug 2019 at 16:16, Chase Peeler <chasepeeler@gmail.com> wrote:
> > Well, one reason I was so vocal about short tags wasn't a love for short > tags themselves. It wasn't even to prevent the detrimental effects of > removing them. Honestly, the 2nd RFC wasn't a horrible option. It was more > about the precedent that it set - pushing huge BC breaks on the users (most > of which are voiceless in the process, because they aren't involved in the > community at all, most not really aware there is anything to be involved > with) with little, if any, positive gain. > > Let's see how this plays out a bit longer. It's too early to tell if it's a > dying attempt to keep pushing those type of changes, which are destined to > be rejected, or, evidence that we are still in danger of having such a > precedent set. > > > > On Wed, Aug 28, 2019 at 10:11 AM Chase Peeler <chasepeeler@gmail.com> wrote: > > > > > > > On Wed, Aug 28, 2019 at 9:55 AM Reindl Harald reindl@thelounge.net> > > wrote: > > > >> > >> > >> Am 28.08.19 um 15:48 schrieb Chase Peeler: > >> > If it is still done, then I think a deprecation path is a must. As > >> > mentioned earlier, this doesn't necessarily mean E_DEPRECATION messages > >> - > >> > warnings will work too. The key is that error logs with more urgency > >> than > >> > notices are created that users can use to track down and fix issues. > >> > >> hell, there are notices for at least a decade > >> > >> error_log = "/var/log/php_error.log" > >> error_reporting = E_ALL > >> display_errors = 1 > >> > >> this is my development *as well* production config on every machine > >> since 16 years now and every warning/notice get fixed because every 30 > >> minutes the errorlog get mailed to every developer and admin > >> > >> turn logging on and start cleanup what you would have had a decade time. > > > > > > Am I the only one getting tired of people telling me how I need to operate > > just like they do? Everyone's circumstances are different. Just because > > something is easy for you, or works well for you, doesn't mean it's easy or > > even feasible for someone else. I've learned it's useless to try to explain > > how my situation might not be exactly like everyone else's, so I'm not > > going to waste the time doing it again. > > > > Why can't anyone see that taking on these myopic "My situation is the only > > valid situation" views are going to kill this language. > > > > "I always initialize my variables, so, it's no big deal if everyone else > > is forced to do so." > > "I was able to find and replace all the short tags in my code in 5 > > minutes, so it should be easy for everyone else to do as well." > > "We fix every single notice within 30 minutes of it popping up in a log. > > You should be able to do that as well." > > etc. etc. etc. > > > > Also, if you are going to try and tell me how I should my job, at least > > have the guts to reply to the entire list instead of sending it to me in a > > private reply. I'm obviously not afraid to turn around to make your reply > > public, so it'll save everyone a bit of time. > > > > -- > > Chase Peeler > > chasepeeler@gmail.com > > > > > -- > Chase Peeler > chasepeeler@gmail.com
  106732
August 28, 2019 14:27 chasepeeler@gmail.com (Chase Peeler)
On Wed, Aug 28, 2019 at 10:20 AM Gert <gertp93@gmail.com> wrote:

> Maybe i'm misunderstanding something here, but what does turning > notices into deprecations achieve? Because if you have deprecation > notices being logged then it shouldn't be extra work to log > notices/warnings as well right? > > Notices include a lot more than just undeclared variables. Turning them on in our environment would pretty much make the logs unusable for any on the
spot checking for issues. They would only be useful if we were trying to parse out specific errors, and, they would be HUGE. Each web server generates about 5-10 megs of logs in a day. Our CLI servers (which runs beanstalkd jobs) generates about 80-100 megs of logs in a day. That's without notices turned on.
> On Wed, 28 Aug 2019 at 16:16, Chase Peeler <chasepeeler@gmail.com> wrote: > > > > Well, one reason I was so vocal about short tags wasn't a love for short > > tags themselves. It wasn't even to prevent the detrimental effects of > > removing them. Honestly, the 2nd RFC wasn't a horrible option. It was > more > > about the precedent that it set - pushing huge BC breaks on the users > (most > > of which are voiceless in the process, because they aren't involved in > the > > community at all, most not really aware there is anything to be involved > > with) with little, if any, positive gain. > > > > Let's see how this plays out a bit longer. It's too early to tell if > it's a > > dying attempt to keep pushing those type of changes, which are destined > to > > be rejected, or, evidence that we are still in danger of having such a > > precedent set. > > > > > > > > On Wed, Aug 28, 2019 at 10:11 AM Chase Peeler <chasepeeler@gmail.com> > wrote: > > > > > > > > > > > On Wed, Aug 28, 2019 at 9:55 AM Reindl Harald reindl@thelounge.net> > > > wrote: > > > > > >> > > >> > > >> Am 28.08.19 um 15:48 schrieb Chase Peeler: > > >> > If it is still done, then I think a deprecation path is a must. As > > >> > mentioned earlier, this doesn't necessarily mean E_DEPRECATION > messages > > >> - > > >> > warnings will work too. The key is that error logs with more urgency > > >> than > > >> > notices are created that users can use to track down and fix issues. > > >> > > >> hell, there are notices for at least a decade > > >> > > >> error_log = "/var/log/php_error.log" > > >> error_reporting = E_ALL > > >> display_errors = 1 > > >> > > >> this is my development *as well* production config on every machine > > >> since 16 years now and every warning/notice get fixed because every 30 > > >> minutes the errorlog get mailed to every developer and admin > > >> > > >> turn logging on and start cleanup what you would have had a decade > time. > > > > > > > > > Am I the only one getting tired of people telling me how I need to > operate > > > just like they do? Everyone's circumstances are different. Just because > > > something is easy for you, or works well for you, doesn't mean it's > easy or > > > even feasible for someone else. I've learned it's useless to try to > explain > > > how my situation might not be exactly like everyone else's, so I'm not > > > going to waste the time doing it again. > > > > > > Why can't anyone see that taking on these myopic "My situation is the > only > > > valid situation" views are going to kill this language. > > > > > > "I always initialize my variables, so, it's no big deal if everyone > else > > > is forced to do so." > > > "I was able to find and replace all the short tags in my code in 5 > > > minutes, so it should be easy for everyone else to do as well." > > > "We fix every single notice within 30 minutes of it popping up in a > log. > > > You should be able to do that as well." > > > etc. etc. etc. > > > > > > Also, if you are going to try and tell me how I should my job, at least > > > have the guts to reply to the entire list instead of sending it to me > in a > > > private reply. I'm obviously not afraid to turn around to make your > reply > > > public, so it'll save everyone a bit of time. > > > > > > -- > > > Chase Peeler > > > chasepeeler@gmail.com > > > > > > > > > -- > > Chase Peeler > > chasepeeler@gmail.com >
-- Chase Peeler chasepeeler@gmail.com
  106733
August 28, 2019 14:39 ocramius@gmail.com (Marco Pivetta)
On Wed, Aug 28, 2019 at 4:27 PM Chase Peeler <chasepeeler@gmail.com> wrote:

> On Wed, Aug 28, 2019 at 10:20 AM Gert <gertp93@gmail.com> wrote: > Notices include a lot more than just undeclared variables. Turning them on > in our environment would pretty much make the logs unusable for any on the > spot checking for issues. They would only be useful if we were trying to > parse out specific errors, and, they would be HUGE. Each web server > generates about 5-10 megs of logs in a day. Our CLI servers (which runs > beanstalkd jobs) generates about 80-100 megs of logs in a day. That's > without notices turned on.
I worked with clients with much more log overhead happening: the solution is working to fix these issues, and not ignoring more of them. Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/
  106735
August 28, 2019 14:52 rowan.collins@gmail.com (Rowan Collins)
On 28 August 2019 15:39:26 BST, Marco Pivetta <ocramius@gmail.com> wrote:
>I worked with clients with much more log overhead happening: the >solution >is working to fix these issues, and not ignoring more of them.
Being right is not the same as being easy, or being the top priority for an organisation with limited resources. Regards, -- Rowan Collins [IMSoP]
  106736
August 28, 2019 14:54 chasepeeler@gmail.com (Chase Peeler)
On Wed, Aug 28, 2019 at 10:39 AM Marco Pivetta <ocramius@gmail.com> wrote:

> On Wed, Aug 28, 2019 at 4:27 PM Chase Peeler <chasepeeler@gmail.com> > wrote: > >> On Wed, Aug 28, 2019 at 10:20 AM Gert <gertp93@gmail.com> wrote: >> Notices include a lot more than just undeclared variables. Turning them on >> in our environment would pretty much make the logs unusable for any on the >> spot checking for issues. They would only be useful if we were trying to >> parse out specific errors, and, they would be HUGE. Each web server >> generates about 5-10 megs of logs in a day. Our CLI servers (which runs >> beanstalkd jobs) generates about 80-100 megs of logs in a day. That's >> without notices turned on. > > > I worked with clients with much more log overhead happening: the solution > is working to fix these issues, and not ignoring more of them. > > You going to come and fix the issues? It's an internal application and most of those messages are coming from legacy areas of the code which are
mainly "it works, so leave it alone" things. Instead of going back and spending time trying to fix those boondoggles, we invest the time of our developers (there are 2 others besides myself) into building new features that help our business grow. Time permitting, we try and update some of the legacy areas, but, we usually find it's a better investment to just rebuild them at that point. Bottom line is that we live with the not-so-good stuff so that we can focus on adding new great stuff. The not-so-good stuff isn't holding us back, and trying to fix things like undeclared variables would have absolutely ZERO positive effect on our business, which uses this application every day. If I went to our executive team and said "Can we delay that new scheduling system that will really help our business so I can go back and update code to get rid of these undeclared variable notices?" I'd get laughed at! Like I've said before - can we please stop pretending we understand everyone else's situation? Maybe my situation is unique. My gut tells me it might be unique among people on this list, but, that it's actually pretty common among the myriad of developers out there which never get involved in these discussions. -- Chase Peeler chasepeeler@gmail.com
  106739
August 28, 2019 15:12 markyr@gmail.com (Mark Randall)
On 28/08/2019 15:54, Chase Peeler wrote:
> Bottom line is that we live with the not-so-good stuff so that we can focus > on adding new great stuff. The not-so-good stuff isn't holding us back, and > trying to fix things like undeclared variables would have absolutely ZERO > positive effect on our business, which uses this application every day.
This is a classic case of technical debt. It might not bite you in the ass today, tomorrow, or next week, but it will inevitably bite you in the ass at some point, and the longer it's left, the more it's going to hurt when that time comes. Don't build your business on a foundation of eggshells and then complain when something comes along that makes those eggshells crumble. -- Mark Randall
  106741
August 28, 2019 15:36 kalle@php.net (Kalle Sommer Nielsen)
Hi

Den ons. 28. aug. 2019 kl. 17.54 skrev Chase Peeler <chasepeeler@gmail.com>:
> You going to come and fix the issues? It's an internal application and > most of those messages are coming from legacy areas of the code which are > mainly "it works, so leave it alone" things. Instead of going back and > spending time trying to fix those boondoggles, we invest the time of our > developers (there are 2 others besides myself) into building new features > that help our business grow. Time permitting, we try and update some of the > legacy areas, but, we usually find it's a better investment to just rebuild > them at that point. > > Bottom line is that we live with the not-so-good stuff so that we can focus > on adding new great stuff. The not-so-good stuff isn't holding us back, and > trying to fix things like undeclared variables would have absolutely ZERO > positive effect on our business, which uses this application every day. If > I went to our executive team and said "Can we delay that new scheduling > system that will really help our business so I can go back and update code > to get rid of these undeclared variable notices?" I'd get laughed at! > > Like I've said before - can we please stop pretending we understand > everyone else's situation? Maybe my situation is unique. My gut tells me it > might be unique among people on this list, but, that it's actually pretty > common among the myriad of developers out there which never get involved in > these discussions.
I'm sorry, but like Mark Randall has already pointed out then this is a classic example of technical depth. At one point you must choose, "Do I want to upgrade to the latest version of PHP or do I want to fix the issues which is caused by the technical depth in my stack?". I get it, writing new code is always more fun, it really is, I have previously worked with companies with that same attitude that "we'll fix it later", but at one point that becomes such a burden and if your management doesn't believe in putting in resources to actual maintenance of your infrastructure, then I'm sorry but it does not sound like a healthy place to be (no offense meant). Right now your argument is merely trying to hold back changes which will bite that technical depth of yours, and everytime an argument has been raised towards your concerns it has been met with "Will you come and fix it?", "I demand that X, Y or Z tool is available for me to use", etc., so again, I'm sorry but I'm not buying this argument. Some things we can solve by an opt-in, like the strict_types declare, however other things so fundamental to the language should not have any options to alter its behavior, that should be consistent. We have spend a long time trying to carve a migration path and advocate against options which changes language behavior across installations. If we continue down this path, then its just a runtime version of php.ini with a million declare statements on top of each file, each having multiple meanings and an added complexity to maintain the code, not a burden I think userland developers need as it is. -- regards, Kalle Sommer Nielsen kalle@php.net
  106743
August 28, 2019 16:04 chasepeeler@gmail.com (Chase Peeler)
On Wed, Aug 28, 2019 at 11:37 AM Kalle Sommer Nielsen <kalle@php.net> wrote:

> Hi > > Den ons. 28. aug. 2019 kl. 17.54 skrev Chase Peeler <chasepeeler@gmail.com > >: > > You going to come and fix the issues? It's an internal application and > > most of those messages are coming from legacy areas of the code which are > > mainly "it works, so leave it alone" things. Instead of going back and > > spending time trying to fix those boondoggles, we invest the time of our > > developers (there are 2 others besides myself) into building new features > > that help our business grow. Time permitting, we try and update some of > the > > legacy areas, but, we usually find it's a better investment to just > rebuild > > them at that point. > > > > Bottom line is that we live with the not-so-good stuff so that we can > focus > > on adding new great stuff. The not-so-good stuff isn't holding us back, > and > > trying to fix things like undeclared variables would have absolutely ZERO > > positive effect on our business, which uses this application every day. > If > > I went to our executive team and said "Can we delay that new scheduling > > system that will really help our business so I can go back and update > code > > to get rid of these undeclared variable notices?" I'd get laughed at! > > > > Like I've said before - can we please stop pretending we understand > > everyone else's situation? Maybe my situation is unique. My gut tells me > it > > might be unique among people on this list, but, that it's actually pretty > > common among the myriad of developers out there which never get involved > in > > these discussions. > > I'm sorry, but like Mark Randall has already pointed out then this is > a classic example of technical depth. At one point you must choose, > "Do I want to upgrade to the latest version of PHP or do I want to fix > the issues which is caused by the technical depth in my stack?".
I don't get to make that choice, though. The executives do.
> I get > it, writing new code is always more fun, it really is,
It's not about what is more fun. It's about what is necessary for our company to grow, move forward, and survive. What good is fixing old code if our company withers away while we do it since we aren't supporting them with the new things the need to move forward? We aren't building things on top of that old code, so, the new things we build aren't accruing additional technical debt as a result of the existing technical debt. I have
> previously worked with companies with that same attitude that "we'll > fix it later", but at one point that becomes such a burden and if your > management doesn't believe in putting in resources to actual > maintenance of your infrastructure, then I'm sorry but it does not > sound like a healthy place to be (no offense meant). > > That's not exactly our attitude. If something is really broken, we fix it. We are not focusing our limited resources on updating things that currently
work just because we don't like how they were built. Most of it was done 10-15 years ago, and, even if we had the resources to update it, we'd be better off just rebuilding it altogether. Let me focus on the technical debt that has high interest, instead of the debt that doesn't really impact anything, like undeclared variables.
> Right now your argument is merely trying to hold back changes which > will bite that technical depth of yours, and everytime an argument has > been raised towards your concerns it has been met with "Will you come > and fix it?", "I demand that X, Y or Z tool is available for me to > use", etc., so again, I'm sorry but I'm not buying this argument. > > No, it's just that we should weigh the positives and the negatives. If we want to move PHP forward, we need to look at new features, and fixing old
things that are really broken. I don't consider undeclared variables only generating a notice to be something that's "really broken." It still might be worth doing, though, if there isn't much of a reason not too. The current system doesn't prevent anyone from properly initializing their variables. Nothing prevents a company from doing code reviews or employing other tools to make sure their developers always initialize their variables. Why do we have to FORCE everyone else that wants to use PHP to do that as well? To me, what makes PHP great is its flexibility. Does that mean some people out there write some really bad code? Yes, it does. Heck, a lot of that code lives in our legacy code base and was probably written by me. But, the flexibility doesn't PREVENT anyone from writing truly great code, either. The only things that prevents great code are the great features we haven't implemented. Instead of focusing on those, it seems we spend our time trying to decide how we can take away some of the languages strengths. Even if you don't view it as a strength, is it really such a weakness that it's hurting the language? Some things we can solve by an opt-in, like the strict_types declare,
> however other things so fundamental to the language should not have > any options to alter its behavior, that should be consistent. We have > spend a long time trying to carve a migration path and advocate > against options which changes language behavior across installations. > If we continue down this path, then its just a runtime version of > php.ini with a million declare statements on top of each file, each > having multiple meanings and an added complexity to maintain the code, > not a burden I think userland developers need as it is. > > I agree. I don't think an opt-in is a great way to do it. That's why I think it just shouldn't be done. I just view an opt-in model as the least
evil way to do it, if we do in fact have to do it.
> -- > regards, > > Kalle Sommer Nielsen > kalle@php.net >
-- Chase Peeler chasepeeler@gmail.com
  106784
August 29, 2019 04:52 php-lists@koalephant.com (Stephen Reay)
> On 28 Aug 2019, at 23:04, Chase Peeler <chasepeeler@gmail.com> wrote: > > On Wed, Aug 28, 2019 at 11:37 AM Kalle Sommer Nielsen <kalle@php.net> wrote: > >> Hi >> >> Den ons. 28. aug. 2019 kl. 17.54 skrev Chase Peeler <chasepeeler@gmail.com >>> : >>> You going to come and fix the issues? It's an internal application and >>> most of those messages are coming from legacy areas of the code which are >>> mainly "it works, so leave it alone" things. Instead of going back and >>> spending time trying to fix those boondoggles, we invest the time of our >>> developers (there are 2 others besides myself) into building new features >>> that help our business grow. Time permitting, we try and update some of >> the >>> legacy areas, but, we usually find it's a better investment to just >> rebuild >>> them at that point. >>> >>> Bottom line is that we live with the not-so-good stuff so that we can >> focus >>> on adding new great stuff. The not-so-good stuff isn't holding us back, >> and >>> trying to fix things like undeclared variables would have absolutely ZERO >>> positive effect on our business, which uses this application every day. >> If >>> I went to our executive team and said "Can we delay that new scheduling >>> system that will really help our business so I can go back and update >> code >>> to get rid of these undeclared variable notices?" I'd get laughed at! >>> >>> Like I've said before - can we please stop pretending we understand >>> everyone else's situation? Maybe my situation is unique. My gut tells me >> it >>> might be unique among people on this list, but, that it's actually pretty >>> common among the myriad of developers out there which never get involved >> in >>> these discussions. >> >> I'm sorry, but like Mark Randall has already pointed out then this is >> a classic example of technical depth. At one point you must choose, >> "Do I want to upgrade to the latest version of PHP or do I want to fix >> the issues which is caused by the technical depth in my stack?". > > > I don't get to make that choice, though. The executives do. >
I thought you said you were the tech lead? Part of building an application is maintaining it. And honestly, your claim about “it’s technical debt that is no longer growing” is incorrect. Like financial debt, technical debt will accrue “interest” - in this case, it’s going to prevent you from upgrading to a newer release of PHP. Believe me I understand your situation, in terms of code very well. This RFC, the short open tags one, and probably some more before 8.0 is frozen will all affect an active client project I’m tech lead for. In every case, I’m still for the change: because making the change means one less type of sloppy-but-“working” code I’m going to see and have to task someone to fix in the future. If you can’t currently schedule some percentage of development time to maintaining/fixing existing code, (you *did* say you’re the tech lead, right?) this RFC makes your job easier then: you have an external control factor that your executives (who apparently make technical decisions?) cannot argue against, and cannot deny.
> >> I get >> it, writing new code is always more fun, it really is, > > > It's not about what is more fun. It's about what is necessary for our > company to grow, move forward, and survive. What good is fixing old code if > our company withers away while we do it since we aren't supporting them > with the new things the need to move forward? We aren't building things on > top of that old code, so, the new things we build aren't accruing > additional technical debt as a result of the existing technical debt. >
Well presumably a working, secure application/website is necessary for the company to just survive, let alone grow.
> I have >> previously worked with companies with that same attitude that "we'll >> fix it later", but at one point that becomes such a burden and if your >> management doesn't believe in putting in resources to actual >> maintenance of your infrastructure, then I'm sorry but it does not >> sound like a healthy place to be (no offense meant). >> >> That's not exactly our attitude. If something is really broken, we fix it. > We are not focusing our limited resources on updating things that currently > work just because we don't like how they were built. Most of it was done > 10-15 years ago, and, even if we had the resources to update it, we'd be > better off just rebuilding it altogether. Let me focus on the technical > debt that has high interest, instead of the debt that doesn't really impact > anything, like undeclared variables.
Exactly how many instances of undeclared variables do you have? This talks about PHP8, so its expected 7.4 due late November this year will be the last version that doesn’t error on your code. 7.4 will have 2 years of full support and a further year of security support. Can you *really* not find the time to fix undeclared variables in the next 39 months?
> >> Right now your argument is merely trying to hold back changes which >> will bite that technical depth of yours, and everytime an argument has >> been raised towards your concerns it has been met with "Will you come >> and fix it?", "I demand that X, Y or Z tool is available for me to >> use", etc., so again, I'm sorry but I'm not buying this argument. >> >> No, it's just that we should weigh the positives and the negatives. If we > want to move PHP forward, we need to look at new features, and fixing old > things that are really broken. I don't consider undeclared variables only > generating a notice to be something that's "really broken." It still might > be worth doing, though, if there isn't much of a reason not too. The > current system doesn't prevent anyone from properly initializing their > variables. Nothing prevents a company from doing code reviews or employing > other tools to make sure their developers always initialize their > variables. Why do we have to FORCE everyone else that wants to use PHP to > do that as well? > > To me, what makes PHP great is its flexibility. Does that mean some people > out there write some really bad code? Yes, it does. Heck, a lot of that > code lives in our legacy code base and was probably written by me. But, the > flexibility doesn't PREVENT anyone from writing truly great code, either. > The only things that prevents great code are the great features we haven't > implemented. Instead of focusing on those, it seems we spend our time > trying to decide how we can take away some of the languages strengths. Even > if you don't view it as a strength, is it really such a weakness that it's > hurting the language?
Yes. Because people will write code that abuses it, and projects end up where you are now: with ridiculous (in terms of the amount and also how simple it is to fix) technical debt, arguing that PHP shouldn’t become objectively better, because it’s going to break their apparently unmaintained application.
> > Some things we can solve by an opt-in, like the strict_types declare, >> however other things so fundamental to the language should not have >> any options to alter its behavior, that should be consistent. We have >> spend a long time trying to carve a migration path and advocate >> against options which changes language behavior across installations. >> If we continue down this path, then its just a runtime version of >> php.ini with a million declare statements on top of each file, each >> having multiple meanings and an added complexity to maintain the code, >> not a burden I think userland developers need as it is. >> >> I agree. I don't think an opt-in is a great way to do it. That's why I > think it just shouldn't be done. I just view an opt-in model as the least > evil way to do it, if we do in fact have to do it. > > >> -- >> regards, >> >> Kalle Sommer Nielsen >> kalle@php.net >> > > > -- > Chase Peeler > chasepeeler@gmail.com