Rumors of PHP’s death greatly exaggerated
I just read an interesting article called “PHP Is Doomed”. I don’t necessarily agree with the author’s dire predictions, but it did remind me of the importance of continuing to adapt and learn in this crazy field we call web development. As noted in the article, Perl programmers were in high demand just a few years ago and now Perl is barely mentioned (at least in a web dev context). PHP could meet a similar fate as a result of pressure on several fronts (see the article for more about that).
So what do I plan to do about this? In the short term, nothing. I happen to really like PHP and I’m still experimenting with the new features in version 5.1. It works for my purposes and I don’t see any compelling reason to start wringing my hands and looking for another bandwagon to jump on. After all, PHP powers a number of very popular open source projects including MediaWiki (which runs Wikipedia), WordPress (which runs this blog), phpBB, osCommerce, Drupal, Joomla, etc. Need I go on? (Answer: YES)
That being said, it will be worth my while to eventually check out the competition and broaden my skill set. So what would be my choice to replace PHP? That’s easy: Python. Sure, Ruby on Rails is a compelling alternative, but I think Python is the better choice for two main reasons: flexibility and speed. Rails is rather restrictive as far as what one can do. Of course you could argue that Python and PHP give developers more than enough rope to hang themselves, but I prefer to take my chances. As far as the speed issue, Python works seamlessly with C++. Custom-build Python libraries can be rewritten in C++, compiled, and used with exactly the same API as the equivalent interpreted libraries in Python. This creates a lot of potential for performance optimization that Rails can’t even touch.
Of course, I’ll keep my eye on Rails and will probably at least dabble in it. I do like the strict MVC architecture, but that can be replicated in Python by using Django. Heck, you can do the same thing in PHP by using CakePHP. So Rails really cannot pretend to be unique in this respect… which naturally brings us back to flexibility and speed.
Well, I could go on, but I’m getting into unfamiliar territory, so I’ll stop before my foot finds my mouth… “PHP est mort. Vive le PHP!”
Sphere: Related ContentComments
4 Responses to “Rumors of PHP’s death greatly exaggerated”
Leave a Reply
Call me when it’s required that I KNOW Ruby or Python for my job.
The way I see things is this: So what if something might be better or faster. Currently we’re not seeing bottlenecks in our software where we would need to go somewhere else to optimize the software. When that becomes a problem, it will be told to us that we need to either optimize our code, or look into something else to program. I dont see that happening anytime soon though.
A key problem with this guy’s thoughts is that Perl went away in favor of PHP. That only happened because web development using perl wasnt the best way to do things. PHP is meant for the web whereas perl is not. People used perl because we didnt have PHP ‘way back when’.
Things evolve. Who’s to say that PHP WONT be able to multithread?
I doubt PHP will ever ‘die’ unless zend decides to kill it off in favor of something else.
Ramble ramble ramble. Gotta get back to work
I see a lot wrong with the “PHP is Doomed” article. The author of the article failed to accept the fact the PHP is a web scripting language built and accepted among users to handle that task. Where as I can see the need for multi-threading on desktop and server applications that are built for performance, a web application is just that… a web application.
First of all, multi-threading is used to perform one task while you are doing another concurrently in parallel, such as loading one section of your application while the user is viewing another. Or Pulling live data from a third party to update content within your application with no apparent delay to the end user. These are just a couple examples.
Ok, now lets look at the concept of a web site. A user loads up the home page of a website, then has several options (links) of what to do next. When the user clicks on a link, then another web page loads up… then the next. Bandwidth is a commodity just like anything else, and we don’t want to burn unnecessary bandwidth just because we can… so we don’t. Anyway, if we wanted to “thread” the rest of the pages, it would have to be a joint effort on the client and the server because if we just did it on the server, it would be of no use to the client. So we could virtually “thread” it with AJAX. I know, this is a major part of the debate, so bare with me.
Alright, for the pulling of live data, in order to do so with the server side scripting language, we would have to hold the page in limbo (a little loading bar at the bottom of the screen indefinitely) and continually push chunks of data to the client. As they are pushed to the client, they will be forced to the bottom of the document, so you will have to use JavaScript to force the chunks of data where they need to go. There is one problem with that though… the onload function never fires because we’re holding the page in limbo to compensate for the threading. Again, AJAX technology is clearly a better choice for updating third party data.
Now on to one of the main arguments of the document… multi-core processors/SMP servers. Yes, multi-core processors are cool, and yes it is true that PHP can’t take advantage of them by using multiple threads for various tasks while it is running… Or can they?
PHP scripts just sit there until a user tells it that it’s time to be interpreted. The Apache webserver runs under such a user that can tell the PHP scripts to be interpreted, and also tell them which core/processor to run on. Yes, the Apache web server supports SMP, so indirectly, PHP can take advantage of multi-core/SMP systems (How and why is beyond the scope of this comment).
Now to my last point. The author mentioned something about pulling database queries and then running other code in another thread to build a table or something. I see this as very trivial optimization, and I see the performance gain vs. time spent on programming it (not to mention the amount spent for the programmer) as being so minuscule that it wouldn’t be worth it.
Ok, so you would gain maybe a couple hundred extra pages per million (*assuming you programmed it correctly and your optimizations really worked), but if you really need the extra performance, then it means you are making money and could just throw a couple extra servers at it behind a load balancer using a couple databases utilizing replication. The amount speant on the extra servers… about 4 – 8 grand (depending on how beefy the servers are), and an extra 3 grand or so per year for bandwidth (assuming you need it).
Weigh that in with the hiring of a programmer who beats on his chest because he’s a master at programming in a multi-threaded JDK/Tomcat environment and requires Java Enterprise Edition to be efficient… up to 20k per year….. And, to top it off, you’re still going to need the few extra servers behind a load balancer and a couple of Oracle servers utilizing replication (12-18 grand).
So it boils down to this… 3k per year 8k investment… 20k per year 18k investment. I’ll take the 3k 8k every time.
* Multi-Threaded
1. Pull the query O(n) where n is the number of rows.
2. Build the table O(n)
3. Populate the table O(n) Assuming you have an efficient search and replace algorithm.
1 and 2 happen in parallel so we end up with
= 2 * O(n) (assuming an efficient search/replace algorithm)
* Sequential
1. Pull the query O(n) rows
2. Build the table at the same time as pulling the rows (Accounted for in the first O(n).
= 1 * O(n).
As we know from algorithms, the constant before the O can be omitted, so the run time is essentially the same, but as we can see, you save time from just building the row while you pull the data. Again, it’s a flawed point by the author (it was in a comment), even though I can see where it would be beneficial, just not in the case that he mentioned.
[...] also written about the silliness of predictions of PHP’s imminent downfall. PHP is not without its warts, but it also supports a vibrant ecosystem of frameworks (Zend [...]
Ha ha ha ha….. There are many things that drive a technology, and that is requirements, and ease of use.
If a solution can be put together quickly in PHP, then its the language of choice.