Bummer PHP

Published on 2015-12-20. Modified on 2023-10-19.

Since the release of the PHP programming language, PHP has been both loved and hated by many. In this article we'll take a look at one of the reasons why PHP really is such "a bummer".

A programming language is only as good as it's interpreter or compiler. The interpreter or compiler is the software that parses the source code of the programming language and performs its behavior. Whether the source code is compiled into machine language or translated into an intermediate representation and executed is not important, what's important is how well the interpreter or compiler does its job and how well the interpreter or compiler handles errors in the source code.

Don't get me wrong, with PHP you can be really productive and produce software quickly without the use of frameworks and other junk, but you kindda have to know the "quarks and quirks" of the PHP interpreter. However, it should be known that PHP was never orginally designed, it was mostly a "hack".

A hack is an inelegant solution to a problem. In this sense, a hack gets the job done but in an inefficient, un-optimal or ugly way.

-- Techopedia.

Without going into a lengthy discussion about the PHP interpreter, let us just take a look at one single example of how it handles a specific source code error. This example can serve as a demonstration on one of the many design flaws of PHP.

This is just a really simple piece of code that only serves as a demonstration.

01. $string = "Welcome to my personal home page;
03. if ($page_id == 0) {
04.    renderHomePage();
05. } elseif ($page_id == 1) {
06.    renderContactsPage();
07. } elseif ($page_id == 2) {
08.    renderAboutPage();
09. } elseif ($page_id == 3) {
10.    renderServicesPage();
11. } elseif ($page_id == 4) {
12.    renderWeatherPage();
13. } elseif ($page_id == 5) {
14.    renderNewsPage();
15. }
17. echo "Thank you for visiting!";

Can you spot the error?

If we run this through the PHP interpreter we get the following error messages:

In PHP 5.2, 5.4 and 5.5:

FATAL ERROR syntax error, unexpected 'Thank' (T_STRING) on line number 18

In PHP 5.3:

FATAL ERROR syntax error, unexpected T_STRING on line number 18

In PHP 5.6, 7.x and 8.0:

PHP Parse error:  syntax error, unexpected 'Thank' (T_STRING) on line 18

In PHP 8.2.11:

Parse error: syntax error, unexpected identifier "Thank" on line 18

And PHP 8.2.11 was released September 2023.

The problem with this error message is that the error is on line 1 (a missing ending double-quote), not on line 18.

$string = "Welcome to my personal home page;

What really shows just how bad the interpreter handles this error is that PHP uses semi-colon to end expressions. The interpreter uses the semi-colon to know when an expression has been terminated, yet in this example the interpreter still runs through the rest of the code all the way down to the last line and serves that line as the line that has the error.

You might argue that most modern IDE's and editors would catch this error and color the lines after the missing quotes and as such this error would be discovered before the code is run, but this argument only serves to prove that even your IDE is better at catching this error than the PHP interpreter itself.

The error message has even been changed between PHP version 8.0 and 8.2.11, yet the handling of the error is still the same.

Let's reproduce the same error in a couple of other programming languages and see how their interpreters or compilers handles the error.

In the following examples I have shortened the code output for brevity.


1. package main
3. func main() {
4.     var welcome = "Welcome to my personal home page
6.     if ($page_id == 0) {

Compiled with the Go compiler we get the following error message:

test.go:4: newline in string

The compiler tells us that the error is located on line 4 and the problem is a string that ends with a newline (rather than a double quote).

If we use the GNU Go compiler (gccgo) we get the following error message:

test.go:4:49: error: unterminated string
var welcome = "Welcome to my personal home page

This is even better. "Unterminated string" at line 4 at the 49'th character and then we even have a pointer ^ showing us where the problem is located.


1. class helloworld  {
3.     public static void main(String[] args) {
4.         string welcome = "Welcome to my home page;

Let's have a look at the error message:

helloworld.java:4: error: unclosed string literal
string welcome = "Welcome to my home page;
1 error

Again we get a very helpful error message that tells use the correct line number and what the problem is.


1. welcome = "Welcome to my home page
3. if page_id:

And the error message from the Python compiler (2.7.9 in this example):

File "test.py", line 1
welcome = "Welcome to my home page
SyntaxError: EOL while scanning string literal

Again we get the correct line number and a good explanation with a pointer. "EOL" meaning "End Of Line".


1. $welcome = "Welcome to my home page
3. if page_id == 0

And the error message:

test.rb:1: unterminated string meets end of file

The Ruby interpreter also provides us with the correct line number for this case and a very precise explanation of the problem.

We can find strange error messages that makes absolutely no sense in many programming languages, but the point is not about eloquence of speech. In this example the PHP interpreter - going back all the way to 5.2 and further - makes absolutely no sense and is even providing the wrong line number.

This example is in no way unique. PHP is stuffed with these kinds of mistakes.

Every PHP programmer is familiar with the day-to-day tasks that can be tricky or cumbersome.

-- Facebook developers Julien Verlaguet and Alok Menghrajani.

The PHP developers keep adding new functionality, new paradigms, and more complexity to the language and the language keeps growing everytime a new release is made, yet almost no effort is put into solving some of these old and annoying problems.

Of course the developers have fixed a lot of bad stuff over the years, anyone in doubt can just take a look at the change logs, but adding new functionality and new paradigms to a language that still can't even get basic error messaging right smells of muddling.