Link Details

wasn't this along the same lines as the argument given in the C++ vs Java wars of the middle 90's?

I mean for Tierney's sake Cobol is still, STILL being used, and in volumes much greater than many developers want to give it credit for.

And to rip a note from the article, Perl isn't dead, if it was I wouldn't still be doing weekly CPAN hunts for modules, it just found it's niche.

And PHP isn't going to die because it doesn't allow the developer to multithread, I mean multithreading has it's uses, but given the target audience of PHP I can't picture a multithreaded bulletin board being much of an improvement over a single threaded one, or how about we multithread my niece's guestbook.

Perl didn't lose the limelight because it was lacking some rarely and often poorly used feature, but because some other language could do what Perl was doing, faster and easier with a smaller learning curve.

PHP will end up in the same ballpark, it won't be used on some massive enterprise level applications because j2ee does that already, it won't win out on the windows easy ajax integrated environment because .net does that already, so where is PHP going to sit?
Pretty much where it's sat for the past 10 years, as a replacement for CGI applications, which are too small to bother investing the energy in j2ee, and too simple flow wise (or too linux server based, they DO still outnumber windows servers) to bother investing in .net.


Now, I really wish we could anti-vote a story sometimes, these X vs Y arguments tend to run long and never come to a resolution.

I mean look at the Kirk vs Picard debate among the ubertrekkies, almost 20 years long and STILL going strong.

goodness, no way. there are some businesses that function pretty strictly on php. it's not going away anytime soon.

After reading the article. It becomes obvious who 'lined his pockets'.

From the article one could easy derive that ALL you need to be a successful
would be
a.) Allow multi-threading
b.) Better documentation ( I love PHP for the documentation), but I think the difference between me and the author is
i.) I can read and usually Cut+Paste but he prefers books
ii.) I use the search functions but he prefers content and index from expensive books
c.) Justin James also does not understand the difference between scale-up and scale-out of servers or how cheap, effective and easy to use databases have become and has to resort to some non-sensical number crunching about CPU threading
d.) He also thinks RHEL support for PHP is important, now that is laughing matter and I have to stop writing before I make him cry.

I just look forward to creaming his expensive .NET and JavaServer applications with fast, cost effecting, server friendly and omni-present LAMP architecture.

We need an * Anti-vote * at dZone so we can reduce * FUD * and have authors that backup their work with some real evidence and not have paid-for opinions masqurating as researched work.

I have nothing to say about the article -- didn't even read it -- but DZone should have an 'anti-vote' as others have suggested. There are many other articles that I read on here that I strongly believe were a complete waste of time, and a way to save others the same misfortune would be good.

PHP6 /7
can probably extend the following to allow better multi-threading
You can already do this...

Declare : http://www.php.net/declare
Fork : http://www.php.net/manual/en/function.pcntl-fork.php

WTF @ article.

What a *complete* moron you would have to be to enable multithreading in web applications! Multithreading opens the door to an exponentially growing amount of possible bugs that can sneak into your code, particularly the case of race-conditions, and asynchronous execution of IO operations just isn't worth it in a web application. You're actually just gaining a tiny improvement in performance (web content usually relies heavily on IO, so the server will not have anything to do but wait for IO anyway), while inducing the risk of introducing huge numbers of bugs, all the while complicating your code unnecessarily.

Multi-threading in web applications is BAD!

- Simon