The SitePoint Forums have moved.

You can now find them here.
This forum is now closed to new posts, but you can browse existing content.
You can find out more information about the move and how to open a new account (if necessary) here.
If you get stuck you can get support by emailing forums@sitepoint.com

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Is PHP ugly?

PHP is not about purity in CS principles or architecture, it is about solving the ugly web problem with an admittedly ugly, but extremely functional and convenient solution. If you are looking for purity you are in the wrong boat. Get out now before you get hit by a wet cat!

The real issue is not "how ugly is the programming language?", but "how ugly is the code you write in that language?" PHP allows you to write beautiful or revoltingly ugly code.

A couple of comparisons: The way object orientation has been implemented in Perl 5 is fascinating and minimalistic. It appeals to my sense of simplicity. But the resulting application code is ugly in the sense that you're forced to add stuff that shouldn't have to be there. Java is an attempt at purity, I guess, but the things you have to do just for bureaucratic reasons aren't always pretty and don't always contribute to the readability of the code.

Gabriel's central argument was about a very specific tradeoff between implementation and interface complexity, one which rather exactly fits the categories we have examined in this chapter. Gabriel contrasts an ‘MIT’ philosophy most valuing interface simplicity with a ‘New Jersey’ philosophy most valuing implementation simplicity. He then proposes that although the MIT philosophy leads to software that is better in the abstract, the (worse) New Jersey model has better propagation characteristics. Over time, people pay more attention to software written in the New Jersey style, so it improves faster. Worse becomes better.
...
Gabriel himself, while sticking with the observation that ‘worse’ is more infectious and tends to win in the end, has publicly changed his mind several times about the underlying complexity-related question of whether or not this is actually a good thing. His uncertainty mirrors a lot of ongoing design debates within the Unix community.

Richard Gabriel describes the MIT approach:

Originally Posted by Lisp: Good News, Bad News, How to Win Big

The essence of this style can be captured by the phrase the right thing. To such a designer it is important to get all of the following characteristics right:

Simplicity -- the design must be simple, both in implementation and interface. It is more important for the interface to be simple than the implementation.

Correctness -- the design must be correct in all observable aspects. Incorrectness is simply not allowed.

Consistency -- the design must not be inconsistent. A design is allowed to be slightly less simple and less complete to avoid inconsistency. Consistency is as important as correctness.

Completeness -- the design must cover as many important situations as is practical. All reasonably expected cases must be covered. Simplicity is not allowed to overly reduce completeness.

Richard Gabriel describes the new jersey approach:

The worse-is-better philosophy is only slightly different:

Simplicity -- the design must be simple, both in implementation and interface. It is more important for the implementation to be simple than the interface. Simplicity is the most important consideration in a design.

Correctness -- the design must be correct in all observable aspects. It is slightly better to be simple than correct.

Consistency -- the design must not be overly inconsistent. Consistency can be sacrificed for simplicity in some cases, but it is better to drop those parts of the design that deal with less common circumstances than to introduce either implementational complexity or inconsistency.

Completeness -- the design must cover as many important situations as is practical. All reasonably expected cases should be covered. Completeness can be sacrificed in favor of any other quality. In fact, completeness must sacrificed whenever implementation simplicity is jeopardized. Consistency can be sacrificed to achieve completeness if simplicity is retained; especially worthless is consistency of interface.

I think PHP represents the New Jersey approach. Consistency? not here. Watch out for that wet cat.

Interestingly, the premise is that New Jersey programs propagate faster than MIT programs and I think thats true. PHP spreads on the basis of its simple hello world, the ease of deploying your hello world to the server, the wide availability, the low cost, and the fact that there aint no stinking data types to get in your way.

The price for this, as in the interrupt handling example from the previous articles, is that the end programmer is saddled with a more complicated interface. (See PhpHttpResponseHandling for a comparison of PHP response handling interface versus java.)

The idea that worse propogates faster is something I seem to have used by accident. The SimpleTest interface is...well...simple is a kind way to describe it .

What happens is that people are immediately dissatisfied with it and want to change it. Well, surprise surprise, there is a tutorial on how to do this. It is one of the most popular revisit pages in the whole site. Having done that, they fell they have more control. Not just confident enough to use the tool, but confident enough to have an opinion on it. And they then e-mail me too, so I get more feedback.

I was deliberately sneaky here for different reasons. I used to teach people how to use Windows 3.1 a long time ago. I never showed them Word or Excel, but instead showed them how to change the wallpaper. Then I showed them how to use an icon editor to change all of the icons. Now everybody has an opinion on the right way to do their desktop, so discussion with each other would start and people would see each other saving files, etc. My job was easy.

The Eric Raymond, etc. descriptions mesh with this.

The path seem to be...
1) Irritation leading to an opinion.
2) Exploration only to find something quite primitive.
3) Experimentation (this is the hard part).
4) Customisation.
5) Confidence and control, of a small section at least.
6) An opinion about the internal structure.
7) ...?

I don't know if this has anything to do with the uglyness of the language, but sometimes I really, really wish that PHP used dot notation instead of those ugly arrows (and no, I don't have a background in Java)

I don't know if this has anything to do with the uglyness of the language, but sometimes I really, really wish that PHP used dot notation instead of those ugly arrows (and no, I don't have a background in Java)

I can't agree more but if PHP were to use dot notation, they would have to seriously consider doing so as it might lead to code confusion in conjunction with the cocatenated. Well. perhaps to newbies.

@lastcraft Wonder if there's some kind of slogan there: "PHP - the itch you just gotta scratch"? First time I've heard the "worse is better" argument - it's almost scary.

I used to teach people how to use Windows 3.1 a long time ago. I never showed them Word or Excel, but instead showed them how to change the wallpaper. Then I showed them how to use an icon editor to change all of the icons. Now everybody has an opinion on the right way to do their desktop, so discussion with each other would start and people would see each other saving files, etc. My job was easy.

I bet if more people knew about print_r(), the world would be a better place (The PHP and Sitepoint world that is )

I have a custom function I used to use for in-script debugging:

PHP Code:

<?php
/**
* function to dump data for debug display
*
* I got this function from the user-feedback section
* for the print_r function on php.net. It is very
* useful for debugging. It now features the use of
* debug_backtrace to show exactly where and in which
* file the dp() call is being made from.
*
* @param mixed $call variable to have its data displayed
* @param string string to describe the data dump
*
*/
function dp($call,$cname='') {
/**
* @global boolean $debug variable to toggle debug output on or off
**/
global $debug;
if($debug){
echo backtrace_header(debug_backtrace(),$cname);
echo '<pre style="text-align:left;">';

You tackle PHP in a very theoretical way. It was never meant to have anything like object orientation in it, it started off very much as a templating language. You touch on the improved OO of PHP5 - and yes, while it is going to be almost like Java, it will never be quite like it. After a couple of years of OO programming, I still think of myself as a beginner when I approach, for example, OO patterns - really fascinating. But, if PHP was a tree, you are grabbing the branches with your discussion, rather than looking at the root, as that is where the problem lies.

What I find in the real world, I am working as a PHP developer, is that while PHP can be beautiful, it's roots are ugly. Mostly spaghetti code. For someone to learn how to display "Hello World!" on the screen would only take five minutes.
Procedural programming is nice, but it lacks the abstractability, and thus the power of OO. The problem comes in you have to write pieces of software together: one OO programmer, one procedural programming/spaghetti-code programmer. The PHP he writes - I look at it, I understand it, I can't say anything, because those discussions have happened before and ended up in alienation.

Strangely, though, I find that PHP is beautiful because it has evolved from that. PHP is evolving as we speak and that makes it a "living" language. I can't wait to get PHP5 RC1. OO - yes, bring it in, as much as possible, but do it organically, because everything else won't work.

What is it about PHP that makes it so good for web projects? On the face of it, it looks like half-*** Perl or or scriptlet-based JSP pages. I mean all the bad things we're supposed to be getting away from with MVC and JSTL is included in PHP. Yet, the language is used quite efficiently and well. Yahoo uses it for a ton of projects, all the best web-based BBS systems are written in PHP and now WordPress impresses as well.

That's another summing point of view.

You tackle PHP in a very theoretical way. It was never meant to have anything like object orientation in it, it started off very much as a templating language. You touch on the improved OO of PHP5 - and yes, while it is going to be almost like Java, it will never be quite like it. After a couple of years of OO programming, I still think of myself as a beginner when I approach, for example, OO patterns - really fascinating. But, if PHP was a tree, you are grabbing the branches with your discussion, rather than looking at the root, as that is where the problem lies.

Very true. It's not just coding styles in PHP as well. Things also start to get awkward when you start asking things like "So can I really lock down PHP with safe mode?".

But at the same time, it's nice to push the limits (no one else is going to discuss PHP design theory, if not those using it) and PHP4 works surprisingly well as an OO language. And because PHP is the itch you just gotta scratch...

Think that's sums up "the PHP factor". Discussions with Java/.NET types re. PHP typically end in "but it works" or "but I'm already finished" from the PHP side.

Personally, I think my comment can be applied any programming language. The prettiest code is not necessarily the most efficient code. In my career as a professional developer over the last 10 years, I have seen code on all sides of the spectrum in dozens of programming languages. Some of it was horrible, some nice looking. None of that phases me. The most efficient code is the best code in my opinion regardless of its structure. For my website, I currently use PHP based scripts. However if something came out tomorrow that worked on the server better and more efficiently, I would switch to it.

So take it as a pro PHP comment or not, but it was just a comment on programming in general regardless of language. I, personally, do not care what the code looks like whether it uses OO or gotos as long as it is efficient, quick and gets the job done. May not hold to your higher standard but since I don't work for you, it doesn't bother me.

I personally think it's hard to write ugly code with PHP.
I'm not talking about in the grand sense, architectually, or anything like that.
I'm just talking about looking at a file full of PHP code.
With Perl, on the other hand, it's hard to not write ugly code.
Close your eyes, and reach your hand out, and pick a random Perl script off the web somewhere, and look at it. It'll probably give you a headache.
Do the same thing, except make it a random PHP script, you'll probably get less of a headache.
I think that's why PHP took off the way it did. People could understand each other's code so much better than they could with Perl, so before too long there was 50 gzillion open source PHP scripts floating around.

9. Database abstraction is mostly a myth. There is nothing wrong with direct database calls' making use of all the tricks and cheats your chosen database has to offer, to tweak as much performance as possible out of it.

10. Keep your base technology and building blocks simple. Stay with a nonthreaded Web server, and avoid complex frameworks and abstraction layers, to give yourself a chance to trace and debug any problems that may come up. Solving the Web problem is simple; don't try to make it hard.

Database abstraction is mostly a myth. There is nothing wrong with direct database calls' making use of all the tricks and cheats your chosen database has to offer, to tweak as much performance as possible out of it.

There's a requirement for high performance assumed here. If we want to "tweak as much performance as possible" out of a Web app, we should never make Web pages like this discussion forum. The HTML code is far too voluminous to download quickly over a slow connection. But sometimes, other things are important as well.

The problem isn't so much leading new PHPer's to confusion, more to do with backward compatablility, for example, if PHP5 was to have used Java like syntax, you couldn't have the backwardness that v5 finds acceptable, even if it is to a certain degree.

Here's a nifty tip - if you are wondering how clean the code in some application is, you can get a very rough idea just by setting error reporting to E_ALL. The number of popular applications that throw up 300 or more notices per page is interesting! It's all for careless things like undefined variables, forgetting to put quotes around string constants, etc. These are things that are likely to cause headaches at some stage during the application's development.

The real test of how clean the code is, is to try and maintain the code - try to get to know how it works and how to modify its behaviour. In terms of maintainability I find that most PHP scripts I have seen fail miserably at this. One of the worst possible things you can do when developing is use a 'quick fix' or try to get an extra few percent of performance out of the application by using some ugly, ugly code.

The argument that code can be as messy as you like as long as it's 'efficient' is a misguided assumption, and it is attitudes like this which cause some of the worst code I've seen. For starters, maintaining such code, even to make minor modifications, inevitably requires progressively uglier and uglier hacks thus reducing any benefit in efficiency that the code originally had. It also means the code is not reusable, and I would define code that cannot be reused or modified as the worst kind of 'inefficient', because the code is just near impossible to work with.

^^ Agree also. There is no excuse for sloppy code, especially if the time was available to do it right. Most decent text editors can be set for auto indention, even converting indents to spaces and some IDEs have Tidy native. I often run phpCodeBeautifier, even on my own stuff, to make it more readable. I have E_ALL on at all times locally to force me to fix notices.