Artful Code

PHP is a procedural language. This is not a criticism. PHP revolutionized CGI by being half-scripting language, half templating system. It is, in fact, about the most powerful templating system around. The fact that object oriented syntax was even able to be bolted on is a testament to that.

However, PHP does not shine in object oriented programming. Frameworks like Cake suffer because of this. On the other hand, there are also excellent frameworks, like Code Igniter, which embrace this (by using PHP objects as scoping mechanisms for function libraries).

There is a tendency as a programmer to dismiss any language that is not object oriented. This is a particular trait of Pythonistas (like me), Rubyists, and those who use Java (which I put into the same category as those who use Cobol). This is unfortunate because procedural code can be much more efficient for many applications.

The beauty of PHP is that it allows the creation of a simple application without the overhead of large libraries, long planning meetings, and a fight with the DBA over MyIsam versus InnoDB.

OO advocates will point out that this is also the problem with PHP. If you wish to expand the program in the future, it takes a lot more work than if the program had been written using OO syntax from the ground up.

This is true, and PHP can be written using object oriented syntax as well. However, classes in PHP are pretty second-rate, and do not do much to help solve the problems of over-complication in large PHP applications. Joomla is a perfect example of this; if you look at its internals (or, god forbid, its documentation – yech!) it is readily apparent how unfit PHP is for extremely complex operations using classes.

When working on a large project, it is usually advisable to break your code up into smaller portions. In many languages, these are called shared libraries: smaller chunks of code that can be reused as needed throughout this and other programs.

In many languages, such as PHP, evaluating the contents of another file necessarily means that its code is run in the current namespace. This means that if you were to run the following code in PHP:

$foo = "bar";
require_once("some_file.php");
 
# Contents of some_file.php:
$foo = "baz";

Can you guess what $foo now evaluates to? $foo has been overwritten. To get around this, we can abuse a class to create a singleton-like object:

$foo = "bar";
class Something {
    public $foo = "baz";
}
$context = new Something();

We now have two contexts, main, where $foo = “bar,” and $context, where $context->foo = “baz.”

In Python, we avoid this altogether:

foo = "bar"
import some_module
 
# Contents of some_module.py
foo = "baz"

In the Python example, foo is still “bar.” However, we now have a new symbol, some_module.foo, which evaluates to “baz.”

newLisp has a similar concept, but slightly lower level, and somewhat more limited (in that all namespaces are children of the MAIN namespace, and cannot be nested, as in Python). It also gives you greater control.

(set 'foo "bar")
(context 'SOME-CONTEXT)
(set 'foo "baz")
(context 'MAIN)

In newLisp, ‘foo still evaluates to “bar”, and ‘SOME-CONTEXT:foo evaluates to “baz.” Really, of the three, only PHP comes out the poorer here.

If I were comparing the languages, I would say that Python really wins out with contexts. Having nested modules eliminates the need to misuse classes and likewise prevents symbols overwriting each other.

newLisp’s implementation is extremely useful as well, but somewhat hindered by its lack of nesting.

PHP is the one that really takes a hit here. It’s complete lack of programmer-controlled namespaces forces misuse of other parts of the language and encourages bad coding – for which I am just as guilty as anyone.

PHP does shine in one area, though: arrays. In PHP, the array is a phenominal construction. It can be used to create tables, dictionaries (associative arrays or hashes to the non-religious), lists – just about anything. There is a fairly comprehensive set of functions for dealing with arrays as well (at least, comprehensive when not comparing it to Lisp), and a superb iterator for them as well (foreach).

PHP does not need classes except as a mechanism to group functions grouped together. Its powerful arrays bely its heritage as a procedural language, and more than make up for its substandard classes. PHP arrays are much more helpful than classes if you consider PHP in the context of a templating system, rather than an OO language.