Generally I enjoy reading all kinds of “PHP sucks” and “PHP is doomed” articles, of which there’s no shortage. First, many times the authors have very interesting ideas on places where PHP does suck and can use improvement - and the more good ideas the merrier. Second, once you read a dozen of them you can’t help noticing how people say PHP sucks and is doomed for entirely contradictory reasons which makes it fun. And last but not least - if people write about flaws of PHP it means they care. Nobody writes about why PL/1 sucks and how Clipper is doomed

Recently on PHP blogs I saw a reference to one blog entry - named “PHP is Doomed!” of course - that proclaims PHP is doomed for one single reason - it doesn’t support multithreading. I personally think that claiming PHP is doomed because of that just shows that the author does not take the right perspective of what tasks PHP is meant to do and how in general Web applications work.
Having said that, however, I must also note that there are some actions which you may want to do asynchronously. While there are a bunch of possible solutions for that - from implementing async I/O in an extension to using job managers like Zend’s job queue - PHP also does have kind of “multithreading” inside.
This is something named “ticks” - I wonder how many of the PHP developers heard about it and of those how many actually used it. Could it be used for offloading long-running I/O-bound tasks or grouping them together (e.g. so we could wait for DB and HTTP in parallel and not sequentially)? Would there be any use at all for such functionality and if so - how it’s supposed to work? I.e. how would you know it’s done and how you would collect and use the results?