PHP vs. X programming language
Being a new Zender I’ve spent some time in the recent past looking at people’s opinions about PHP now that it directly affects the work I do. In my research I have found a lot of interesting “opinions” about PHP vs. this that and the other thing, usually in the form of lists. “4 reasons why Java will outlast PHP”, for example.
So, I figured I’d come up with a list of responses to the naysayers concerning PHP.
1) PHP lacks several important features
PHP is specifically web-centric. This means that many of the features that programmers from general purpose programming languages complain about PHP not having are simply not that important in a web based environment. Asynchronous execution using threads, for example, has very little use when a browser makes one request at a time.
2) PHP doesn’t have “real” object oriented programming support.
Knocking PHP because of a lack of OOP support is so “2003”. While the initial implementation of OOP in PHP 4 was not so great, PHP 5 implemented OOP in a manner that brings it very much in line with the other OOP programming languages out there. But the difference is that with PHP you don’t HAVE to use objects. The true definition of flexibility is when you are free to build as the situation warrants.
3) There are no tools for easing debugging/development problems.
Simply not true. For example, Zend developed Zend Studio which has all of the features of a modern IDE; profiling, debugging, etc. There are also several open source applications that aide in this arena. With the Eclipse PHP plugin coming along, this argument loses even more steam.
4) PHP is slow
Can be true, doesn’t have to be. If you take PHP out of the box, throw it on a web server and leave it there you will see lower performance. But if you build an application that understands caching, loads only what it needs and uses a code cache such as Zend Platform or APC you can get extremely fast performance. For example, using a caching mechanism in Zend Platform I recently demonstrated reducing execution time on a certain program from 600ms to 7ms.
5) There are no serious applications written in PHP.
While this is not true (many companies are using PHP in mission critical enterprise applications and there are several large scale applications available for use) the problem is that this statement diverts attention away from what the real question ought to be. The real question is “What is keeping serious applications from being developed in PHP?” The former statement is often used in a context of ridicule, guile or wholesale discrimination and seldom backed by fact.
There are very few reasons that should keep an enterprise level application from being developed in PHP from a functional perspective. In terms of back office integration today’s dependence on XML makes that concern irrelevant. If your concern is that your enterprise runs on Java then Zend’s Java Bridge built into Zend Platform gives you the option of using PHP to build your web based front end to your Java-based enterprise. Even in Microsoft environments PHP has COM and .NET integration points with Microsoft compatible platforms.
When I look at the php.net’s function reference I see 182 individual modules that are supported natively by PHP. There is support for several databases (not just MySQL), LDAP, IMAP, PDF, XML, shared memory, SSL, bindings to several multi-media engines, SOAP, COM, .NET, multiple compression/encryption schemes, JSON, non-blocking IO for both streams and sockets, XSLT, NIS, Shockwave and on and on and on. These are not the hallmarks of an insignificant programming language.
And this is only the beginning. PHP, with the help of Zend, has been given enterprise credibility via partnerships with IBM, Oracle and Microsoft. These are not industry lightweights. And they are companies who recognize that PHP is more than a simple hackers’ language. They see that PHP has the potential for great things in the enterprise space.
I would argue that once most of these points have been fully considered there are few significant barriers to building serious applications in PHP.
If, after reading this, still think that PHP has no place in the enterprise, please email me at kevin@zend.com. Your thoughts and responses are both anticipated and welcome.
Comments
To Henke, there's actually a few options available if PHP does not have the functionality you're looking for. One is writing a C-based PHP module, the other is to use the Java Bridge available from either Zend's Platform application or the Java Bridge available at Sourceforge.
JMPCollins, Thanks! PHP is a maturing language but that's not to say that it doesn't fit the needs of most situations for which it's intended. As more and more creative people contribute I think it's pretty safe to say that the "arguments" against PHP will lose more and more of their steam. Some arguments are valid but most seem to be based on personal preference.
Unfortunately, it makes a lot of sense and is exactly what I am looking for in the "serious application" we are currently working on. Sure, the user makes one request at a time, but his request may trigger a lot of background processing that now either the user will have to wait for (silly and user-unfriendly) or will have to be set aside to be triggered later (silly too).
I'd like to handle all the consequences of an event (like a user ordering a complex transaction), asap. Unfortunately, there is no way to hand these tasks to a specific background thread or threads, so I can either spawn fresh threads (by starting a CLI PHP thread from my script and letting it loose) or set these aside an handle them batchwise (in a seperate script triggered as a cron job). The first method gives me an uncontrollable number of PHP threads, the latter doesn't qualify as "event driven" in my book.
So, while I'll no doubt manage to work around it, this is IMHO indeed a missing feature.
If you need to have backgrounded execution you could simply have a PHP CLI program running in the background polling a database every X seconds to see if there's something new to do. That way your user could keep on browsing while you did your background tasks. There are other methods you could use as well, but there's only so much I can say in a comment response box :-).
Furq, this was not a "my programming language is better than your programming language" article. I don't like those articles either. This article was a response to the people making those claims against PHP. OOP was brought up because others have bashed PHP for not having OO semantics, which is a completely false statement. I don't like completely false statements. :-)
In my opinion, OOP in PHP4 wasn't more then dealing with associative arrays, which is far away from being what we have today in PHP5. So it's at least comprehensible that some peope are the opinion discribed above, isn't it?
In fact, I hope I understand something wrong of what you said, since it doesn't make much sense.
That was one of the things that prompted me to write the article. I ran into SEVERAL articles written in 2005-2006 using the PHP 4 OOP model as their basis for comparison. I didn't keep track of any links since I didn't want to start a flame war with anyone, but I did see several in just a few Google searches. While the articles that I saw did not make the specific claim that they were referring to PHP 4, the semantics they noted were clearly not PHP
PHP does not NEED multi-threading capabilities. As said, it is not needed, with the exception of the rare case. Sure it might be nice to have for those occasions, but is it really worth having around the rest of the time? No. It will just take CPU cycles and memory away from you applications.
it's true, but it implements the basic functionalities for every module, if I want to use xml schema I cannot make it, like if I want to manage complex pdf file, quite with some database I do not have all the functionalities. Moreover the php library available online are little professional (i.e. PEAR: much bug and little documentation).
Moreover you have not mentioned the insufficient portability of the php, even if from the version 5 is much improved.
there are some functions in php that they work alone in safe_mode, or that they are connected to something in php.ini.
For this and other I use java for enterprise and php for personal project or little site.
It seems to be one characteristic of the typical PHP developer to not stick to standards and invent their own structures and libraries all over again. And they releas pre-mature code as free "libraries". Might be because it's so easy in PHP. Might be because of a "do-it-yourself-culture" in the PHP market.
Yes: PHP is OOP now, there are tools, it is stable and scalable, it can integrate. But where are the standards? Where are the well trained developers who can code PHP in an appropriate way? How do you distinguish them from the average webdesigner who thinks in dimensions of screens and buttons rather than about application structure? (sorry guys, dont mean to offend anyone)
Zend has a lot of answers to this: Certification, Zend Framework, Best Practices. But it is still a long way to go...
C'mon people, stop trying to force PHP into the enterprise. It simply does not belong there. It's OK for high school kids, hobbists and small websites and that's where it's usefulness stops.
Here is a article that summarizes some points about the use of PHP in large websites.
http://www.ukuug.org/events/linux2002/papers/html/php/index.html
PHP is waaaaaay behind on some important issues, SOAP being one of them. They still use RPC encoding and that's not even supported any more by virtually any new SOAP stack. I could go on and on and on but I think the point is clear.
but why the best CMS on the web are written with php? Wordpress, mambo, joomla, the best blogger platform are written with PHP.
PHP is a fantastic language, it permit to use more fantasy in coding, not always standard is so cool, standard?
I saw many project crash when porting from one version of java to another, a disaster.
I think programming is resolve a problem and the problem never have to become the programming.
Team working? Svn is useful for all language.
Cronjob are more efficient and more stable then java thread, you can build a scheduler and dont'be afraid of tomcat crash where all activity die, this is event driven, YES.
I have programmed many years in C, someone tell me that it was a bad language because of pointer etc etc... but it solved any problem, like php in web development.
I think solve the problem is important, find a solution is important, and not the language. 90% of language limit are between the keyboard and the chairs.
How can you separate in java the logic from layout? XML+XSLT????? This is a joke true? Utopia!!!
Look Smarty!
Best regards
To answer your question: Why are several popular CMS applications written in PHP? I don't know exactly, you would have to ask the developers of each to get an accurate answer. However, I would suspect that it's easy to implement on a wide variety of platforms as being one of the primary reasons. I have used many of those very CMS systems you claim and EVERY one of them I have used is SLOW. I have personally seen some die under very light loads as well. (With no error message either!)
I'm sorry you saw "many project" crash when moving from one version of Java to another. It's unfortunate the people working with those projects are not a familiar with Java as they should be. Poor planning does not warrant the claim a language is "bad".
How do I separate presentation from business logic? Easy! I use the model-view-controller design pattern or in Java I use JSF (which is build on that very solid foundation), or I use Microsoft Web Forms.
Personally, I don't use or subscribe to the idea of "fantasy" in programming projects. I leave that to when I visit clubjenna.com. Or by that can I assume you mean "creativity"? If so, creativity = hard to read code.
Now let's move on to the meat of WHY PHP is a bad language . . . Ready?
1. Namespaces don't exist at all. I know, I know it's coming in version 6. Weeeeeee! Everyone gets to rewrite / organize their PHP code. Shouldn't this be done before hand?
2. Exceptions didn't exist until PHP5. Even now they a superficial afterthought at best. Who's going to go back a rewrite to new PHP exception handling style? Please stand up. Didn't think so.
3. No consistent naming convention is used in the language. Underscore here, not there . . .
4. Code duplication. I give you: sort(), arsort(), asort(), ksort(), natsort(), natcasesort(), rsort(), usort(), array_multisort(), and uksort(). Stop already... Code duplication is a sure sign of bad design.
5. Many errors are silent. I suppose if you don't see it it's not a problem.
6. Weakly typed language. Leads to more bugs and bad code.
7. Server-side / Server-wide settings. EVERYONE plays with the same harmonica. Not good.
8. The performance is crippled for commercial reasons.
9. Variable scoping is strange, inconsistent.
10. The mixture of PHP code with HTML markup tends to make code difficult to read. Readability is important.
PHP is OK for high-school kids and hobbyists and lone developers. The fact is it grew out of a set of PERL scripts, was never designed and is bloated in ways that make it hard to use in large projects. Note: a large API does not mean "bloat" either.
I would not call these CMS applications "enterprise" grade software applications in the grand scheme of things. Show me a PHP application processing thousands / Hundreds of thousands of transactions every day. I got a C-note that says it's NOT PHP.
Finally, AGAIN, PHP is OK for small to medium websites. As far as a language, it has far more than its share of warts. It's not a choice for large, scalable projects and this developer wishes PHP advocates would stop trying to make a 1972 Pinto run a Formula-1 race. It ain't gonna work. PERIOD! Let if live where it belongs.
Peace.
1. Namespaces don't exist at all
Valid, though there are quite usable workarounds. Zend Framework is a good example of that.
2. Exceptions didn't exist until PHP5. Even now they a superficial afterthought at best.
And PHP 5 has been out for 3 years. I'm not entirely sure how they are a superficial afterthought since they work the same way Exceptions do in other languages. Coming from a Java background myself I noticed no significant difference between Java and PHP's exception handling.
3. No consistent naming convention is used in the language. Underscore here, not there . . .
I can understand the argument here but I can't say that having nor not having underscores in certain function names has honestly impeded me. But at the same time there are naming conventions that have been used. f*, file_*, etc. pertain to particular types of file operations, for example.
4. Code duplication. I give you: sort(), arsort(), asort(), ksort(), natsort(), natcasesort(), rsort(), usort(), array_multisort(), and uksort().
None of those functions do the same thing so there is no code duplication happening. You can go to http://www.php.net/manual/en/ref.array.php to see what each of those functions do individually.
5. Many errors are silent.
Depending on what your error reporting level is. Use E_ALL if you want to see all errors.
6. Weakly typed language. Leads to more bugs and bad code.
Not if you use the === (or similar) comparison operator in all pertinent situations except when you need to do type-juggled comparisons.
7. Server-side / Server-wide settings.
You can change individual php.ini settings in your httpd.conf file or in an .htaccess file.
8. The performance is crippled for commercial reasons.
Huh?
9. Variable scoping is strange, inconsistent.
Examples? I think I've heard of some examples where if you do really weird stuff it may not scope the way you expect but I have never run into scoping issues while writing practical code instead of "how can I best mess things up" code.
10. The mixture of PHP code with HTML markup tends to make code difficult to read. Readability is important.
Then don't mix it with HTML code. Use the MVC components in Zend Framework. That's one example of a framework that separates business and presentation logic.
"Show me a PHP application processing thousands / Hundreds of thousands of transactions every day. I got a C-note that says it's NOT PHP."
Yahoo, Lufthansa (http://www.zend.com/news/zendpr.php?id=60), Facebook, Flickr (http://www.niallkennedy.com/blog/uploads/flickr_php.pdf). I'll take that C-note now. :-) I think you may be surprised at how robust PHP can be in most web-based environments.
If there are more issues you have with the language I would love to hear them. Some are valid, such as the namespace example, but most of the objections I've run into in the past are either personal objections, comparisons made with PHP 4 or another one of those "my language is better than your language" holy wars. But if there are valid points of consideration I'd love to see them posted so they can be addressed.