• 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.

GUI development in the early 90s/late 80s was a nightmare. It felt like coding through molasses. The simplest things seemed to take forever. Tools like MFC, Visual Basic and Delphi were a definite step forward. They abstracted the windows API to varying degrees and took over the event loop. But still, GUI applications seemed to take longer to develop than character applications. There was less more sizzle in the app, but less bang for the buck.

When I started to do some web development with PHP, I was reminded of what got me interested in programming in the first place. Writing a web application in 2000 felt to me like writing a character based application in 1985. And I liked that feeling. The very primitiveness of the web interface was liberating in that it allowed the focus to return to the functionality of the application.

Web development has its own drawbacks. The farther you stray from primitive, the bigger your test suite of browsers has to be.

But we now sit at the same point with web development that we were at with GUI development in the early 90s. Frameworks such as dotNet, and Java Server Faces have come along, building on collective experience. They abstract the API to the web server and take over the “HTTP event loop” and bring web development in line with GUI development model.

Unfortunately, web apps are only as rich as their client, and many times only as rich as the lowest common denominator of clients. With a Microsoft monopoly on browser market share, progress has been slow.