A case for PHP (Part 1)

Note: this post was migrated from my old Tumblr-backed blog

The purpose of this post is not simply to bash PHP, but rather to express what I see as severe shortcomings in the PHP language. Ultimately, I’d like to make an argument for a fork of PHP as a way to resolve these shortcomings and it a better language for everyone. Because it would be impossible to make my changes without a completely new project and the final result wouldn’t look much like the PHP that people know and love/hate today, it would need to be a “new” language.

This should be a multi-part series (at least 3 parts) which I will write whenever I have some time and motivation to crank out these ideas.


Before I begin, I’d like to share my background a little bit. I’ve been writing code off and on since I took my first programming class in 6th grade. This class taught BASIC on PCjr machines and, at the time, I had fun doing it but didn’t fully grasp what I learned until 2 or 3 years later when I discovered QBasic on a machine at my dad’s job and I had an idea for how I could write a program to animate a ball bouncing around the screen. From that point on, I was writing a significant amount of code and tearing through programming languages first with REALBasic (then, called CrossBasic or XBasic), to C, then C++, then PERL, ObjC, PHP, BASH, Python, Ruby…… and on and on.

Much in the same regard that I’m pretty much a programming language slut, I’m also an operating system slut. I love seeing how OS’s do things differently and all this diversity has given me, what I consider to be, a pretty decent perspective on good, better and best ways of doing things.

Jumping between these languages, I’ve seen all the various -isms that each language attempts to steer you into. I’ve seen languages go out of their way to make things easier for the developer or easier for the compiler. This leads me to my first section.

You’re doing it wrong

The first, very wrong thing that jumped out at me early in my PHP learning process was that, off the bat, it encourages developers to mix their business logic with their view code. PHP was designed, from day one, to be embedded in HTML.

I understand that this was done for the express reason of lowering the barrier to entry and enabling users to build dynamic web content with minimal effort. This is a great idea, and I’m not faulting the original PHP developers for it, but I feel that it is a bad move to make that part of the core language. If a developer is creating some code that they want to share between projects, whether that code will be used for web content or a commandline script or whatever, they must wrap their code in start and end tags (<?php //code… ?>).

Since the majority of the code that I write is stuff that runs on the commandline, I find it a little annoying to always need to wrap my code in these tags. When creating a web application, especially when using MVC design concepts, the only code that should use embedding is the view code. The rest of the app should both be non-web-accessible and also be nothing but code.

Of course, when running things on the commandline or using CGI (with nginx, for instance), you can configure it to use the ‘-r’ switch to disable the requirement of said tags, but when using mod_php in apache (as is most often the case), this is not an easy task. Also, if you’re mixing files that contain start/end tags with files that do not, it can get hairy, especially if you forget to use the switch.

PHP should have a built-in method for automatically detecting that a file should be treated as raw sourcecode vs embedded code. The most obvious solution would be the use of different file extensions. Personally, I’d choose ‘phpe’ for files with start/end tags and just ‘php’ for raw php source. I don’t believe that affects the difficulty for beginner users in any way and also hints that there is a time and a place for each type of file.

This concludes Part 1. If you’ve got any corrections, you can post in the comments or contact me. Contact info is available on my website (http://spike.grobste.in).