Brent (stitcher.io)

Aside from the LLM smell, the most egregious thing about this article to me is simply implying that it's going to be much of a surprise to people that PHP has improved since the "fractal of bad design" days. The most popular Hacker News post that matches "php" in HN Algolia is this post from 2019:

https://stitcher.io/blog/php-in-2019

https://news.ycombinator.com/item?id=19917655

And while sentiment is understandably mixed even then, I actually think a lot of people have already come around on PHP as being "not as bad as it once was", if not even "good".

Some of its reputation, though, hinges not on out-of-date internet commentary, but instead on the fact that in practice a lot of the PHP code that's still in production today is simply legacy code and not up to modern standards, and most of the time when someone says PHP, they really mean that PHP. I think that is actually the thing that is holding PHP back hard outside of bubbles like HN. And honestly, even though I don't hate modern PHP, I don't have many codebases that come to mind when I think about modern PHP that are exemplary. I actually was relatively impressed with the s9e TextFormatter library used by phpBB3 when I looked at it, but even that is dated by today's standards.

Still, I think that PHP has an undeservedly bad reputation relative to other languages. I've recently come back into Python lately after having not really touched a ton of Python in a while and I gotta say, other than `uv` and `ty`, I don't…

Can always have a look at this https://stitcher.io/blog/evolution-of-a-php-object

Latest code sample is at the bottom, covers a single specific use case (DTO) and it's still old as last update is november 2022.

PHP in general has managed to had great feature while cleaning up and keeping true to its mantra of "it should be simple and easy".

Modern PHP is super fun to use, and whether you like the verbosity and completeness of symfony, the "take a shortcut around the things you don't care so you can focus on your stuff" of laravel, the event based system of swoole or similar, the microframework like slim or just raw php, it's hard not to find a shoe that fit.

What's notably funny is how they managed to do that without breaking bc, and how that is perceived highly depend on who is reading. Take switch(). The original php version of it is rather terrible in what it does in term of "programming language correctness", but it worked and had its use. At the same time, a clean one that did what was needed was really wanted.

So instead of breaking every single software out there, making wordpress and company stuck on old version forever, they added a match(), which is a bit different and much cleaner. It's not really "the broken one and the good one", as their feature is different, but it's obvious that people who look for something bad will see that as terrible. In reality, you mostly don't use switch() in new code, but its behavior is fully described and documented.

Counterpoint (from the same website): https://stitcher.io/blog/evolution-of-a-php-object

PHP 8.2 has this:

``` readonly class BlogData

{

public function __construct( public string $title, public State $state, public ?DateTimeImmutable $publishedAt = null, ) {} }

```

Whereas in php 5.6, to accomplish the same you need all this:

``` class BlogData { /* @var string / private $title;

/** @var State */ private $state; /** @var \DateTimeImmutable|null */ private $publishedAt; /** * @param string $title * @param State $state * @param \DateTimeImmutable|null $publishedAt */ public function __construct( $title, $state, $publishedAt = null ) { $this->title = $title; $this->state = $state; $this->publishedAt = $publishedAt; } /** * @return string */ public function getTitle() { return $this->title; } /** * @return State */ public function getState() { return $this->state; } /** * @return \DateTimeImmutable|null */ public function getPublishedAt() { return $this->publishedAt; } } ```

I've been using PHP professionally since ~1999. I remember ripping the Perl fanboys in the early 2000's until the foundations of PHP started to crumble with what are issues that stick in peoples minds today; so I do wonder if we brought it on ourselves sometimes. But PHP moved on carefully to preserve backwards compatibility. I still have a SaaS first developed back in 2005 on the latest version of PHP that's happily ticking over with the minimal of maintenance required - the code base is horrendous but that's because a developer I had with me at the time made a massive case for "software design patterns" that he crowbarred into every nook and cranny regardless of if it was required or not.

I've done things with PHP that would give people nightmares. It's a far more capable language [1/2] than most realise and with version 8 bringing us JIT things just keep getting better. Would I use PHP if I was starting out today? Unlikely, but I know PHP inside out and can wield it to my wicked ends with ease so won't be dropping it anytime soon.

[1] https://stitcher.io/blog/php-in-2019

[2] https://stitcher.io/blog/php-in-2020

Don't forget, much of that effort has now trickled down into the PHP language itself. We've long had scalar types for function parameters and return values, but with 7.4 and 8.0 we've added union types[1], nullable types[2], and typed properties[3]. While not a part of the language yet, generics can be annotated with the linting tools PHPStan and Psalm[4], and native support for these annotations is coming to the next release of PhpStorm[5].

Using PhpStorm, I've worked with 100 kloc PHP codebases where almost every type was inspectable. And the language support and tooling are only getting better all the time.

1: https://stitcher.io/blog/new-in-php-8

2: https://www.php.net/manual/en/migration71.new-features.php

3: https://stitcher.io/blog/typed-properties-in-php-74

4: https://phpstan.org/blog/generics-in-php-using-phpdocs

5: https://blog.jetbrains.com/phpstorm/2020/07/phpstan-and-psalm-support-coming-to-phpstorm/

> There's a reason it took a decade to get projects onto python 3, but PHP can swiftly move the entire ecosystem from v5 to v7 in a year.

PHP did well with v5 to v7. It took more than a year but your point is well made.

The PHP v7 to v8 move is not as easy [1, 2, 3]. Not having Python 2 to 3 fresh in everyone's minds is one reason; not having failed PHP v6 is another. The breakages that led to the downfall of PHP6 made backwards compatibility a focus in PHP7.

Since PHP7 was released the contributors/voices who favour backwards compatibility have left or been drowned out. The emphasis on supporting legacy code has gone.

[1] https://stitcher.io/blog/new-in-php-8#breaking-changes

[2] https://24daysindecember.net/2020/12/21/a-perfect-storm/ (recommended reading)

[3] https://developer.yoast.com/blog/the-2020-wordpress-and-php-8-compatibility-report/