Lol.

It recently happened to me twice that, very quickly after opening a bug report for an OSS project on GitHub, a random dev with a very junior pedigree popped up, sending a PR to fix the issue.

The weird thing is that those PRs came with a strong vibecoding-bot vibe attached to them, not in the quality of the code, but rather in the way their devs handled interaction with the project's ecosystem - disregarding existing PRs and open tickets relating to the same issue, and not even attempting meaningful discourse with others.

Needless to say, this consumes valuable bug-triaging time and effort - and we are not even talking security issues and non-disclosure coordination...

I just hope this fad passes, either by those bots upping their game, or by the script kids running them just loosing interest.

Same old, same old.

In the real world, most non-geek people I know never update anything, be it phone, computer or other electronic gadget.

It's not hard to figure out why: everyone has been bitten at least once by a bad update, and remembers it bitterly. Otoh not everyone has been hacked, or at least not-every-device-they-own has, so on balance the inconvenience from upgrades is bigger than the inconvenience from hacks.

With the AI-bugfinding floodgates open, we will be on a rollercoaster ride for months, most likely more. Meaning weekly rollouts of kernels, and huge churn in all apps, be they OSS or not. Which means more people getting burned by faulty updates.

Imho, in an ideal world, every software would have to have mandatory support durations and a minimum number of LTS releases supported at any given time.

Alas, most (all?) developers I know don't care about users running old software versions, and can not be bothered to put in that kind of effort. They really resist the idea of separating bugfix-only branches from shiny new features - a position not entirely without merit, see the xkcd spacebar heater.... If anything, the industry has been moving steadily towards a quicker release cadence, and linux distributions have been loosing grounds to alternative, developer-driven distribution channels, such as container images or language-specific package managers.

Making software more modular would be one way to improve the situation where users might want all bugfixes and one or two new features out of the 99 added to a software release. But modularity is hard, as it brings combinatorial explosion to code paths and testing procedures.

I guess there is no free lunch?

PS: re. the Android ecosystem being proof that frequent updates work - I would posit the opposite: it is proof that infrequent updates are fine. And that, given a large enough userbase, every update is dangerous.

Case in point: I have been hit just this week by a bug most likely related to the kernel: my Samsung Galaxy's (postmarket) screen, after applying the latest OS update, stopped responding to any finger interaction. I went as far as having the phone opened to check for hw issues, and testing a new (postmarket) screen replacement, which unfortunately behaved the same way. The only option left is to try a factory reset, which, in the best case scenario, will bring along the huge pita of having to reinstall and configure all apps and overcoming 2fa impediments (I'm looking at you Google and Meta: phones do break down from time to time. Please make it easy to transition to a new one when the old one is not accessible any more!!).

Insightful comment, with which I mostly concur.

What would be an ecosystem which is well ahead of PHP, in 2025?

Call me a boomer, but I hate the "Amazon Fresh" buying experience - I'll take any day a shop where
- I can pay with cash
- I can pay with a credit card
- I do not have to fear that, if I pick up an item and then put it back on the shelf, the system will think that I have taken it out anyway
- I am forced to use my all-encompassing online profile to buy bread and milk, and give away all my grocery habits to the same company who already has info on my online shopping and music/video listening
 

1. Use PHPStorm. If you contribute regularly to OSS, you can get a free license from them. If not, it is worth its every penny multiple times over. VSCode is nice, but it does not come close in the level of intelligence it has in analysing PHP code and figuring out the slightest mistake or code-smell. It also has great integration oob with the whole ecosystem, from grokking composer files to ofc git, rdbms and ssh support - but it does not force any of that on you, apart possibly for the "work on a project at a time, do not open a file at a time" paradigm.

2. About switching to a framework, as others have pointed out, the answer is "it depends":
- do you need to onboard junior devs? If so, using a well known framework will save them learning time
- is your own code high or low quality? would you throw it away and refactor it in any case, or is it good enough to only require minimal maintenance? if the latter, do not bother rewriting
- being able to rely on someone else's implementation for "tricky" bits such as authn/autz, rdbms abstraction etc... is a benefit in your situation, or is it a hindrance?
- what's the expected support lifetime of your code? can you find a framework which has the same lifetime and is not likely to disappear on a whim? what are its BC promises?
- do you have comprehensive testing, functional+integration, or not at all? if you have no tests, refactoring is a big gamble
- is your code already well separated into SOLID components, or is it an organically grown bowl of spaghetti? If it is, a framework can be introduced piecewise, sliding in one component at a time*

* = this is a bit of a stretch in fact. What you could use to piecewise-replace your own code is generally acknowledged as being a "library", whereas a framework is more of a coherent whole application which calls out your code here and there.

BUT

Symfony comes with both a framework and a set of independent, well tested, maintained and documented components.

A good "middle of the road" choice could be to start using piecewise those components, until all the pieces make sense and click together, and possibly introduce the full fledged framework in a later, final step. Begin with using eg. dotenv for managing the settings, twig to separate the presentation layer, psr/log for logging (and later introduce monolog), adopt an Entity/Repository pattern.

In a recent project I worked on, where the prime directive was "no external code, full auditability is required" I ended up implementing from scratch most of the components mentioned above. Just copying the necessary parts of the Sf components API gave me reassurance about the solidity of the patterns adopted, as well as keeping the door open for possible swap-out-this-component scenarios in the future.

PHP has evolved a lot since HACK was created.
Today it is much faster (eg. it does include JIT), flexible (eg. anonymous functions as first class construct), consistent (in every release a few warts get corrected), and safer (allowing more type hinting but also readonly attributes, enums, etc...).

Talk about battles lost ages ago...

Nowadays most apps are web apps, most actions in web apps happen via js code making http requests to retrieve or push data, and most of that code gives _zero_ feedback:
- no visual feedback such as graying out or change of colour of the clicked control
- double-clicking is not prevented
- cursor does not change to a spinner
- worst offender of it all: quite often there is no feedback at all if the http request fails for any reason, or if it brings back unexpected data

Japan begs to differ.

It has as much automation as any other country in the world, if not more, and it works 100% on cash.
Everywhere you would see a PoS system in the EU/US, they have an automaton taking both cash and cashless instead. Often just cash, or even, shudder, only coins!

I am not saying that this works better in practice: on one hand having to travel with pockets full of coins is something I don t long for, usually, and on the other hand I am not sure how much more resilient to network failures their cash handling machines are compared to a debit-card pos.

As for getting robbed or pulled-over with a large wad of cash: I think the most common "need to be able to do thing" in a 'global hack attack' scenario is not to book within the day your flight to the other side of the world or buy an high end stereo system, but rather to buy groceries and pay a cab to get home or to a nearby hotel. Something around $50 should be enough as emergency sum to be carrying around...

Must have gone to the same high school as ebassi... ;-)

That's in fact one of the things which eZPublish always did better than Drupal - have a great focus on BC.
Sorry you picked the wrong CMS ;-)

Fully agree.

Up to the move from 7 to 8, PHP had in fact quite a good track of keeping BC. The last time changed so dramatically was when switching from 4 to 5, in 2004.
I can not compare to all other widespread languages, as I don't use them on a daily basis, but much better than Python, for sure.

Sure, there are changes in each and every release, and as we know every bugfix can be perceived as a painful BC breakage by developers (cue the obligatory XKCD - nr. 1172...). But most of the time, if your program breaks in massive or unexpected ways on minor PHP version updates, it is because it was sloppily coded. The fact that PHP has always allowed coders to be sloppy can not really be argued... in fact it is a huge part of its original success, and at the same time it is most likely also a big driver behind the current maintainer's urge to make the language stricter! :-D

As a side note: I maintain a bunch of php libraries which are compatible all the way from PHP 5.4 to 8.3, within a single codebase, and with no IFDEFS in sight. So I know this is possible

Not sure you wanted to reply to my comment, or the parent.
As for me, eZPlatform (ex eZPublish) has been paying my bills since 2007.
To this day, I still find it a better CMS than Drupal - even though I think it peaked around version 4.7...

I sure hope that Poetry won't be the only Python package manager going forward, as I just settled on PDM instead - the feature set looked similar, but there were far fewer horror stories about bugs and disregard for api/abi breakages (which is paramount for any dev tool in daily use) :-D

As for Pip, it might be just me, but it seems stuck in the 90s, when it was not yet necessary to update your project's (transitive) dependencies every other week - which is sadly a fact of life for anything exposed to the web. It is incapable of catering to the very simple scenario where you specify in your requirements file only the 2-3 libs you are actively using in your code and it takes care of writing down in a lock file all the installed libs, allowing you to later run an update command which will update everything while respecting semantic versioning, or checking for available updates - ie. without forcing you to specify by yourself the desired version of transitive dependencies. The closest I could get to that is via other tools on top of pip, which do not seem to be as widely adopted or well maintained...

And about type coercion: it might be frowned upon, but is this not happening basically all the time, when you do f.e. `f"the chosen color is: '{color}'"` ? Also, considering that APIS such as the Django Models give you back DB data as either a string or None in case of a varchar column, one does have to always typecast, say for comparing the fetched value to another string (and that's without even taking into account all the databases who think that having '' != null for string columns is a sensible choice...)

Having recently started dabbling in Python after many years of PHP, I'm surprised to find it, despite its increasing popularity, less well architected, coherent and pleasant to use.
Starting from ecosystem issues such as the too many package managers, none of which is both fully featured and widely used, or the multiple datetime libraries, down to details such the weird ways of declaring static methods vs. static class members, how None converts to "None" instead of "", mutable default arguments or how type hinting seems to be a few years behind, just to name a few.
The docs on the internet seem to be split between "coding for noobz" and "architecture astronauts", ie. precious few of them target the proficient coder coming from a different ecosystem.

Still, I'd never touch JS with a ten-foot pole... (and I did try to pick it up)

ps: agree that recent PHP is too gung-ho on cherry-picking the ease-of-use of Java and the stability of the nodejs ecosystem... :-( ...but that might just be me having become an old fart :-D

My understanding is that a large part of the reason `apt` was developed was to allow breaking the output format without impacting the scripts consuming it, whereas `apt-get` is more or less frozen in time