Of PHP, Java, hammers and nails
First of all, this is neither a PHP-bashing topic nor a Java evangelizing one. Or vice-versa :) Even if there seem to be more people that say PHP sucks than people that say Java stinks. But after all, stubborn preference for a programming language is a matter of opinion or maybe a side-effect of Murphy’s law - When all you have is a hammer everything starts to look like a nail.
Secondly, I use Java as an exemplification because I can speak from experience. But I strongly suspect that the same arguments could apply to platforms like .NET or Ruby on Rails.
That being said, let’s take a look at ye olde HelloWorld program with a twist. Let’s use an array for storing the user’s name and age:
<?php $user[]=$argv[1]; $user[]=$argv[2]; echo “hello “.$user[0].”, you are ” .$user[1].” years old”; ?>
Now to translate this into Java. The command-line arguments spare us the trouble of writing a servlet. First attempt:
public class HelloWorld {
public static final void main(String[] args){
String[] user=new String[2];
user[0]=args[0];
user[1]=args[1];
System.out.println(”hello “+user[0]+
“, you are “+user[1]+” years old”);
}
}
But there’s already a problem. The age should be a number, not a string. So do we do this?
Object[] user=new Object[2]; user[0]=args[0]; user[1]=Integer.parseInt(args[1]);
Rather ugly.
What if the PHP program extends the array by adding more names and ages, e.g. in an user-controlled loop? We’d have to use a List in Java. What if we have keys in PHP, like this:
$user['name']=$argv[1]; $user['age']=$argv[2];
We’d have to use a Map!
At this point, the versatility of PHP arrays smacks us in the face, together with the realization that Java is object-oriented so we’d better create an User class:
class User{
String name;
int age;
}
...
User user=new User();
user.name=args[0];
user.age=Integer.parseInt(args[1]);
System.out.println(”hello “+user.name+”,
you are “+user.age+” years old”);
and then have a List<User> or Map<User> if necessary.
But all we wanted is a simple HelloWorld program and this starts to look complicated. The types of the variables, the size of the array, we have to bother with all these things. And if, God forbid, the name and age were taken from an HTTP request and we had to write a Java servlet, then all those objects and methods (request, response, writer, doGet, doPost) would come into play. All this to accomplish the same thing as 4-5 lines of PHP code??
This is the main reason why PHP has gained such a huge popularity. It’s SIMPLE. It does so much behind the scenes, that the developer has very few worries. No types for variables and no explicit request/response operations ? just regular arrays, like this:
$user[]=$_REQUEST['name']
Cool! Add to this a lot of convenient runtime functions/classes, and you can write a whole Web site in a few days!
But then maybe the site grows, the arrays collect so many things you can’t remember which is which, and you start having ugly runtime errors ? appearing only when somebody strays off the regular usage scenario, so they were not detected beforehand. Your newer code accidentally reuses (rewrites) some global variables and again, you might only see this when the site is up and running.
Maybe those strings, integers, classes and collections of classes would help you be more organized. Maybe those free Java/Java EE IDEs, with their hoards of features and plug-ins, would also help you be more organized. Maybe having compile-time errors would prevent some of the boo-boo-s.
Of course, PHP4 came with its own object-oriented model and PHP5 enhanced it. This model is very similar to the Java one (well, to the SmallTalk one if you want to be historically accurate). Even so, many PHP developers prefer the versatile arrays because they are much easier to use. In my opinion arrays are one of PHPs greatest strengths and weaknesses at the same time. Together with the inherent characteristics of a weakly-typed/interpreted/mostly procedural language, arrays contribute to the speed of development - and facilitate poorly structured applications.
Because there comes a time when maintainability and reliability must be taken into account, at the expense of coding speed. After all, the time gained when developing will be lost later on ? debugging and fixing problems. And the cost will be way higher.
For small to medium applications, PHP may be a very good choice. No point in bringing in the heavy artillery. Go past a certain code size though (or past a certain size of the development team) and you might need some shiny howitzers. Or just a bigger hammer for those pesky nails :-)