Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106743
MIME-Version: 1.0
References: <CAF+90c9Kc6m_bv=aJxbD3-RmnNXXLqv6mPjHp7U7qxX_ck27qw@mail.gmail.com>
 <CAJHtznyadHb5_RgjddnPiyeWXtLQyp2CDK=ix=BiEd+DEUHqLg@mail.gmail.com>
 <CAF+90c_94zAj-7XW+=YtZ2VsZEshd4DvNY8_17PyiBXvYR1gdw@mail.gmail.com>
 <CAJHtznw5wOTMA-BUO6hOARxSie75+PwccSocVapHi4k02Z+x0A@mail.gmail.com>
 <CAPKYkKzc37d52ZjHy0ht6Oc_HgoBq4+DandNW1Hk-+x5NnUS7Q@mail.gmail.com>
 <CAPKYkKwhUmq40yGta3+ERfcDOOrkPi5Db6-i7pPMRmV4CrQRTQ@mail.gmail.com>
 <7ddbae5c-7451-4094-8b32-19676128054b@thelounge.net> <CAPKYkKyYvqW9Hm-nae0CXJ98XxRzt7XRpe_+FzeqiJME3K4jug@mail.gmail.com>
 <CAPKYkKw5vxgeM+vq_z9YhNYEMuPodCjfGNv6BRFS+bg0BG-Q0w@mail.gmail.com>
 <CAOkcCt_xsP1AOwB0-nuY4_qwxSc3h8mns_Yax9UnrLzFCN-m+g@mail.gmail.com>
 <CAPKYkKxAkowF_H9gDZg2pDVdUyftJz0b2LAE08jW8jjA6Nq-uw@mail.gmail.com>
 <CADyq6sJd6=2UEXXrad2heYw4Mp876rSQ9ZcKeuXOKEWO8F2saA@mail.gmail.com>
 <CAPKYkKw7Q7A4Z5TkgNX-=LPZZy7_orCRUsULBA7j=wZgKU-VuQ@mail.gmail.com> <CAJW__o19_rchtPgdC5mAKGvLpemjdy8uJP_BJ6Xq9Ctbs0C_7g@mail.gmail.com>
In-Reply-To: <CAJW__o19_rchtPgdC5mAKGvLpemjdy8uJP_BJ6Xq9Ctbs0C_7g@mail.gmail.com>
Date: Wed, 28 Aug 2019 12:04:19 -0400
Message-ID: <CAPKYkKwoE7_enm83OrQ3-ebnxWrmATw2E5RNqYXqWW7H449A3w@mail.gmail.com>
To: Kalle Sommer Nielsen <kalle@php.net>
Cc: Marco Pivetta <ocramius@gmail.com>, Gert <gertp93@gmail.com>, 
	PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000005c452605912f8b6e"
Subject: Re: [PHP-DEV] [RFC] Reclassifying engine warnings
From: chasepeeler@gmail.com (Chase Peeler)

--0000000000005c452605912f8b6e
Content-Type: text/plain; charset="UTF-8"

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

--0000000000005c452605912f8b6e--