I had my ear pierced today. Ow! All right, I concede that on a scale of one-to-ten, the pain measured only two, two-point-five, but that moment when the burly employee in the Claire’s smock assaulted my earlobe with a nail gun, it did hurt.
Whenever I sit down to design the architecture of a new application, I sit back and ponder. For the past few years, my decision continues to be: php.
I have read many blog entries on the merits of choosing php, ruby or java, and theories on why programmers make choices in opposition to the blogger's. It's my turn to weigh in, for what it's worth.
My first consideration when I consider the question, framed by an application and not simply as an academic matter, is whether the requirements of the application (usability, scalability, functionality) lead me to a particular choice. Usually, the answer is, "no."
Faced with the fact that any of the three can be used to meet the technical requirements, I then look at some of the secondary factors to me, which are typically primary to the client: cost. There is certainly a difference in cost to having a java application if the client will be using shared hosting, for example. However, just like looking at poll numbers or the numbers that speak to how a policy affects the economy, the lower cost of the tools and hosting of php can be countered with a higher cost to maintain, and vice-versa for java.
Let's assume, for discussion's sake, that cost is not an issue. That brings us to maintainability (which is also a piece of total cost of ownership). The fact is, despite the hype, one can write well-structured php code that is every bit as maintainable as its counterparts.
Testing? Ruby has the stubs built right in. That doesn't mean you have to use them. Php doesn't have them built in, but that doesn't mean you can't build them. If you're intent on developing a quality solution, it's likely that, for example, ruby will cost less when approaching the testing of screens, functions, etc., but none of the three make it so difficult to test that good testing isn't an option.
This brings me to what is usually the deciding factor: which is easier and more fun to use? That might seem frivolous, but since we removed any technical issues right off, someone please show me where it says that developers aren't supposed to enjoy their jobs? Someone who understands programming, sitting at an empty desktop (pick your flavor), can go from 0 to working test app in about 30 minutes tops with php, and that includes installing something like wamp, to provide the apache web server, mysql and php. They can consume a php manual in a couple hours, and then start making the decisions as to what balance they want to strike with granular control of the app versus featured frameworks; i.e. whether to write everything from scratch, or to use a framework that handles many of the repetitive web functions while imposing some architectural and/or syntactical control over the developer.
No, I'm not saying that someone becomes an instant creator of quality php code immediately upon beginning to learn php, but I do argue that given a developer who already understands objects, separation of business logic and presentation, performance, logic and the other pieces that combine to form a robust application, the learning curve for php can be biked, for ruby can be jogged, and for java can be hiked, but have a stress test done before starting out.
I think many of the reasons I've heard given about why java should be used are akin to the reasons I used to hear about why people should continue to use IBM mainframes instead of Unix servers. It didn't matter that one needed, in that case, millions of dollars, a stout annual equipment and consulting budget and an army of people dedicated to each of the different layers, the argument was that mainframes scaled better, were engineered better (in terms of the various software layers), and that "no manager was ever fired for picking the mainframe." This said seriously, while one of their developers was wading through a 500 page core dump trying to figure out where someone tried to add 2 to an uninitialized variable.