Hacker News new | comments | show | ask | jobs | submit login
PHP is meant to die (software-gunslinger.tumblr.com)
42 points by artyom on Apr 4, 2013 | hide | past | web | favorite | 9 comments

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?

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.

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.

The line 0 error happens when you try to throw an exception in a destructor.

... 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.

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.

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.

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...), 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.

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.

Applications are open for YC Summer 2018

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact