PHP - What Really Sucks About It?

PHP sucks. That's something I think a lot of programmers will agree on, even PHP programmers. For example, Jeff Atwood offers an interesting viewpoint in his blog entry The PHP Singularity. But heck, a lot of programming languages suck. And even though they suck, there are many millions of KLOC written in languages like COBOL, PL/I, and RPG.

Programming languages, like human languages, evolve. PHP started life as a web templating system, and evolved into a general-purpose programming language. During subsequent releases, new features have been added and some cruft deprecated. Other languages, like Perl and RPG have over the decades undergone similar transformations away from their original purposes.

Why is PHP so maligned? Perhaps because many of us have had to deal with PHP code written 10-15 years ago when the language lacked many of the nice features added in recent releases. Or PHP code written by programmers who knew better than the previous programmers on the project.  Or PHP code written by programmers without extensive programming experience. 10-15 years ago, programmers who knew the risks associated with web programming typically chose other languages if they could.

When I started doing PHP programming, I started with PHP 5 and CakePHP. With Cake, you can't help but structure your application using a more or less proper MVC design. It's probably too much trouble not to. And so I know from personal experience that it is indeed possible to write relatively clean code using PHP. Unfortunately, we don't all have the luxury of working with clean PHP code.

What kind of programming shop typically uses PHP? I would guess the typical PHP shop evolved as follows: The shop started out small, perhaps as a one-person company. As the business grew, the demands on the custom PHP application grew as well. Other programmers were brought in, each with their own programming styles. Perhaps one of them was assigned the task of managing the others. But without any significant management experience, eventually the programming staff gets to the point of running from crisis to crisis as the code base gets harder and harder to maintain. Does that sound like your PHP experience? It's a sure-fire recipe for job stress and significant staff turnover.

Based on my own experience, the next time I'm interviewed for a programming position, PHP or otherwise, I would come armed with a bunch of questions, including:

1. Can I see your documents describing your development process?
2. Can I see proof that the documented development process is followed?
3. Would I be reporting to a manager with specific management experience?

To be fair, it's possible to write bad code in any language. But if a programming shop wants to grow beyond a small business, it needs to adopt a different mindset. It needs professional management experience. It needs proper coding standards and processes. It needs programmers who know what it means to work as a team. It needs a staff that understands the importance of egoless programming. Can those things be found in the typical PHP shop?

Cheers! Hans

Scrabble - It's Emotional

We love Scrabble. Lots of people do. It's certainly one of the most fun board games around, and one of the most popular. There are also a number of on-line implementations of the game. One of the most popular was a version hosted on Facebook provided by Electronic Arts (EA). Unfortunately, a few weeks ago, EA changed the program.

The new Scrabble program went through a beta test. And even though the new program was almost universally panned by the reviewers, EA went ahead and foisted the new game on more people. The stream of complaints has been almost steady ever since. Now, they are pushing the program to everyone, and the complaints continue.

Here's a side-by-side comparison of the two programs:

Image by Russ Nemec.

The program on the left is the old program we all enjoyed playing. On the right, the new program, with a cluttered and confusing user interface. In fact, EA even had to write a FAQ for the new program to explain how to use it. Speaking as an experienced programmer, if your program needs a FAQ to explain its use, there's something seriously wrong with the user interface.


Here's one bug I noticed right away on my computer. Note the text "Create New Game" spilling out from the button. Real professional user interface design, eh?

But there's more! The new program won't load for many people. Or it loads very slowly. There have been reported cases where your score gets added to your opponents score. Many complain that they can't move their tiles on the rack, as we could with the old program. There have been complaints about the dictionary. Some don't know how to get to the chat area. Many complain about the general cartoonish appearance of the game. People complain about the ads that pop-up between moves, and the constant request that users recommend the game to their friends. Heck, I wouldn't recommend this piece of shit to my enemies!

You could ask: Why the fuss over a simple game? The answer is simple. This is an emotional issue. Most of us who love playing Scrabble have been playing it for years. I remember playing it as a child. When planning my moves, I would use a dictionary, and I learned a lot of words that way. I'm sure most Scrabble lovers can offer their own stories of how the game has affected them personally. And so for most of us, the connection to the game is visceral. We loved playing the old version of the on-line game. We hate playing the new version.


If you want to add your voice to the complaints, there are two pages on Facebook where EA reps can sometimes be found: ScrabbleEA and Official Scrabble. Are they listening? They do seem to be interested in bug reports for the new game. But they seem to be turning a deaf ear to the flood of requests for EA to bring back the old game. What can they be thinking? Do they think the storm of complaints will die down? Do they think that the Scrabble players who have already left will return? EA needs to understand that this is an emotional issue for us. If they ever did restore the old program, we may well forgive. But we won't forget.


Cheers! Hans

PS. Check out the Facebook page Bring back the old Scrabble.

Is RPG Dead? The Wake

In a previous post called Is RPG Dead? The Autopsy, I suggested I'd probably have more to say on the subject. This offering is in response to Scott Klement's editorial, RPG is Dead? Are You Serious?! I'd like to respond to a couple of points he makes.

First, he brings up the fact that people have been debating RPG's death for the past 20 years, and yet RPG is still around. But why bring up the question at all if there was any doubt as to RPG's future? Does anyone ask if Python is dead? Or PHP? Of course not! No one has to.

Next, he raises the point that most application development on IBM i is done in RPG. No one is denying that. However, no one can deny that IBM i is a platform in decline. The numbers just don't lie. The fortunes of RPG are intimately tied to the fortunes of the platform. As IBM i slowly dies, so does RPG. (I said more on this theme in my blog posting Is RPG Dead? Do We Still Have To Ask?.)

Skipping past some history, Scott talks about what's important to programming business logic. Let's look at each in turn:

Business logic uses numbers heavily. Well, this is not unique to business applications. However, most arithmetic in any business application, like in any other domain, is integer arithmetic. Business logic does make use of decimal numbers, but even there, most operations involving decimal numbers are simply the movement of data. Actual decimal arithmetic is a small part of the logic, and in most business apps, could be implemented fully in SQL code. That said, other languages do have support for decimal arithmetic. Scott mentions Java for one. Python is another. Even PHP has support for decimals.

Business logic uses databases heavily. Business applications don't have a monopoly on using databases. Many different domains, from gaming to on-line social networking to statistical analysis make at least moderate use of databases. And so you can find support for databases in practically every programming language out there. RPG gives you two choices: built-in I/O operations and pre-processed SQL. Other languages often provide higher-level access to databases. For example, in CakePHP, you define your high-level relationships (1-1, n-1, 1-n, n-n) between your tables, and one find() operation can bring in all related data for a transaction. That is, the framework figures out the SQL for you, including joins. Among the available RPG frameworks, which one can provide that level of power?

Business logic uses dates frequently. And so do many other types of programs. And so you can find date support in practically all modern programming languages. RPG is certainly not unique. Python has the datetime class. PHP has an extensive list of date/time functions and classes.

Business logic uses a lot of string manipulation. I disagree with that assertion since strings are most commonly needed in the presentation layer of an application. But let's assume it's true for business logic. Again, what modern programming language lacks support for strings? Languages like Python, Perl, and PHP (to name a few) all have very powerful string support. Much more powerful than RPG's support. In those other languages, strings are all objects, with a rich set of methods. RPG, in comparison, has a rather limited choice of string operations. Consider the ease of doing regular expression matching in Perl, Python, and PHP. And compare that to what you need to do in RPG.

If these four categories define what's important in programming business logic, there are clearly languages other than RPG that have a definite advantage. Whenever I see someone claim that RPG is the best language for business logic, I always interpret that to mean that the author simply knows RPG best. And Scott certainly is an expert on RPG.

Finally, Scott makes the point that RPG is still being enhanced and supported. True. However, other languages have long ago surpassed RPG in terms of features and capabilities. In my previous missive, I listed half a dozen features common to other programming languages that are still lacking in RPG. And I could have listed more. And other languages continue to grow and gain in popularity.

RPG will not disappear overnight. To say that RPG is dead is an exaggeration. However, it is becoming increasingly irrelevant in the I.T. world. I'm reminded of a job interview I had back in 2008 where the interviewer looked at my resume and asked: "What's an iSeries?". (RPG wasn't discussed at all in that interview.)

Cheers! Hans