[dgb23]

I wouldn't recommend PHP to anyone who isn't already invested/emerged in the language.

Wordpress for blogs or websites on a shared host with automatic updates and a few select plugins? Yes. Laravel or Symphony for applications? Ok.

But just PHP has way too many footguns and doesn't provide nearly enough affordances to make them worth it IMO. Plus it's a language that breaks backwards compatibility way too often, stops support for older versions. You need some sort of protection layer that shields you from all of this. So you might end up with something that is way more complex and slow than it needs to be.

[FinalBriefing]

Gotta disagree with you here. Modern PHP is quite great, especially when paired with Laravel or Symphony. They had to introduce breaking changes to move the language forward, but I don't recall anything huge after 7.0 or so. There's a huge ecosystem of packages to do just about anything web-related, and the documentation and community resources are way better than anything I've seen with say, Java/Spring.

Laravel is a great way for a small team to get an application up and running quickly and really shouldn't be overlooked.

[dgb23]

We’re not disagreeing though. I was contrasting using something like Laravel with just PHP. And it’s not just documentation and ecosystem. You also get a stable, nice foundation with a clear upgrade path that protects you from a wonky foundation.

[phist_mcgee]

Kinda like saying that people shouldn't use vanilla JS these days unless you're a glutton for punishment.

[jraph]

> Plus it's a language that breaks backwards compatibility way too often

Do you have examples of such compatibility breakages?

I noticed Nextcloud and WordPress both seem to lag behind the last version of PHP a bit. But on the other hand I also see such thing in the Java World where people are stuck on Java 8 or 11, when backward compatibility is one of the strength of the language.

I also have PHP scripts I wrote for PHP 5.1 and still work unchanged on PHP 8.2, 12 years later. Well, I had to fix some warnings for completely dumb things I did like putting mandatory arguments after optional arguments and I'm not sure why it was working, but the upgrades have been painless for me.

Plus, I find the latest PHP version quite pleasant, with the type annotation and other new features of the language, and the execution model where your app doesn't run all the time, its php files are just called by the web server (though php-fpm). No Tomcat or uWSI or unicorn and virtualenvs to manage.

But I guess I'm a person who is "already invested/emerged in the language" :-)

(I'm also invested in Python, Java and Node.js though)

[dgb23]

> Do you have examples of such compatibility breakages?

The wordpress integration test suite broke with PHP 8.0. They seem to be lagging behind for 8.1 and 8.2 as well. Remember new keywords were introduced and code just breaks in weird ways since these versions if you have conflicting names or depend on any library that has conflicting names.

There was a somewhat recent article that talked about changes for a string template literals cleanup for the next major version that will break a whole bunch of code as well.

In the near future you won't be able to assign new properties on instantiated objects anymore. Think anyone who is creating objects dynamically to be encoded as JSON, rendered as HTML, XML or generating them from parsing/reading any of those things. I expect a lot of breakage and patches here.

> I also have PHP scripts I wrote for PHP 5.1 and still work unchanged on PHP 8.2, 12 years later. Well, I had to fix some warnings for completely dumb things I did like putting mandatory arguments after optional arguments and I'm not sure why it was working, but the upgrades have been painless for me.

In many cases the warnings, improvements and deprecations make sense. If you have a few PHP projects and use decent tooling you can fix those things often easily and are sometimes glad for it. There might be hidden bugs that are discovered that way.

But what about many projects? What about transitive dependencies?

PHP is moving fast and makes no excuses. It's simply not a language that prioritizes stability. Often for good reason, but you have to ask yourself it the churn and instability is worth it.

> Plus, I find the latest PHP version quite pleasant, with the type annotation and other new features of the language, and the execution model where your app doesn't run all the time, its php files are just called by the web server (though php-fpm).

I agree on that last part. That's where PHP shines uniquely IMO. It's really optimized for stateless execution, which makes it very easy to reason about on a macro level.

But on a micro level it's tough. There are so many little gotchas and weird behaviors. A death by a thousand cuts.

[0x073]

> The wordpress integration test suite broke with PHP 8.0.

Wordpress was since it creation a bad coded software and as a result they have issues with keeping up with the php release cycle.

> In the near future you won't be able to assign new properties on instantiated objects anymore.

Wrong, the stdClass that json_decode uses still works and will work, if you need dynamic properties without define it in your class add the attribute for this class #[AllowDynamicProperties] .

> There was a somewhat recent article that talked about changes for a string template literals cleanup for the next major version that will break a whole bunch of code as well.

Next major version comes in several years until then you get deprecate warnings, if you can't fix problems that will occur in 2-3 years you should think about your software development skills.

> But what about many projects? What about transitive dependencies?

If you have many projects but no manpower to maintain it thats a bigger problem for the projects itself, e.g. security. And you can use phpunit combined with rector for many projects.

> PHP is moving fast and makes no excuses. It's simply not a language that prioritizes stability.

PHP is stable if you write good code and on the same level as nodejs or python.

> There are so many little gotchas and weird behaviors. Thats the reason for the upcoming breaking things, if php would stick at php 5 it would be dead.

[dgb23]

> Next major version comes in several years until then you get deprecate warnings, (...)

AKA churn. Breakage is not OK.

PHP breaking every couple of years and showering you with deprecation warnings doesn't fix that.

It's like saying: "In a month I will punch your face, you better make sure to wear a helmet!". Just because you said that doesn't make punching people's faces OK.

There are languages and tools that don't break within that time frame and there are languages and tools that _never_ break.

There are also better ways of breaking changes: If you do break then give me a canonical, reliable, automatic upgrade path that also rewrites vendored dependencies.

> (...) if you can't fix problems that will occur in 2-3 years you should think about your software development skills.

It's not that we can't fix them. It's that we have better things to do but _must_ fix them.

Many of those changes are not critical or security related. They are just changes for the sake of change without consideration for stability. Everyone hop into the hype and churn train!

The baseline expectation is that my fundamental tools are backwards compatible and stable. People also have dependencies, transitive dependencies and so on. Dependency management is already hard enough without breakage.

Without stability there must be some _major_ advantage that we cannot get anywhere else. Stability ensures that fundamental libraries and tools can be _done_ outside of voluntary optimization and extension. It means you don't have fix code in multiple places and multiple projects without a compelling reason.

That's what I was getting at.

---

Note: There are good things about PHP and parts of it's ecosystem that I'm not talking about in this comment. This is a rant based on unnecessarily inflicted pain.

[6510]

I never got the endless maintaining in software. We build so much physical stuff but I remember only cars getting recalled sometimes. If you write something for a zx spectrum it will just work a million years from now. It seems there is no good excuse for it.

[kristopolous]

Comparatively speaking PHP has likely the most backwards compatibility with respect to actual wall time when compared with other common options.

It has many tools for the competent and the incompetent.

I'm sure your personal experience sucked, just like many people's personal experience with Java.

But let's not conflate the output of some set of practitioners with the design of the language. The fact that php can be so accommodating to the incompetent can be seen as a virtue. Dumpster fire makers can set things ablaze with any tool and the avalanches of trash PHP code are endless. It is what it is.

[unity1001]

> Plus it's a language that breaks backwards compatibility way too often

I havent ever had any PHP code I wrote get broken by a PHP update in over 20 years.

PHP is still the simplest way to get any API going.

[kichimi]

I'm sorry but this is a really ill informed comment, and nothing said here is actually true. You're going to need to spend some substantial time to back up what you've said.

[dgb23]

I did in another comment. This is not unsubstantiated hate, but using PHP in anger in many projects and being responsible for maintenance, automation, testing, modernizing, refactoring, solving performance issues and so on.