Thread by @davert

I will take this out and write a thread on why I don't enjoy writing #PHP anymore.

PHP development nowadays is bumping versions, updating types, and tests. And getting out of cross-dependencies conflicts.

👇

https://twitter.com/davert/status/1577348990504521728

Let's take this situation, I have my own library MyLib that is expected to support PHP 7.4 and 8+ in the same time.

Meanwhile the coollib package I depend on releases its v2 where it changes interface of the same function to incompatible one:

Client #2 already migrated PHP 8.1 and wants to install coollib 2.0 while

Client #1 is using PHP 7.4 and can't move to coollib 2.0

As MyLib author I can either drop Client #1 and make a major release not because I introduced some breaking changes but because I bumped dep

Now imagine what happens if coollib has also dependencies... Getting out of confict is pain.

I don't understand why

doStuff(mixed $val)

and

doStuff($val)

are conflicting with each other as they are basically the same function! But they are different for PHP engine.

So here are two problems:

🎃 All PHP classes and functions are loaded globally.

🎃 New PHP types are not backwards compatible.

If either of this won't be a thing we would not get into dependency hell.

Problem #1 was solved in In #NodeJS.
If you require a module it will stay only in the current context and won't affect the whole application.

So in NodeJS context different versions of the same library with different method signatures can live together.

Problem #2 could be solved on engine level but probably it was not predicted from the start. You can never know how ecosystem reacts to new features.

Library embraced more and more type changes breaking compatibility in interfaces in every year

Banning types could be an option

So here we are!

While PHP still keeps ugly array_* str* functions from 90s, it breaks compatibility in the ecosystem with every new release.

So it's neither a modern language nor a stable one.

(sorry, #PHP,. you know I love you but I must have said this)

While you can think that everyone can do upgrades every year, it can be automated via @rectorphp and so on...

Well, you can't run Rector on all your dependencies and bump new versions without maintainer permission.

So you get stuck with PHP version of a dependency you don't own

@rectorphp That's how some big project are still on PHP 7.2..7.4 and can't get to PHP 8.1.

Upgrading has its cost.

While making a mid-sized framework-based project can be fine to upgrade, large enterprise codebases with custom core and dozen of dependencies are painfully hard to upgrade

So let's get back to me, a library author who has a library that just works.

Client #2 (mid-size) upgraded their app and wants me to upgrade my code as well

Client #1 (enterprise size) could not get an upgrade yet and wants to use MyLib

Should I drop enterprise client?

And as an author of general purpose library I will need to maintain a library with versions for all currently used PHPs. You see, that's sucks!

Otherwise:

I say: my lib is PHP 8.1 compatible!

Client says: ok, we are not going to use your lib, as we won't upgrade just to use it

I really appreciate all the work of all developers from @laravelphp and @symfony ecosystems as you make PHP modern and cool.

But I the dependency hell problem won't allow PHP projects to grow big yet keep up with all upgrades unless split into microservices.

/THREAD