

PHP is meant to die - artyom
http://software-gunslinger.tumblr.com/post/47131406821/php-is-meant-to-die

======
toast0
Death by design doesn't work for everything (which is why I hope your database
server and your filesystem aren't written in PHP), but it's a great fit for
handling HTTP requests that are shunting data around.

You can, and probably should, use other languages to process data in batches,
and whatever maintenance needs to be done. It would be nice sometimes to be
able to finish a client request, and then continue to do more work, you can
approximate that by forking a background task (hopefully with some sort of
limit to avoid crushing your machine), or a call to a task daemon.

Knowing that the PHP process lifecycle is very short helps you prioritize
things too. Do you really want to spend time making a giant object oriented
representation of your relational database, when you're just going to throw it
away in 50 ms; wouldn't you rather spend more time with your kids?

------
abestic9
I agree, PHP employs very suicidal workers!

Chromium workers die after you've closed their respective tabs. Once the page
finishes loading the worker is no longer needed, another one can pick up the
next request. I've never come across the line 0 error, I don't task a single
PHP script with a respectably large operation, it's not designed for that -
even the default script execution timeout offers a hint.

Obviously session information and state can be stored in a cache, database or
file. If you need to trigger a maintenance script create an XHR or cron job.
1x1 transparent PNGs is a horrible way to do some back-end dirty work that the
client need not be associated with. If you're doing this to run DB
optimization, purges or bulk emailers, you're doing it wrong.

An obscure limitation? Yes, but there are bigger issues in PHP than death-by-
design.

~~~
kaens
Sure there are bigger issues, and I think this guy has correctly identified
death-by-design as a large part of the reason for those issues.

I'm not sure if PHP was _explicitly_ designed to die, or if it just came out
that way because that makes sense for the problem it was originally trying to
solve in the context it was originally trying to solve it in. It doesn't
really matter though -- the language hasn't sloughed off the nature of that
original problem and its context.

Your point about it being the wrong tool for those jobs is, in my opinion,
correct -- on the gripping hand though, the jobs it is appropriate for are
appearing less and less frequently, and the places that have PHP codebases
that suddenly need to scale out and/or run long-running jobs are going to
(more often than not) hammer it in to some weird mold that kinda resembles a
more appropriate (but not really working) tool for that job if you squint just
right.

Search bugs.php.net by notabug sometime, or by wontfix, or just browse around
randomly.

------
digitalzombie
... The reddit thread about this had more insight than hackernews.

I don't get why the author want to freaking do long daemon in PHP. Even if so,
there are people on reddit that talked about coding long process in PHP with
failure in mind (that's like something you learn from Erlang and fault
tolerant system). He/she could use a message queue if need it be.

And really? You want state in your web application? with HTTP protocol that is
stateless?

It's almost like picking on a donkey cause it ain't a bird.

And he/she doesn't even offer a concrete solution. If PHP suck so bad, by all
mean post a solution or an alternative.

And I am going to disagree with meant to die. PHP is actually evolving into a
pretty language even if it's fundamentals are flawed.

I don't think PHP is going to die, it have adopted namespace, anonymous
function, closure, and soon generator and whatever. Not only that but it
recently got an awesome package management system, composer. It's going to
stay for a long time. It's evolving and moving in a good direction with an
existing user base.

------
wldlyinaccurate
First, let me say that I do agree with this post. PHP projects are more often
than not full of inelegant solutions written by bad programmers. The "running
background tasks in the foreground" is a good example; one that I _hate_
seeing in production.

The thing that I don't agree with though, is that you've described a "capable"
programmer who uses good programming techniques and obviously knows how to
structure an application. If this programmer is doing the "background-in-
foreground" thing and hasn't heard of message queues, then I would argue that
they aren't a capable programmer - in which case you're just describing bad
programming practices; not a fundamental flaw of PHP.

~~~
orestes
Thank god I'm not alone on this one. These examples were screaming for message
queuing.

Bad programmers will write bad code. Complex systems are not coded by a single
guy in an epic run. We have software and platform architects, we make
committees and we discuss the whole thing many times, using something various
software methodologies to make sure we're working on the right direction.

------
vlucas
From my experience working with PHP for over 13 years (since PHP 3 was new), I
can say your article is mostly true, and I have definitely seen the invisible-
image-as-a-poor-mans-cron trick in production a time or two. The only nitpick
is that I have really only seen stuff like this on small sites that don't have
enough traffic for it to ever matter, so it's generally a temporary issue or a
stop-gap measure, not common practice as was implied.

That said, there's nothing stopping people from just throwing a task in Redis
from their PHP frontend and using node.js or Python, or Ruby to manage the
queue. This is what Flickr did ([http://code.flickr.net/2012/12/12/highly-
available-real-time...](http://code.flickr.net/2012/12/12/highly-available-
real-time-notifications/)), and it seems to work well for them. People just
have to keep in mind what each language excels at and know the drawbacks.
Articles like yours help, so thanks for the good read.

------
niteshade
I liked the post but you can definitely use that factor to your advantage. Its
all really subjecetive, if you have code that is structured to die and not be
continuously running then you probably wouldn't run into any problems, that
said, PHP is arse.

