Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:106784 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 82639 invoked from network); 29 Aug 2019 07:20:27 -0000 Received: from unknown (HELO mail1.25mail.st) (206.123.115.54) by pb1.pair.com with SMTP; 29 Aug 2019 07:20:27 -0000 Received: from [192.168.0.101] (unknown [125.27.133.232]) by mail1.25mail.st (Postfix) with ESMTPSA id 87DFE604FE; Thu, 29 Aug 2019 04:52:33 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) In-Reply-To: Date: Thu, 29 Aug 2019 11:52:29 +0700 Cc: Kalle Sommer Nielsen , Marco Pivetta , Gert , PHP internals Content-Transfer-Encoding: quoted-printable Message-ID: <21863BE0-DD4D-4462-A5FC-14B50AE55134@koalephant.com> References: <7ddbae5c-7451-4094-8b32-19676128054b@thelounge.net> To: Chase Peeler X-Mailer: Apple Mail (2.3445.104.11) Subject: Re: [PHP-DEV] [RFC] Reclassifying engine warnings From: php-lists@koalephant.com (Stephen Reay) > On 28 Aug 2019, at 23:04, Chase Peeler wrote: >=20 > On Wed, Aug 28, 2019 at 11:37 AM Kalle Sommer Nielsen = wrote: >=20 >> Hi >>=20 >> Den ons. 28. aug. 2019 kl. 17.54 skrev Chase Peeler = >> : >>> 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. >>>=20 >>> 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! >>>=20 >>> 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. >>=20 >> 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?". >=20 >=20 > I don't get to make that choice, though. The executives do. >=20 I thought you said you were the tech lead? Part of building an = application is maintaining it. And honestly, your claim about =E2=80=9Cit=E2=80=99s technical debt that = is no longer growing=E2=80=9D is incorrect. Like financial debt, = technical debt will accrue =E2=80=9Cinterest=E2=80=9D - in this case, = it=E2=80=99s 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=E2=80=99m tech lead = for. In every case, I=E2=80=99m still for the change: because making the = change means one less type of sloppy-but-=E2=80=9Cworking=E2=80=9D code = I=E2=80=99m going to see and have to task someone to fix in the future. If you can=E2=80=99t currently schedule some percentage of development = time to maintaining/fixing existing code, (you *did* say you=E2=80=99re = 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. >=20 >> I get >> it, writing new code is always more fun, it really is, >=20 >=20 > 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. >=20 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). >>=20 >> 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=E2=80=99t 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? >=20 >> 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. >>=20 >> 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? >=20 > 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=E2=80=99t = become objectively better, because it=E2=80=99s going to break their = apparently unmaintained application. >=20 > 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. >>=20 >> 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. >=20 >=20 >> -- >> regards, >>=20 >> Kalle Sommer Nielsen >> kalle@php.net >>=20 >=20 >=20 > --=20 > Chase Peeler > chasepeeler@gmail.com