Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122346
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.11.0-alpha0-144-ge5821d614e-fm-20240125.002-ge5821d61
MIME-Version: 1.0
Message-ID: <90cc47f7-ba80-4798-8447-2f3bb5734eab@app.fastmail.com>
In-Reply-To: 
 <CAK=iT=VzVOTbqh_v4zcu3MjPq+QzWcstMJnz0z1LPZEbJVVAcQ@mail.gmail.com>
References: 
 <CAK=iT=UrMCPw5ydCnxa_87ws6xKRO5Y3qJnmchczgDds8u660A@mail.gmail.com>
 <CABigaAUjSx3-vEaQhPk-toJTSg+J3CLrO3otpm1g6hqbYyQKvw@mail.gmail.com>
 <CAK=iT=WgsEZjyu3Y2wTWvycqCsYH7MrLsZgERZK3u75U08ePpA@mail.gmail.com>
 <CAL0xaBHfEMs1BVAMZOuFCUpb9orNSRD0YDhu=3wJAGK7K0_=dg@mail.gmail.com>
 <CAK=iT=XDVcs+y4XDmGu2re137i2yD9LiEj1-HLvyxxxrb8jFUw@mail.gmail.com>
 <CAK=iT=UDUjCZ-25k_MkHFO7uKdWAqoJxdWLVBGM2_SYDk-JyAg@mail.gmail.com>
 <742f202d-7990-4f51-b903-7a15e3fd33c2@app.fastmail.com>
 <CABigaAW2KeGxf7HnzpcOeS=CL31=UNGZnqpZvoJsJg4miBTBGw@mail.gmail.com>
 <1cd8fa7b-ab62-4563-bf13-bb7801f1ce8d@app.fastmail.com>
 <CAK=iT=X5XKdSZ1D=+SEU4=12hJK+oPn+XBWxA54yyQsxAixx8A@mail.gmail.com>
 <CAOyH9yT5NQQYgq=5O5q==BaTpm-JJRDUcAsX2Tc36hbXLdH5vw@mail.gmail.com>
 <CAK=iT=W7xzS_9FZj-Cd1uUBaLtX=157t81_KOkr999bRyTcDjw@mail.gmail.com>
 <CAOyH9yQKA+RnhXFHvH=dVHT8UWfyF_A89p_c9wES1k4kKstBtA@mail.gmail.com>
 <CAK=iT=VtOx=dZYNMNnn0iVPm4KUy1BoCr07=WYJFR9HJOOKLPg@mail.gmail.com>
 <CAOyH9yTJNq9Y+OcOGw7bkfU7efxoz+0bUt9iyy949_Zj=1_M1g@mail.gmail.com>
 <CAK=iT=VzVOTbqh_v4zcu3MjPq+QzWcstMJnz0z1LPZEbJVVAcQ@mail.gmail.com>
Date: Thu, 08 Feb 2024 16:00:42 +0000
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Feature request: https://github.com/php/php-src/issues/13301
From: larry@garfieldtech.com ("Larry Garfield")

On Thu, Feb 8, 2024, at 11:15 AM, =D0=93=D1=80=D0=B8=D0=B3=D0=BE=D1=80=D0=
=B8=D0=B9 Senior PHP / =D0=A0=D0=B0=D0=B7=D1=80=D0=B0=D0=B1=D0=BE=D1=82=D1=
=87=D0=B8=D0=BA Web wrote:
> Just because PHPStan is a ready solution for design errors that you can
> predict.
> My case is about errors that you detect later, after the design is
> finished, PHPStan shows you that "all done!".
>
> Because it's not \LogicExceptions (types, mappings), it's all
> \RuntimeExceptions... You have to implement it after the design is don=
e!
> Also writing code comments for PHPStan accidentally increases time of
> catching \LogicExceptions that will be autocatched once an exception
> happens and is reported. This is necessary work, but it increases the
> estimate; the business does not want to hear long deadlines, and consi=
ders
> you ineffective. But if you say too small, the code will not even pass
> PHPStan, it will not even pass visual inspection. Therefore, I say some
> magical things, and then I correct them, for some reason they like this
> approach better, they are not used to improving until everything works
> properly, they even push the word into the lexicon - MVP. This means =E2=
=80=9Cit
> doesn=E2=80=99t work well but it works=E2=80=9D, it seems normal to th=
em in order to get
> results faster. Because they will receive bonuses for results, but for=
 bad
> results you will receive punishment.
>
> A closer solution is "get out from the job where business was built th=
at
> way to ignore complainings". I had worked for 12 years. I've changed a=
 lot
> of jobs because of that. And any new job is the same. It could be more=
 or
> less ready to build the same, but they are working on it. It's not a
> solution either. As a result - "you cant rebuild
> non-yours successful business that gives you money because you know how
> things work", you have to fix or lose your rent home.
>
> =3D=3D=3D
>
> @Arvids Godjuks <arvids.godjuks@gmail.com>
>
> I had to work in such companies, and there were 13 projects at the mom=
ent.
> But after some time I realized that nothing depends on the number of
> projects. All businesses strive to not give away the right to think to
> their employees. If this happened, it was more an accident than a goal=
. If
> they are forced to listen to you, you are considered a problem that th=
ey do
> not yet know how to solve.
>
> Now my company has only one project, which they are leading themselves=
. But
> business and profit dictate the conditions - at first we do a year very
> quickly, then we redo it for 3 months, which we will have time, but the
> amount of legacy is too large, because the pace is insane, and the tas=
ks
> are becoming more and more difficult.
>
> They can't just "wait quietly until you finish." They will ask you whe=
n,
> and will be disappointed if you suddenly suddenly realized that you ne=
ed to
> move the deadlines, because there are already 5 new ones behind the cu=
rrent
> task and they are planned for the quarter. =E2=80=9CRewrite better=E2=80=
=9D is not included
> in them.
>
> Let's stop discussing my personality, I gave a rationale for why langu=
ages
> should preferably help developers, since such a question arose. Because
> there won=E2=80=99t be fewer situations like mine, but there will be m=
ore jobs. And
> there will be a lot more bad companies, and in the end there will be v=
ery
> bad ones left.

OK, there's multiple, really unrelated things going on here.  Let's cut =
to the chase:

It sounds like the root problem is not code, but management.  The OP's m=
anagement is insisting "make change X to a bad codebase, but we'll give =
you 1/10 as much time as doing it properly actually needs."  That is a s=
ocial problem, not a technical problem.  No software will solve a social=
 problem.  In this case, the social problem is "your manager is an abusi=
ve moron."  Sorry, PHP cannot help you with that, no matter what feature=
 we add.

Moreover, adding features to the language to make it easier to write slo=
ppy code that will be harder for the next person to maintain is a losing=
 proposition.  It will just compound on itself until both the language a=
nd applications written in it are universally trash.  PHP has spent 20 y=
ears digging out of "quick and easy" design decisions that were made bac=
k in the 90s that are still causing problems today.  I do not see any ap=
petite for adding more such structurally-poor features.

There may be an appetite for adding features that make it easier to writ=
e good code that is self-correcting.  We can (and do) debate what featur=
es qualify for that description, and whether my checked exceptions propo=
sal qualifies for that, but that's independent of "my boss is asking the=
 impossible."  It's not the language's job to solve for bad bosses.

I think what you're looking for (since your descriptions are not particu=
larly precise) is a customizable version of json_last_error() and friend=
s, which operates on global state.  I am only one vote, of course, but b=
ased on prior discussions here I don't believe there will be any support=
 whatsoever for a global-state-based error mechanism in PHP, ever.  If a=
nything the trend is to move away from that, in part because it makes "h=
ack random shit into random crappy code with more globals" harder.  That=
's a good thing.

If that's the case, we should probably just close this thread and potent=
ially move the checked exceptions discussion to a new thread, if anyone =
else is interested in continuing it.  But the original request here is, =
if I am understanding it, dead on arrival.  No amount of talk about bad =
bosses with poor expectations will change that.

--Larry Garfield