• Flexible and powerful: PHP, C, C++, and Perl.
• Structured and organized: Java, Ruby, and ASP.NET.

I don’t disagree with the cultural grouping. PHP’s cultural heritage is definitely in the Unix programming, C/Perl camp as I suggested in building a culture of objects in PHP and Why isn’t PHP the natural successor to Java?

I prefer to group languages in a different way.

Garbage Collection

To me, this is the single biggest language comparison issue. Managing memory is orthogonal to the task most programmers are trying to accomplish. Thats a fancy way of saying a waste of time. Additionally, memory management is easy to screw up. Any process that relies on humans repeatedly doing something correctly is destined for disappointment. Sure, there are tools that help avoid memory management bugs. The best of these is to take it off the programmers plate entirely with garbage collection and let the programmer concentrate on other things.

Sure, there can be resource usage and performance issues. However, for most cases computer hardware is cheaper than computer programmers.

We can divide our languages along this axis:

• Quickly runs: PHP, Java, Ruby, C#, Perl, Python, Smalltalk
• Runs quickly: C, C++, Objective C, Delphi

Interestingly, this corresponds fairly closely with native executable versus virtual machine.

Static or Dynamic Typing

The next most important axis of comparison is dynamic or static typing. In static typing type information is associated with the variable. In dynamic typing type information is associated with the value in the variable.

The benefit of dynamic typing is that you do not waste programmer time and attention with typecasting (”static types get in my way”). The benefit of static typing is that the compiler can catch certain errors (”The compiler finds my mistakes”).

• Risk tolerant: PHP, Ruby, Python, Smalltalk, Perl
• Risk averse: Java, C#

Interactive or Batch

Some might call this axis interpreted versus compiled. The issue is how long does it take to switch contexts from coding to running? Is there a lengthy build process or a deployment stage? The shorter the build process, the more productive development can be.

• Interactive: PHP, Ruby
• Batch: Java

A good example of this in the PHP world is to look at Smarty and Propel. They both generate code to execute. Smarty does it interactively, while Propel requires a build process. The build process is the primary reason I don’t use Propel.

Scope

One should not underestimate the importance of this factor. Why is Java considered so complicated? One reason is that it is designed to run on everything from servers to cell phones, from desktops to dishwashers. It’s scope is impossibly general. Of course, specialized tools such as Rails and PHP are more productive for their sweet spot applications.

• General: Java, .NET
• Specific: PHP, Rails

PHP and Ruby on Rails are two peas in a pod

Looking at these factors so far, PHP and Ruby on Rails are two peas in a pod. Lets start looking at some of the factors where Ruby and PHP begin to diverge.

Popularity

Popularity brings better tools, more available developers, better documentation, and better productivity. Programming on a discontinued or rarely used platform is more difficult.

• Popular: PHP, .NET, Java
• Rare: Python, Ruby, Smalltalk

Abstraction

Working at a higher level of abstraction allows the programmer to be more productive. The computer industry has continuously been heading up the abstraction scale without looking back. Professional programmers want to work with higher level constructs because they are more expressive. One can get more done with less code. The draw back is that higher level language features can require more programmer skill to use well.

• Simple: PHP, C, Java
• Powerful: Ruby, Smalltalk, Lisp

I’m talking about the language, not the libraries when I classify Java as simple. Dynamic versus static typing aside, I see the Java and PHP languages as similarly expressive.

I have alot of respect for Anders Hejlsberg and there is some serious innovation going on in the C# world on this front. Java can barely keep up.

The Rails folks are fond of saying that Rails couldn’t be written without the expressive features of the Ruby language. It would be interesting to get the opinions of some of the cake developers on this idea.

Library Organization

Not my favorite part of PHP.

• Function oriented: C, PHP
• Object oriented: Java, .Net, Python, Ruby

Stiffies?

I think Ruby is misclassified when placed with Java and C#. Ruby is closer to PHP than it is to either Java or C#. Rails and PHP share most of the same sources of productivity: garbage collection, dynamic typing, interactivity, and focus on web applications.

Ruby on Rails today looks poised to eat Java’s mindshare on the web tier. If not Rails, then something else.

It does seem like Java’s mindshare is on the decline, along with sun’s fortunes. There is some evidence that rails is drawing mindshare from PHP as well. (Mind share is the grown-up way of saying “what the cool kids are doing.”)

So why isn’t PHP that something else?

i think its the unit testing, “You aren’t gonna need it,” “Do the simplest thing that could possibly work” folk that are dismantling Java’s mindshare. As they gain it, Java loses it. Some of that is showing up in the java community itself in concepts like POJOs and dependency injection. Some of it shows up in an exodus from Java to dynamic languages.

So why are the agile leaders like Martin Fowler and Dave Thomas working with Ruby instead of PHP? David Heinemeier Hansson directly credits these guys with influencing his decision to stop programming rails in PHP and move to ruby. I suspect that its the dynamic, smalltalk, like features of Ruby that appeal the the agile methods leaders.

Rails could have been a PHP framework, but wasn’t. Although, I’m not sure that it would get the attention it is if it were a PHP framework. The rails, ruby combination may be greater than the sum of the parts.

I can’t speak for anyone else, but I have some ideas about why PHP might not appeal to the agile method and java is too complicated folk:

• Too many globals – globals make unit testing more difficult and prevent integrating work from different developers, let alone different organizations.
• No culture of objects – PHP has made great strides in this area, but I don’t get the impression that many of the folk that work on and with PHP really buy into object oriented programming the way that the agile methods folk do.
• Crowded namespaces – How many functions is PHP up to? Constants?
• incomplete component model – This is another integration thing. PHP has too many islands and not enough continents. (I’m talking beans here, but definitely not EJB.)
• No mature frameworks – Ruby has been around a long time, but didn’t really start gulping mindshare until Rails came along. See The Value of MVC.
• No closures – Its a dynamic thing.
• Expert level gotchas – hopping on the learning curve is easy. Reaching the top, not so much.

I’ll elaborate on each of these points in a series of upcoming posts.

I’ll close by saying that life is not a zero sum game. The success of Ruby and Rails does not diminish the success of PHP. The cool kids were doing Java and now some of them are doing Ruby. Oh, well. Its disappointing that more of them aren’t doing PHP, but PHP has many things going for it. That, however, is a different series of posts.