Good thing in PHP nobody talks about

Anthony Sidashin -

Do you know what I like about PHP?

It is designed to die after execution.

You should not fear code duplication, or bad formatting of code, of bad variables naming - mentioned artefacts of code smell are bad, but are nowhere close to statefulness in terms of contaminating your code.

One of the biggest restrictions of PHP, hated by a lot of people, and at the same time the single and the only huge factor which make poor PHP code written by junior developers manageable is this. State in most cases is completely separated from PHP process and is stored in (server-side) database and even in shittiest code samples the database is something you can rely on as on the source of truth, so reproducing the bugs is (often) easy, and gradual code rewriting (old code and new code using the same database - state) is possible. And the deployment is so easy - you just upload your script! And the development, oh, you just edit this line, save the file... and it works! Think about it.

  • Stateless (this is trendy now, right?)
  • Easy deployment
  • Easy development
  • Easy debugging

All of this happiness is just there out of the box, because it dies every time.

Talking about this language design choice - I am even not sure this was intentional (UPD: okay, Rasmus Lerdorf confirmed it was intentional on HN discussion of this article), this might be a side effect. But this restriction, I think, is one of the reasons why PHP, historically full of bad code and strange architectural decisions, gained its popularity, and is still alive as a technology.

This simple concept of strict state separation was alien in JS world because it was not there by design, this is why most frontend frameworks of the first wave (like Angular 1) (and complex jQuery code, of course) were such a pain in the ass before Redux and other solutions were invented, which separated state from interface and finally made it manageable. In JS, you can separate state. In PHP, you have to.

Every time I see Node.js code of sample websocket chat which is a long-living process I can't help myself and shudder because of this global "subscribers" variable which holds all the open websocket connections - I just see how this async long-living complexity explodes in hands of young and fast-typing developer.

This is why Ajax, when it was introduced, while giving so much good stuff to end users, made the life of PHP developers so complex - state suddenly appeared on the frontend and we could not even imagine where this will lead us - jQuery, then Backbone, then Angular, then React, and here we go - now we have the frontend developer profession - separate people dealing with state and stateful interfaces there on the front.

This is why you should be careful when working with queues and daemons (and you will still need them in any mid-sized PHP project). They do not forgive, they are hard to debug and the memory leaks and OS kills them once in a while when your bad code is launched in production. Regular PHP script forgives you, please remember this and appreciate it the next time when you wish your old PHP framework to be better in async code and long-living threads support, or when you praise Docker for being stateless - PHP is stateless, too :)

UPD:
HackerNews discussion: https://news.ycombinator.com/item?id=17853755