Around 7 they started trying to mature the language with features like compiler enforced type safety and bringing other tools previously relegated to PHPdoc into the language.
PHP 8 is a decent system and features like Generators, Attributes, Fibers and first class callables have bought it near parity with other server ecosystems like .NET.
The biggest thing PHP still lacks is first-class generics for proper, type safe repository patterns.
I've been a PHP developer for over 15 years. I fucking hated 4 and 5, tolerated 7 and actually quite enjoy 8.
The biggest issue nowadays is that, for backward compatibility, a lot of the good features like type hinting are just recommended instead of enforced, so you can get situations like in Typescript where lazy developers just have everything return mixed or any.
You get to choose your battles - some sections of the code get to have verbose documentation (I consider types a sort of documentation). On the other hand, meaningless utility function #2421354 can remain typeless.
I do this with 80% of the functions, and skipping that waste of focus on those last 20% - the meaningless crap that is allowed to remain meaningless crap - is what keeps my productivity from plummeting into the abyss.
You only have so much focus - wasting it on things that don't matter is far worse than some might think.
And properly documented functions reduce the chance of difficult to trace bugs which plummet productivity when you spent two days tracking them down because someone accidentally returned a JSON string instead of the deserialzed result.
And that makes sense... in a large, dysfunctional company.
A small team where everyone talks to each other, and everyone actually tests their shit, and an accidental JSON string gets caught the moment whoever implemented it runs their test (manual or autoamted).
Or any medium size business which has a code base more than a few hundred files.
It's a completely unnecessary burden to have your team remember the inner workings of a project when there are perfectly serviceable tools to automate that process.
Coming back to a sub component of a large project after six months to add a feature is far less daunting (and easier to delegate) if the code is unambiguous about what it expects and what it produces.
The only reason to forego such simple code documentation standards is if you're gunning for job security by way of noone else being able to understand what anything does.
As I said, not having overly verbose documentation doesn't mean having no documentation at all. If you have a module, its intent should be documented to begin with, as should any functions which aren't trivial / self-documenting.
When you're missing is that you don't need to document every sortArray function in order to have meaningful documentation.
14
u/-Nastyenka 2d ago
How it feels to use Php in 2026:
Undeniably a joke, do not slime me