I generally agree with the summary even though the points are not entirely consistent and it severely misses the big picture of "sucking".
Even though the strictly technical criticism of the cited article no longer applies to newer PHP, PHP as a language and ecosystem sucks a lot largely due to its maintainers but also the community.
PHP 5 had several problems that are at the root of that:
it didn't know which paradigm to fully approach: OOP or something else? OOP in PHP5 is half-baked to say the least. You really need to want it because the language doesn't help you remain confined to OOP. You can also see that whoever thought about OOP concepts in PHP5 didn't really understood them (as an example, the DateTimeInterface of PHP's own language constructs is an interface in name only).
it evolved slowly (Javascript had its own woes but ECMA standards evolved much faster with much greater support and it also helped spawn new technologies). PHP is just PHP.
the very lack of enforcement made it easily approachable by anyone and the was no incentive to get better once you were in. Sure, lot of people find motivation but enforcement of any good standards in PHP5 was a manual thing
most languages (JS and Python come to mind) have a clear process for common things to make their way into the language. PHP had no such thing (in addition to being slow to better itself). Even now, we do have a mechanism for improvements, participation in PSR definition but from there to additions to the language itself is a long way.
even PHP7 failed to enforce strict types and instead made it a 'wonderful' addition to its boilerplate.
community: many still adhere to compatibility with PHP 5.x. Why? Why add incentives for people to stick to unsafe, dead, obsolete versions??
You offer some advice for PHP5 users and you also mention using strict types. Do you know that strict types are a PHP7 thing, right? You're basically telling people to upgrade, which comes with a learning curve, particularly for OOP practices. It's a costly upgrade and factor in that of all PHP applications in the wild almost 60% use version 5, people's opinion of PHP will stick to version 5. No wonder people still refer to that article!!
Also .... you tell people to follow PHP-FIG. Do you mean all standards? (that would be nice) or you just mean coding standards (aka PSR-2 - which incidentally was deprecated, but people still follow it and quote it out of inertia). I'm asking because one of the most famous frameworks (Symfony) isn't compatible with the most needed standards: PSR7 and PSR15. It's mind-blowing that incredibly useful components like HttpFoundation (I love working with their requests and responses) don't provide builders for PSR7 and PSR15. Yeah, they provide a bridge as a separate package which only adds to boilerplate.
Speaking of composer, I wouldn't be so eager to jump into packages. My usual tooling for APIs involves PHPDI's container, theleague's router and stuff like Monolog and Doctrine but that's about it. A recent nightmare involved mailgun and some sms sending API that each had the same dependency locked at different versions. It's a matter of time before running into version conflicts that, in the happy occasion when there's a resolution, ends up with using the lower common acceptable version (which, given the way most libraries go for compatibility, means code from PHP5 era - a great example for the developers that end up using it). In the case of node, for example, older packages aren't that problematic since even what's considered older at the moment (think node 6) isn't as old as vanilla PHP5.
And last, my personal gripe with the PHP ecosystem is that in many cases the tendency is to copy Java. Java-fication is most obvious on frameworks like the defunct Silex or Symfony. Fortunately now there are some nice alternatives (Symlex, Ubiquity) that are embracing PHP7 for what it is, instead of trying to copy another language. Add to that application engines like Roadrunner that bring true performance and nowadays we have something workable.
But there's also the tendency to get stuck in OOP world (I get it, PHP has be so slow to evolve that I've seen developers jump at OOP as if they suddenly discovered sliced bread - most OOP 'benefits' are a myth and while it did help promote great practices like SOLID, they aren't tied to OOP and apply regardless of core paradigm). Other languages offer functional programming alternatives or strong code support for it, PHP only got Swoft framework fairly recently and it's quite in its infancy.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I generally agree with the summary even though the points are not entirely consistent and it severely misses the big picture of "sucking".
Even though the strictly technical criticism of the cited article no longer applies to newer PHP, PHP as a language and ecosystem sucks a lot largely due to its maintainers but also the community.
PHP 5 had several problems that are at the root of that:
You offer some advice for PHP5 users and you also mention using strict types. Do you know that strict types are a PHP7 thing, right? You're basically telling people to upgrade, which comes with a learning curve, particularly for OOP practices. It's a costly upgrade and factor in that of all PHP applications in the wild almost 60% use version 5, people's opinion of PHP will stick to version 5. No wonder people still refer to that article!!
Also .... you tell people to follow PHP-FIG. Do you mean all standards? (that would be nice) or you just mean coding standards (aka PSR-2 - which incidentally was deprecated, but people still follow it and quote it out of inertia). I'm asking because one of the most famous frameworks (Symfony) isn't compatible with the most needed standards: PSR7 and PSR15. It's mind-blowing that incredibly useful components like HttpFoundation (I love working with their requests and responses) don't provide builders for PSR7 and PSR15. Yeah, they provide a bridge as a separate package which only adds to boilerplate.
Speaking of composer, I wouldn't be so eager to jump into packages. My usual tooling for APIs involves PHPDI's container, theleague's router and stuff like Monolog and Doctrine but that's about it. A recent nightmare involved mailgun and some sms sending API that each had the same dependency locked at different versions. It's a matter of time before running into version conflicts that, in the happy occasion when there's a resolution, ends up with using the lower common acceptable version (which, given the way most libraries go for compatibility, means code from PHP5 era - a great example for the developers that end up using it). In the case of node, for example, older packages aren't that problematic since even what's considered older at the moment (think node 6) isn't as old as vanilla PHP5.
And last, my personal gripe with the PHP ecosystem is that in many cases the tendency is to copy Java. Java-fication is most obvious on frameworks like the defunct Silex or Symfony. Fortunately now there are some nice alternatives (Symlex, Ubiquity) that are embracing PHP7 for what it is, instead of trying to copy another language. Add to that application engines like Roadrunner that bring true performance and nowadays we have something workable.
But there's also the tendency to get stuck in OOP world (I get it, PHP has be so slow to evolve that I've seen developers jump at OOP as if they suddenly discovered sliced bread - most OOP 'benefits' are a myth and while it did help promote great practices like SOLID, they aren't tied to OOP and apply regardless of core paradigm). Other languages offer functional programming alternatives or strong code support for it, PHP only got Swoft framework fairly recently and it's quite in its infancy.