So, usually by the time I am two sentences into this sort of discussion I am labeled a zealot, and I get some panacea arguments like "use the right tool for the right job!" or "shut up!".  No, PHP is not the right tool for the job, I'm sorry, I don't care if the job is pumping gas, PHP will fuck it up good.  Don't even start in with the "but it's easy!", yes, it encourages you not to think about what you're doing as a programmer as long as your short sighted goals are reached, so that you may have horrible side effects growing in a dataset over a period of some years.  If that sounds like a bunch of tech mumbo jumbo, try this: lost customers, lawsuits, and all other sorts of "paper cuts".

Recently, I came up with a new idea for explaining why this is a problem, and why doing things The Old Way(tm) where every feature must be abused to compete with modern technology, even if it's a little bit faster to develop the first time around, can be a Very Bad Idea(tm).  As you may have surmised from the title of this post, the idea is that PHP in today's world is like Punch Cards and Paper Tape in the 60s.  Sure, a lot of people already know how to accomplish things this way, because that's how they've been doing it for the past ten or fifteen or twenty years.  In fact, the way it's done now MUST be the right way because it's the ONLY way that ANYONE does it, and by the very nature of the universe, THAT is how it's done!  Come on, do you think you are some sort of Genius breaking paradigms?  Pfft.

In walk the likes of Ken Thompson, Brian Kernighan and Dennis Ritchie with their fancy procedural programming language, C, and with Bell Labs comrades in tow wielding UNIX: files, pipes, multitasking processes, and Jimi Hendrix, Oh My!  Surely people had some very well tested and battle-worn software on punch cards, though there were many horrible problems with this approach, least of all that only one person at an entire huge institution like a university or top secret military installation could run a computation at once, and then all they had to show for it was a little piece of paper tape with the answer to their question(s).  If they bent the edge of a card or something, the whole thing would go kaput, raining a pile of cards across the room.  Also, with computers like this, you could never have something like The Internet - in fact, that idea is about as absurd as a flying vehicle which for some reason looks like an automobile.  It follows that modern software which similarly fails to embrace new paradigms will hinder the development of the next great advancement of comparable magnitude to The Internet.

So, fast forward about forty or fifty years, and we have the wildly popular GNU/Linux, which is still essentially a grassroots reproduction of the work done at Bell Labs in the 70s, with a rebellious bent on disproving the wacky theories of 97% of the world's Computer Science Faculty. ;)  Apple has dumped their proprietary Xerox clone for an entirely new system built on very similar technology to GNU/Linux, and Microsoft has taken this idea and changed all the terminology so that it's very difficult for anyone to understand both sides.  Moving along, I feel that we're knee-deep in new paradigm shifts, and that just as UNIX and C stood on the shoulders of giants, they are now part of the technological mortar that binds our world's communication infrastructure.

What now?!

Internet on the Moon?  Fiber optics directly through the center of the earth connecting NYC and Hong Kong?  Entire people made out of recycled iPods?  Sure, all of that, but that's not the paradigm shift.  What I'm getting at, for my "why do web development the oh-so-hard and reusable way, when I can go to sleep after colbert by writing PHP?" crowd, is that systems like Plone and Zope - or even .NET - which are a bit more complicated to acclimate oneself to as a developer have a payoff, just like porting those punch cards to C programs which can run concurrently with separate privileges.  The longer you hold onto those punchcards, the more creases they'll get, and the less people will understand them because, seriously, have you seen this new stuff?  It's awesome, I quit. ;)

Let's talk about what's different with what I'd describe as "modern software":

Object-Orientation

In the middle of the 20th century, procedural programming in english instead of ones and zeroes was all the rage, and still is today.  A Brazilian software engineer that I met last year told me that people who learn the Python programming language first often ask him what language to learn next, to which he responds: English.  Object-Orientation takes this conversion between human communication and computation and extends it to allow you to define your own lingo, to create some nouns and define their behaviour and interaction with each other in a very explicit way.  If this sounds kooky, I'd like to print a few hundred thousand lines of procedural code for you - it's the worst birthday cake recipe ever.  Yes, I know that you may think PHP is Object-Oriented, but it's not any more than Perl, and they are both examples of what not to do in many cases.

Design Pattern inspired

In the 90s, when I first began studying Computer Science, a group colloquially referred to as the "Gang of Four", or GOF, met up for a summit and drew upon their cumulative years of experience to define some of the most common "patterns" found in software applications.  Consider this McCall's for software.  Most of the CS and engineering graduates I've met hate this book, but I've grown to love it, and you should too.

Service Oriented

I can't remember the last time my computer was of much use to me as anything but a very heavy mp3 player without a connection to the Internet.  No matter how much storage and processing power you give me, no matter how complex you make the software running on my computer, as with all things, it's for naught without some interaction of other people.

Separated Concerns

Anyone can try to take the world onto their shoulders, but it's crucial to separate concerns and lay the groundwork for collaboration early on in a design.  The Gartner Group concluded in the past couple of years that Componentized software engineering would soon, if it does not already, outweigh programmer productivity as factors contributing to the success of software projects.

I wouldn't say that these goals can't be accomplished with tools like PHP, ASP, JSP, CFM, or even good-ol' CGI scripts, but in all of those cases you would be grafting each bullet point onto something inferior, rather than working to transcend the limitations of punch cards and paper tape, to use these new concepts as stepping stones toward the next advancement.

Unfortunately, clients often feed this by saying: "Hey! I am not an R&D lab, and I prefer to have something old and mostly broken than for you to use me as an instrument of change, you low down jive sucka."  So, if you hire people to write PHP, and you want to think about how using modern tech can positively effect your finances instead of becoming a race to accrue shiny things, look a little further into the future and put some planning into what you do, instead of insisting that people work in an hourly manner which actually discourages them from accomplishing much of anything for you! ;)