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

I know I would like to see an update to this groundbreaking work with more modern interpretations of what have become the canonical patterns.

Rebecca talks about how the interface type has come to replace the C++ abstract class. One area that I am interested in is how Duck typing may replace the interface construct in many of the classic patterns. I’m not sure that patterns intended for statically typed languages such as C++ and java necessarily have the same implementation in dynamically typed languages, such as smalltalk, Ruby and of course, PHP.

For the last few weeks, I’ve been doing an interesting educational exercise. I’ve been simultaneously reading Design Patterns, Refactoring, Refactoring to Patterns, and Agile Software Development. I’m finding the cross-referencing between each of these highly complementary books to be be educational. I’m hoping to add Design Patterns Smalltalk Companion and PHP|Architect’s Guide to PHP Design Patterns (Jason Sweat’s book) to get a more dynamic perspective in the mix. This is my reading project for the next few months.

That 10 years after first reading the Design Patterns book, i am still studying from it shows how much of a classic this book has become.