CIO Magazine Trolls and Gets Spanked Hard
CIO Magazine Trolls and Gets Spanked Hard
Join the DZone community and get the full member experience.Join For Free
Building real-time chat? Enroll in a Free Course on Mobile Chat Development.
[DISCLAIMER: What you are about to read is my opinion and should not be construed in any way to be an official statement from my employeer]
The article, "You Used PHP to Write WHAT?!" is the first in a series titled similarly that purport to examine different language options. A cursory read of the two articles published to date show that they do more to steer CIOs away from the two languages reviewed so far, I am assuming that the series will culminate in an article on the language that the magazine has "blessed".
The PHP article however, is not only negatively biased, it's factually incorrect and at times, insulting to those of us who use the language. I'm going to look at a couple of the statements that the author makes and discuss them. I will do my best to not take them out of context but I urge everyone to visit the article and read it for themselves instead of just taking my word for it.
There is no single right answer to every problem and PHP is no exception.
The author, Ken Hayes, gets this right. No one that I know that makes their living using PHP has ever suggested that PHP is the right answer for every problem. I speak only for myself in saying that it is the right answer for just about every programming problem I've tackled in the past seven years. Quite possible because I've made my living for most of that time writing web applications and in my opinion, it is the right answer for just about any problem you can solve on the web.
In particular, PHP is not thread safe—which means that multiple instances of the same routine may interact with each other, resulting in a crash on the Web server.
He is correct, PHP is not "thread safe". I've built multi-million dollar web based applications using PHP and never once in seven years have I had two instances of PHP interact with each other, much less crash a web server. As a matter of fact, I can't recall one single instance in my career where a "crash" (crash being defined here as bringing an httpd daemon down and a server not being able to serve web pages, dynamic or otherwise) on a server has been related to PHP. Yes, if you try real hard you can 'fork' PHP on Linux and do some shared memory operations if you have the right libraries installed but by-in-large, that's an edge case. PHP applications are not written like that. I do invite Ken though to share his experience on the "thread safe" issue because I for one want to learn and obviously he has some knowledge on the subject.
PHP has suffered its share of security problems, and it isn't particularly well-suited to large or extremely complex site implementations.
This is interesting because now Ken is tying one truth - that in the past, the language itself has had security problems - to a wholly unrelated supposition, that PHP isn't well-suited to large or extremely complex site implementations. The supposition is not true, Yahoo uses PHP as it's "glue language" and sites like Wikipedia and Facebook use it as their primary language.
Several dynamic or "scripting" languages, including PHP, Perl, Java and others, have their roots in the C language, which makes them a natural fit for developers making the transition from traditional application programming to Web programming.
The last time I worked in Java (it's been a few years, maybe things have changed) Java was not a scripting language...I know, minor point but it's just one more inaccuracy in the list.
Migrating from one database server to another is usually quite simple since most of PHP's functions have a common naming convention. A programmer can do simple global pattern replacements to change from one database brand to another.
Now I know his target audience is C-Level and that means he has to dumb things down a bit (short words, small sentences) but really, this is just wrong. For all but the most basic select statement, SQL dialects are different enough so that changing the function name is just going to break your application, not allow you to move to a different back end. A knowledgeable author would have pointed to PDO or Database abstraction layers like the one in Zend Framework that will help mitigate the dialect differences.
When should you use PHP? * Creating an intranet site. * Prototyping an application that will be converted to Java or some other language. * Creating a Web database application. * Deploying an inexpensive or quick solution. * Using ready-made apps from Sourceforge.net or other sites.
Now this is just insulting. PHP is not designed to answer the questions that Java is. (Mainly, how do you build a large, bloated application that will ensure employment of the development team?...now I'm just being naughty...ignore that last comment please) Oh and if there are an C-Levels reading this, when the author says "converted to Java" he means throw out everything you've done and rebuild from scratch. When I was a Director of IT, that was one of the main strengths of the language, not a drawback. Yes you can prototype in it, but then you can flesh out your prototype and finish the job, all without retooling.
But that's not to say that PHP is always the best solution under every circumstance. In general you should not use PHP: * Where data security is of high importance. * In Shell or automated scripted applications. * In enterprise applications where scalability takes higher precedence than economy.
Here, in my opinion, our author gets 0 out of 3. The language itself has absolutely nothing to do with the security of your data. If it's of high importance, hire programmers who understand this and can build your application accordingly. PHP is actually a very good shell scripting language. As the author has already pointed out, it's easy to learn but most importantly, your developers can leverage their existing skills instead of having to learn something like bash. It is true that there are cases, when writing shell scripts, that you have to 'shell out' to get the job done but if done properly, it's no more of a security risk than calling scripts from within a shell script. Honestly, unless you are building on Windows, it's an excellent choice for writing shell scripts. Again with the scalability. I'm going to defer to someone I respect as an authority on that, Mr. Theo Schlossnagle. In an interview I did with him a while back, he had this to say about "scalability".
I’ll just say that languages don’t scale. The word doesn’t even apply to a language. It’s like saying, “does English scale”. If you have a lot of people speaking English then I guess it scales. It’s really a bad word for talking about languages. Saying “Java doesn’t scale” simply means that the code you wrote in Java doesn’t scale well. That’s because of the code you wrote, not Java.
The entire interview can be found at "30 Minutes with Theo Schlossnagle", that quote is about 1/2 the way into the article. I encourage you to read that section to get the entire context of the quote. (The fact that I'm quoting from an article on DevZone, again, does not imply that my views are in any way representative of my employers)
PHP is sometimes criticized for being slow, and detractors claim that it has somehow been crippled in order to prompt users into purchasing the Zend Optimizer.
It's quotes like this that totally discredit the author even though he claims to be a PHP developer. A quick look at the "Zend Optimizer" page clearly states that Zend Optimizer is free. I really don't know who he's talking to about buying Zend Optimizer.
In larger implementations, PHP can suffer performance hits and may need an external boost from a caching engine.
I'll do the author one better here, in medium to large applications you should most assuredly run a caching engine. That's true of any scripting language. However, the author seems to ignore the fact that even languages like Java (which he seems to hold in high esteem) suffer from performance issues. Luckily for those of us who use PHP, the answers are usually free. (See above point)
PHP isn't Java.
Finally a second correct fact in the article. PHP is NOT Java. I'll give the author a point for stating this (fairly obvious) fact.
For large enterprise solutions, PHP makes a great prototyping or feasibility tool, but heavily loaded sites that require thread safety, security and stability should use Java.
Opps, here the author blows what little credit he got for his true fact. He also returns the the insulting tone of "PHP is a cool toy but 'real developers' use Java". Sorry but no, PHP is faster to develop in, the solutions are just as stable if not more. The one true fact you have here is if you need a threaded application, where the threads need to interact with each other, then yes, you need to look at another language. Personally, I wouldn't use Java but that's because I spent a year in system administration and know what a royal pain it is to keep things like Tomcat running.
Now for the "spanked" part
I do hope you didn't think that my analisys of the article was in any way "spanking" CIO magazine or the author. As of this writing, 30 comments have been added to the article that do a fairly good job of it. I won't quote them all here or even rehash them, you can see them all nicely here on the Comments Page. I will however quote one...and I'll do it verbatum because after all of the authors talk of scalability, performance, and security, this commenter spanked their ass pretty hard.
Oh and btw, this very site uses drupal, a PHP CMS. I wonder if this site is secure and scalable.. hmmm.. maybe i should not use my real email address here on the comment..
Ouch! Ok, so either CIO magazine doesn't consider their content very important, they don't expect a lot of hits or they don't consider security that important...or..they realize that they can build it faster, better, cheaper, and secure if they use PHP.
DISCLAIMER: The views expressed in this article are my own...go get your own.
Originally posted on "Postcards From My Life". Used with permission.
Opinions expressed by DZone contributors are their own.