Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120043
Message-ID: <7d815024-814a-8880-56ed-4a8cb4689c35@helionweb.de>
Date: Sat, 15 Apr 2023 20:25:48 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.7.1
Content-Language: de-DE, en-US
To: PHP internals <internals@lists.php.net>
References: <aa9f0f66-f772-3fc4-4f66-2245930ab089@helionweb.de>
 <CAEZPtU6qV1OEBt7kaVoaxog=Wd4AZWNyiJW=1NMkASW8AJkRTA@mail.gmail.com>
 <CADK1yXLie-hPJwKSUqpBgpOkWPBrBvcaXdFfLKxDMPbcT=1dYA@mail.gmail.com>
 <CAL0xaBGCw7szRaqJNdDHuZVoATms7dhCus4eXjUacAnLpBz+GA@mail.gmail.com>
 <CADK1yXKCKzq=965HT85nYoJcQqfp=X_L1b_O6zpAn0UoxS66+Q@mail.gmail.com>
 <CAL0xaBH2OtLg0wiTHPr8L9=uz+No6zxoUMYA6avORra5qEdAcg@mail.gmail.com>
 <CADK1yXJP__a8ZzFpkXsUsh3DxJFDcB4gppOYV9AnwaAcBfKExg@mail.gmail.com>
 <CAL0xaBGfoc5UF=U82o8PXrObcikozswkX2LFHN9BJg7PwX0ZJA@mail.gmail.com>
 <5E8E5486-B715-45DF-AB6F-35434CFB78D2@sewell.info>
In-Reply-To: <5E8E5486-B715-45DF-AB6F-35434CFB78D2@sewell.info>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] Future stability of PHP?
From: stephan.soller@helionweb.de (Stephan Soller)

> 
> I generally come across 3 types of projects:
> 1. Projects that were originally developed a number of years ago and have not been updated since
> 2. Projects that were originally developed a number of years ago and have been updated regularly since
> 3. Projects that were originally developed in the last 5 years and have been updated regularly since

Interesting categorization, especially the 5 years part. Looks like I 
misjudged the magnitude of the shift in the PHP community a few years 
back (not just from your categorization, but from what others wrote as 
well).

I think of languages as tools specialized for a given problem space. 
Even general purpose languages have a lot of design decisions that make 
them better suited for specific areas than others (e.g. memory 
management, threading, scripting, …). And usually there's some spillover 
of thought patterns from one language community to another (e.g. someone 
programming Java in PHP, JS in Ruby, C++ in C). I thought those 
spillovers were merely affecting the language design a bit more than 
usual. After all if I want a statically typed language there are already 
ample to choose from.

But this was clearly the wrong mindset on my part. I usually combine 
various languages in a project, mostly depending on whats already part 
of the environment, well maintained and stable. So my focus is on when 
to combine what tools and languages. But from your post and others in 
the topic most (if not all) seem to work on larger code bases mostly 
focused on PHP. And in this situation it makes more sense to bring 
static typing into the used language. Thanks for clearing that up.


> 
> Generally projects in 1 match what Stephan described:
>> My usual tool set for web projects like that is plain PHP, HTML, CSS and JS. Everything without any frameworks or unnecessary libraries and kept as simple as possible. If possible I just use builtin and stable APIs and usually end up without any or with just one or two dependencies (e.g. PDF generation).
> 
> I've tried to keep this generic, but in a lot of cases I see this with local government work that was developed several years ago (generally PHP 5). They had budget up front to build something but then expected to maintain it without any code changes, just by updating the OS and PHP. They perfectly match Stephan's use case group:
>> I think a lot of programmers underestimate the flexibility and simplicity of file based webservers like Apache with PHP. If you keep it simple they allow projects to grow organically.
>> A lot of that are just small projects, small customers or the inglorious everyday work that nobody likes but someone has to do. So it doesn't get talked about much.
> 
> These tend to run for 10 years plus.

I haven't worked on any government projects, but I guess industry and 
process automation isn't that different (maybe a bit less bureaucratic). 
Machines run for decades and I guess this also sets the time-frame or 
mindset for the software used in there (ERP systems, CRUD-like stuff 
that models small processes, etc.). Maintenance of course is part of the 
picture but on the software side admins are expected to take care of 
that. Actually changing code to keep it running as-is isn't expected, 
and of course this shapes budgeting. Except for the industry 4.0 
subculture, that seems to be a totally different set of people. But I 
have no idea if my experience is representative of the industry. Most of 
my experience comes from companies in the range of 100-200 employees 
(with maybe 5 IT people) or smaller.

I've used PHP in such environments several times, funnily enough because 
it was the preferred option for the admin. Maybe the budgeting is my 
hint that I shouldn't do that again.

Apart from that I often employ a way of programming that seems to be 
quite different from what other posts describe. I usually optimize for 
minimal complexity, minimal dependencies and maximal stability. Taking 
advantage of the environment to reduce the number of moving parts where 
I can. You could say I hunt for synergies between tools to avoid 
complexity. This often means taking a bit longer at the beginning or 
sometimes using weird tools because they're already an indispensable 
part of the environment. A classic is letting an already existing 
webserver handle authentication via LDAP or Active Directory. It pays of 
in the long run with low maintenance overhead. It's not zero, bugs 
happen, stuff changes, but it's maybe a code change every few years 
instead of every few months.

For me this is just another way to write software. It works in some 
situations, it doesn't work in others. Since my projects are usually to 
small to justify a team of programmers I end up using it quite often though.

Also almost all of my projects are one-off "built something that does X 
in our environment" things. Not evolving products that get regularly 
extended (I have just one of those). Hence its difficult to piggyback 
regular cleanup on feature updates.

I maintain my code and take care of notices and deprecation warnings. 
But mainly I try to avoid features that might get deprecated. I restrict 
myself to a conservative subset of the language. Last time I've had to 
put effort into updating some code bases was with PHP 5.3 (it was just 
one small language change, though). It was smooth sailing ever since. 
Until PHP 8.2 recently, which indicated that some of my core assumptions 
about PHP got out of touch with reality.


Thanks to everyone for sharing your thoughts. All of this gave me a way 
better handle on how the PHP community ticks right now. I was surprised 
by the emotional component of the discussion but I hope I didn't make to 
much of a mess for everyone.

Happy programming
Stephan