It’s Really help me , Boost me up 
I am a PHP developer. Maybe even a halfway decent one. As such, I often find myself engaged in conversations on the subject of web application development in general and PHP in particular. I am continually flustered by the myths, half-truths and outright falsehoods that technical and non-technical people alike hold about this humble programming language.
I’m far from a zealot about anything software related. I think if you’re excited about software, you’re missing the point. It’s like a carpenter being really excited about hammers instead of building houses. Having said that, I feel I really need to dispel a few of these things before they fester any longer. That and I’m getting tired of being talked down to by Java developers who feel their chosen language is The One True WayTM. So here’s my list.
So here’s Jaybill McCarthy’s Blog: 10 PHP Myth
Myth #1: PHP is not a truly Object-Oriented Language
I hear this one a lot from Java programmers. It’s completely false. PHP has excellent OO language facilities. There’s inheritance, abstract objects, interfaces, properties and methods. Okay, there’s no method overrides, but there are ways around this. Late binding is still a bit immature. I will say that there have been vast improvements in PHP’s OO mechanics with PHP 5, but I’ve written lots of PHP 4 apps that were totally OO. The mere fact that you can write purely procedural PHP code doesn’t mean that PHP isn’t OO capable. Furthermore, the fact that PHP allows you to mix OO and procedural code makes things like bootstrap scripts really simple.
Myth #2: PHP Encourages Sloppy Code
Also false. Is there a lot of sloppy PHP code around? Absolutely. PHP’s low entry barrier means that a lot of people who aren’t formally trained developers get in over their heads. The sloppy code that results is a result of poor training and bad management, not the language itself. Saying PHP encourages sloppy code is like saying hammers encourage bloody thumbs. Sure, you can bang your thumb with hammer, but is that the hammer’s fault or yours for not knowing how to use it correctly?
Myth #3: PHP doesn’t follow MVC
I know this sounds ridiculous, but I can’t tell you how many Rail-tards I’ve had this discussion with. No, PHP does not, in and of itself, provide an MVC framework. Neither does Ruby, or any language for that matter. That’s because Ruby and PHP are languages, not a application frameworks. MVC is a design pattern, not a language facility. There are many great MVC frameworks written for PHP. I like the Zend Framework. Can you make database calls from a script that also renders HTML? Sure you can. Does that mean you should? No.
Myth #4: PHP is slow because it’s interpreted
This one is insidious because it sounds so plausible. In fact, it should be true. In practice, it’s not. The Zend Engine that powers most PHP implementations is ridiculously fast right out of the box. Combine it with an accelerator, (like the free eAccelerator) which pre-complies and caches the code (and re-complies it if it changes on the disk), and it’s one of the best performing application platforms around, even compared to things that are traditionally compiled, like Java and .NET. Short of writing your app in C or C++, compiling it native and hooking directly into the web server or something, you’re not really going to get much faster.
Myth #5: PHP doesn’t have a good IDE or Debugger
This is true. I doesn’t have one. It has several. There are at least two debuggers and many good IDEs. You can get all the goodies you’d expect, like breakpoints, variable watching, mouse-over evaluation, etc. Can you use a text editor and an FTP client? Sure you can. You certainly don’t have to, though.
Myth #6: PHP apps all look the same
I have to say, it took me a long time to figure out what people who made this assertion were getting at. At first I shrugged it off as if the person saying it was crazy. After all, PHP is just a language, you can make the output look like…whatever you want! Surprisingly, I’ve heard this a lot. Eventually I determined that the confusion stems from non-technical people confusing PHP with PHP-Nuke, which is just an application written in PHP. It’s fairly customizable, but deals in columns and boxes that all look kind of the same.
Myth #7: PHP isn’t really for “serious” developers.
This is another one I hear from Java developers (and perhaps more amusingly, .NET developers). Similar to #2, I think this stems from PHP’s low entry barrier. Pretty much anyone can learn the rudiments of hacking a PHP script together in an afternoon. Does this mean it has no place in “serious” development by “serious” developers? Well, PHP, like any development platform, is a tool. How well a tool is used varies greatly based on the skill and training of the person using it. I have written many large scale, robust, high performance applications in PHP and so have lots of other people.
Myth #8: PHP is only good for web applications
That was true once, but these days it’s pretty much general purpose. It has a command line interpreter that can be run completely independent of the web server (for scripts) but can still use your existing PHP code libraries. You can even knock together GUI applications using PHP-GTK. Admittedly, PHP’s lineage and primary purpose is web applications, but that’s far from all you can do with it.
Myth #9: PHP code is a mess of “include” and “require” statements that break easily.
Being a scripting language, PHP is interpreted at run-time. That means any code that gets executed has to get pulled off the disk and the script in question needs to know where that is. The easiest (but by far the worst) way to do this is to place an “include” or “require” statement that loads your external script. If you do this and you move or rename a file, your script breaks unless you change the offending statement. A mess of includes and requires can make your code into spaghetti.
Fortunately, by following sound OO processes, good naming conventions and using __autoload, in-line includes and requires are generally completely unnecessary. __autoload is a callback function that accepts a class name as an argument. If you instantiate a class that the engine doesn’t know about, it calls your __autoload with the name of the class as a string. Assuming you have a reasonable naming convention, (one class per file, class name and filename match) it’s pretty trivial to load the required class when you need it. This has the side benefit of only loading classes that are actually needed for a particular script, as opposed to loading all of them before your script even runs.
Myth #10: PHP Code is rife with in-line SQL statements
Take a look at a lot of PHP applications and you’ll see it. SQL being scraped together with concatenated strings and passed to database (often mysql) specific statements. This makes your code brittle, annoying to debug and maintain and subject to SQL-injection attacks. It’s also completely unnecessary and easily avoided. Simply use a database abstraction layer like Zend_DB or ADOdb instead of directly talking to the database.
So there you have it. Ten common PHP myths utterly…well…busted. This isn’t to say that PHP isn’t without its faults, but I think few other tools get the unwarranted bad rap that PHP gets. Here’s hoping I cleared things up a little!
