PHP was designed with the reverse in mind. In its first release, it could have been considered to be a DSL for web-based applications. It was written to specifically address the needs to writing web applications, and is now building toward a more general purpose language. In all likelihood, this is the wrong way around. It certainly does not fall into the bottom-up design Shangri-La of which Paul Graham is such a proponent.

In reality, though, web-based applications are driving the industry. PHP is still very relevant in that domain. From very early on, PHP was centered on functionality that is considered basic to any web-based framework. Functionality without which each library is simply a thin wrapper over CGI. Features like easy access to GET and POST variables, session handling, header control, and database access have been built into PHP from, if not the beginning, then close enough that dinosaurs like myself don’t remember it ever being otherwise.

PHP has its own share of frameworks, too, which allow the programmer to painstakingly map SQL schema to XML or vice versa. They carefully abstract the logic out of the view and force the programmer to jump through hoops to write a simple application (although, for complex applications, this often makes the programmer’s life *much* easier.)

PHP does not need any of this. In fact, the most pragmatic framework I have used to date for PHP is the Simple PHP Framework, which is just a set of useful classes to automate some of the more tedious areas of web development. What it does not do is get in the programmer’s way. It is Occam’s razor at work in the world of web development. From the SPF website, quoting a non-existent link:

“All the web frameworks in the world won’t turn a shitty programmer into a good one.”

What PHP is not is elegant. It does not have beauty of prose, nor those features that make languages like ML and Lisp so exciting, such as closures, functions-as-objects, or lazy evaluation. Instead, PHP is, above all, a practical language. Instead, it has less sexy features, such as built-in support for XML, XSLT, and Xpath, support most databases, and the built-in ability to serialize to and from JSON and cookie strings.

It is easy to overlook how simple PHP makes many tasks that are complex in other frameworks. For example, Django’s form library is large and complex. I’ve no doubt that most other frameworks have equally Byzantine systems for developing reusable forms. In PHP, one might just write:

function input($type, $name, $display, $value)
{
    < ?
        <label>< ?= $display ?>
        <input type="<?= $type ?/>" value="< ?= $value ?>" />
    ?>
}

The function could be refined to separate the template and the code by putting the HTML into a separate include:

function input($type, $name, $dispaly, $value)
{
    include 'templates/input.inc.php';
}

Simple, right? Which is not to say that PHP’s faults are not legion. That said, I think that PHP sometimes does a better job of building toward general purpose programming than many other languages do of building toward web development.

Submit article

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.

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.

Submit article

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.

Submit article