PHP as Visual Basic of the Web

An anonymous reader writes "Jeff Atwood at Coding Horror has a post about the awfulness of PHP - or, rather, a post about posts about the awfulness of PHP. He points out that PHP has been the whipping boy for the developer community for years, and while everybody seems happy to complain about it, nobody seems willing to do anything about it.

He writes, 'From my perspective, the point of all these "PHP is broken" rants is not just to complain, but to help educate and potentially warn off new coders starting new codebases. Some fine, even historic work has been done in PHP despite the madness, unquestionably. But now we need to work together to fix what is broken. The best way to fix the PHP problem at this point is to make the alternatives so outstanding that the choice of the better hammer becomes obvious.'"

[Oct 21, 2019] Differences between Perl and PHP [closed]

Notable quotes:

"... Perl has native regular expression support, ..."

"... Perl has quite a few more operators , including matching ..."

"... In PHP, new is an operator. In Perl, it's the conventional name of an object creation subroutine defined in packages, nothing special as far as the language is concerned. ..."

"... Perl logical operators return their arguments, while they return booleans in PHP. ..."

"... Perl gives access to the symbol table ..."

"... Note that "references" has a different meaning in PHP and Perl. In PHP, references are symbol table aliases. In Perl, references are smart pointers. ..."

"... Perl has different types for integer-indexed collections (arrays) and string indexed collections (hashes). In PHP, they're the same type: an associative array/ordered map ..."

"... Perl arrays aren't sparse ..."

"... Perl supports hash and array slices natively, ..."

Nov 23, 2013 | stackoverflow.com

jholster ,Nov 23, 2013 at 21:20

I'm planning to learn Perl 5 and as I have only used PHP until now, I wanted to know a bit about how the languages differ from each other.
As PHP started out as a set of "Perl hacks" it has obviously cloned some of Perls features.

What are the main differences in the syntax? Is it true that with Perl you have more options and ways to express something?

Why is Perl not used for dynamic websites very often anymore? What made PHP gain more popularity?

hobbs ,Jan 17, 2013 at 8:36
Perl and PHP are more different than alike. Let's consider Perl 5, since Perl 6 is still under development. Some differences, grouped roughly by subject:
Perl has native regular expression support, including regexp literals. PHP uses Perl's regexp functions as an extension.

Perl has quite a few more operators , including matching ( =~ , !~ ), quote-like ( qw , qx &c.), exponentiation ( ** ), string repetition ( x ) and range ( .. and ... ). PHP has a few operators Perl doesn't, such as the error suppression operator ( @ ), instanceof (though Perl does have the Universal ::isa method) and clone .

In PHP, new is an operator. In Perl, it's the conventional name of an object creation subroutine defined in packages, nothing special as far as the language is concerned.
Perl logical operators return their arguments, while they return booleans in PHP. Try:
$foo = '' || 'bar';
in each language. In Perl, you can even do $foo ||= 'default' to set $foo to a value if it's not already set. The shortest way of doing this in PHP is $foo = isset($foo) ? $foo : 'default'; (Update, in PHP 7.0+ you can do $foo = $foo ?? 'default' )
Perl variable names indicate built-in type, of which Perl has three, and the type specifier is part of the name (called a " sigil "), so $foo is a different variable than @foo or %foo . (related to the previous point) Perl has separate symbol table entries for scalars, arrays, hashes, code, file/directory handles and formats. Each has its own namespace.

Perl gives access to the symbol table , though manipulating it isn't for the faint of heart. In PHP, symbol table manipulation is limited to creating references and the extract function.

Note that "references" has a different meaning in PHP and Perl. In PHP, references are symbol table aliases. In Perl, references are smart pointers.

Perl has different types for integer-indexed collections (arrays) and string indexed collections (hashes). In PHP, they're the same type: an associative array/ordered map .

Perl arrays aren't sparse: setting an element with index larger than the current size of the array will set all intervening elements to undefined (see perldata ). PHP arrays are sparse; setting an element won't set intervening elements.

Perl supports hash and array slices natively, and slices are assignable, which has all sorts of uses . In PHP, you use array_slice to extract a slice and array_splice to assign to a slice.

You can leave out the argument to the subscript operator in PHP for a bit of magic. In Perl, you can't leave out the subscript.

Perl hashes are unordered .

Perl has a large number of predefined and magic variables . PHP's predefined variables have quite a different purpose.

Perl has statement modifiers : some control statements can be placed at the end of a statement.

Perl supports dynamic scoping via the local keyword.

In addition, Perl has global, lexical (block), and package scope . PHP has global, function, object, class and namespace scope .

In Perl, variables are global by default. In PHP, variables in functions are local by default.

Perl supports explicit tail calls via the goto function.

Perl's prototypes provide more limited type checking for function arguments than PHP's type hinting . As a result, prototypes are of more limited utility than type hinting.

In Perl, the last evaluated statement is returned as the value of a subroutine if the statement is an expression (i.e. it has a value), even if a return statement isn't used. If the last statement isn't an expression (i.e. doesn't have a value), such as a loop, the return value is unspecified (see perlsub ). In PHP, if there's no explicit return, the return value is NULL .
Perl flattens lists (see perlsub ); for un-flattened data structures, use references.
@foo = qw(bar baz);
@qux = ('qux', @foo, 'quux'); # @qux is an array containing 4 strings
@bam = ('bug-AWWK!', \@foo, 'fum'); # @bam contains 3 elements: two strings and a array ref
PHP doesn't flatten arrays.
Perl has special code blocks ( BEGIN , UNITCHECK , CHECK , INIT and END ) that are executed. Unlike PHP's auto_prepend_file and auto_append_file , there is no limit to the number of each type of code block. Also, the code blocks are defined within the scripts, whereas the PHP options are set in the server and per-directory config files.

In Perl, the semicolon separates statements . In PHP, it terminates them, excepting that a PHP close tag ("?>") can also terminate a statement.

The value of expressions in Perl is context sensitive .

Negative subscripts in Perl are relative to the end of the array. $bam[-1] is the final element of the array. Negative subscripts in PHP are subscripts like any other.

In Perl 5, classes are based on packages and look nothing like classes in PHP (or most other languages). Perl 6 classes are closer to PHP classes, but still quite different. (Perl 6 is different from Perl 5 in many other ways, but that's off topic.) Many of the differences between Perl 5 and PHP arise from the fact that most of the OO features are not built-in to Perl but based on hacks. For example, $obj->method(@args) gets translated to something like (ref $obj)::method($obj, @args) . Non-exhaustive list:

PHP automatically provides the special variable $this in methods. Perl passes a reference to the object as the first argument to methods.

Perl requires references to be blessed to create an object. Any reference can be blessed as an instance of a given class.

In Perl, you can dynamically change inheritance via the packages @ISA variable.

Perl supports operator overloading .

Strictly speaking, Perl doesn't have multiline comments, but the POD system can be used for the same affect.

In Perl, // is an operator. In PHP, it's the start of a one-line comment.

Until PHP 5.3, PHP had terrible support for anonymous functions (the create_function function) and no support for closures.

PHP had nothing like Perl's packages until version 5.3, which introduced namespaces .

Arguably, Perl's built-in support for exceptions looks almost nothing like exceptions in other languages, so much so that they scarcely seem like exceptions. You evaluate a block and check the value of $@ ( eval instead of try , die instead of throw ). The ~~Error~~ Try::Tiny module supports exceptions as you find them in other languages (as well as some other modules listed in Error's See Also section).
PHP was inspired by Perl the same way Phantom of the Paradise was inspired by Phantom of the Opera , or Strange Brew was inspired by Hamlet . It's best to put the behavior specifics of PHP out of your mind when learning Perl, else you'll get tripped up.

My brain hurts now, so I'm going to stop.
Your Common Sense ,Mar 29, 2010 at 2:19

When PHP came to the scene, everyone were impressed with main differences from Perl:

Input variables already in the global scope, no boring parsing.

HTML embedding. Just <?php ... ?> anywhere. No boring templates.

On-screen error messages. No boring error log peeks.

Easy to learn. No boring book reading.

As the time passed, everyone learned that they were not a benefit, hehe...

Quentin ,Jan 15, 2016 at 3:27
I've noticed that most PHP vs. Perl pages seem to be of the

PHP is better than Perl because <insert lame reason here>

ilk, and rarely make reasonable comparisons.

Syntax-wise, you will find PHP is often easier to understand than Perl, particularly when you have little experience. For example, trimming a string of leading and trailing whitespace in PHP is simply
$string = trim($string);
In Perl it is the somewhat more cryptic
$string =~ s/^\s+//;
$string =~ s/\s+$//;
(I believe this is slightly more efficient than a single line capture and replace, and also a little more understandable.) However, even though PHP is often more English-like, it sometimes still shows its roots as a wrapper for low level C, for example, strpbrk and strspn are probably rarely used, because most PHP dabblers write their own equivalent functions for anything too esoteric, rather than spending time exploring the manual. I also wonder about programmers for whom English is a second language, as everybody is on equal footing with things such as Perl, having to learn it from scratch.

I have already mentioned the manual. PHP has a fine online manual, and unfortunately it needs it. I still refer to it from time to time for things that should be simple, such as order of parameters or function naming convention. With Perl, you will probably find you are referring to the manual a lot as you get started and then one day you will have an a-ha moment and never need it again. Well, at least not until you're more advanced and realize that not only is there more than one way, there is probably a better way, somebody else has probably already done it that better way, and perhaps you should just visit CPAN.

Perl does have a lot more options and ways to express things. This is not necessarily a good thing, although it allows code to be more readable if used wisely and at least one of the ways you are likely to be familiar with. There are certain styles and idioms that you will find yourself falling into, and I can heartily recommend reading Perl Best Practices (sooner rather than later), along with Perl Cookbook, Second Edition to get up to speed on solving common problems.

I believe the reason Perl is used less often in shared hosting environments is that historically the perceived slowness of CGI and hosts' unwillingness to install mod_perl due to security and configuration issues has made PHP a more attractive option. The cycle then continued, more people learned to use PHP because more hosts offered it, and more hosts offered it because that's what people wanted to use. The speed differences and security issues are rendered moot by FastCGI these days, and in most cases PHP is run out of FastCGI as well, rather than leaving it in the core of the web server.

Whether or not this is the case or there are other reasons, PHP became popular and a myriad of applications have been written in it. For the majority of people who just want an entry-level website with a simple blog or photo gallery, PHP is all they need so that's what the hosts promote. There should be nothing stopping you from using Perl (or anything else you choose) if you want.

At an enterprise level, I doubt you would find too much PHP in production (and please, no-one point at Facebook as a counter-example, I said enterprise level).
Leon Timmermans ,Mar 28, 2010 at 22:15

Perl is used plenty for websites, no less than Python and Ruby for example. That said, PHP is used way more often than any of those. I think the most important factors in that are PHP's ease of deployment and the ease to start with it.
The differences in syntax are too many to sum up here, but generally it is true that it has more ways to express yourself (this is know as TIMTWOTDI, There Is More Than One Way To Do It).

Brad Gilbert ,Mar 29, 2010 at 4:04
My favorite thing about Perl is the way it handles arrays/lists. Here's an example of how you would make and use a Perl function (or "subroutine"), which makes use of this for arguments:
sub multiply
{
 my ($arg1, $arg2) = @_; # @_ is the array of arguments
 return $arg1 * $arg2;
}
In PHP you could do a similar thing with list() , but it's not quite the same; in Perl lists and arrays are actually treated the same (usually). You can also do things like:
$week_day_name = ("Sunday", "Monday", "Tuesday", "Wednesday", "Thursday", "Friday", "Saturday")[$week_day_index];
And another difference that you MUST know about, is numerical/string comparison operators. In Perl, if you use < , > , == , != , <=> , and so on, Perl converts both operands to numbers. If you want to convert as strings instead, you have to use lt , gt , eq , ne , cmp (the respective equivalents of the operators listed previously). Examples where this will really get you:
if ("a" == "b") { ... } # This is true.
if ("a" == 0) { ... } # This is also true, for the same reason.
Sorin Postelnicu, Aug 5, 2015 at 15:44

I do not need add anything to outis's fantastic answer, i want only show the answer for you question:

Why is Perl not used for dynamic websites very often anymore? What made PHP gain more popularity than it?

Please check first some "Job Trends" sites - and you can make the judgement alone.

http://www.indeed.com/jobtrends?q=perl,%20ruby,%20python,%20php

as you can see, perl is still a leader - but preferable for real applications not for toys. :)

[Jun 29, 2012] The PHP Singularity

Slashdot
Python has *always* been obviously better than PHP (or perl, etc.) But if you have no skills, you look for the easiest path: the goal is to get the project going.
If your expertise is Perl, climbing the Python learning curve, gentle as it may be, isn't attractive, and becomes less so as your available time to engage in such things narrows. And so your project $sucks @terribly $$ and looks like APL But it works fine because you know how all that perl weirdness operates:

$_ = shift; tr/+/ /; s/%(..)/pack('c', hex($1))/eg; return($_);

For a new user with no skills (which really seems to be the primary group that ends up using it), the availability of PHP examples and the ease of putting a canned site up seem to be the primary enticements. Slap a canned site up, and bam, there you are. *Now* you can learn how it works (which accounts of a lot of strange things on the web, but I digress.)

So better isn't really the issue. Easier is the bottom line, it seems to me. Where are the canned sites in Python? For that matter where are the canned sites in Perl or Ruby or whatever?

If "better" were all it took, no one would be running Windows, for instance, but that's not the case.

Mind you... *I'm* not running windows, and I long ago abandoned Perl for Python (and I'm so glad I did), but I'm someone who actually has the time to explore and make choices without someone else hovering over my shoulder or otherwise being compromised. I don't think that's very common.

alex67500 (1609333) writes:

Re:Recursive? No, very iterative.

Ever since programming languages existed, they have been classified in 2 categories:
- Those every one bitches about,
- and those nobody uses...
leonbloy (812294) writes: on Friday June 29, @02:27PM (#40497139)
Ever since programming languages existed, they have been classified in 2 categories: - Those every one bitches about, - and those nobody uses...

Sounds clever, but it's plainly false.

C, Java, C# are among the most used languages today. Very few serious programmers will say that they are stupid or awful. And, many criticisms aside, most programmers respect them - even love them. I program in all these languages, I like them all, and I hate PHP with passion. It's not an issue of popularity; PHP, its community, its history, all of it, is a tale of terror.

Reality Master 101 (179095) writes:

<RealityMaster101 AT gmail DOT com> on Friday June 29, @03:24PM (#40497959) Homepage Journal

Very few serious programmers will say that they are stupid or awful.

Huh? Have you just fallen off the turnip truck?

C: Unsafe at any speed. Un-bound-checked array, null pointers, etc, etc. Many people HATE C because it's unsafe, though they grudgingly admit that it's sometimes a necessary evil for system programming.

C++: Overly complex, insane learning curve, no garbage collection. There are no shortage of people who hate C++.

And Java is possibly your most absurd point. Overly verbose to the extreme, slow, insane memory requirements, slow, crazy libraries, and slow (please don't bother to claim that isn't slow).

=== PHP is a language for getting thing done. Just like any toolbox, you can build great or terrible things with it. It's like perl in that way (and I've done plenty of both). If you code well, there's very little to complain about with PHP. I've hired java guys onto my php projects before, and they were up and running in a week or so because we were coding with some structure instead of slapping together hacks.

And personally, I wouldn't want it any other way. I don't want language designers deciding they know what I want to do better than me. What I want, is the flexibility to build things as I see fit, and to do so quickly. Production is my goal. If you can help me build my projects elegantly/etc, then great, but getting it built quickly is always my priority.

MightyMartian (840721) writes:

It's a broken tool that one has to put a considerable amount of effort into to write tolerably decent apps. It's libraries couldn't be worse than if someone took a print out of the specs, stuck dynamite in the middle and then tried to reassemble them. Coding in PHP has got to be one of the miserable experiences I have had, the only thing being worse is trying to fix someone else's PHP code. Anonymous Coward writes: on Friday June 29, @12:32PM (#40495359) Any good programmer will be able to make awesome PHP code. Bad PHP written applications are just the result of lack of passion, knowledge, and in some cases don't forget it, pressure from the customer. Combine bad programming skills, no experience with other OOP languages, pressure and "I don't care how it is done, I've done it and it works that's enough"... and you get the result. I'm tired to read and hear that PHP is shit. -- ParaBug ===

The one big redeeming feature of PHP is you set up a single DB server (or even multimaster) plus multiple webservers, and bam! You're sharing objects/sessions among the webservers. Doesn't matter what webserver the next request hits, the session's there.

By contrast, that simple thing is something that other environments struggle with. I remember ads for "Share Java POJOs" as if that was a huge deal, and the CEO of some firm that did that said people told him that was a godsend. I'd imagine it's the same for Python and Ruby.

1. Java. Huge memory footprint. Admins hate it because it doesn't conform to certain Unix conventions.

Try this: Download any one of a number of open-source Java CMSs or ERM systems. Then watch the Java exceptions flow down your console screen. Good luck figuring them out. Static analysis rules, except when it doesn't.

Java's great if you're writing an desktop app for geologists trying to find oil or a backend bank system. For your average, ho-hum, billion-dollar website: not so much.

2. Ruby: You go to war with the webserver they give you, not the one you want.

3. Python: Great language and library. A shame it was hobbled by the whitespace issue, which meant that some programmers didn't check it out who should have. Anyway, it's hard for Beta to get traction against VHS.

Anotherwords, PHP is good enough. "Worse is better. [wikipedia.org]"

Since the three environments above are monolithic, if there's a problem, it's a problem for every client logged in. PHP, by contrast, follows a Unix minimalist philosophy: if a PHP FCGI instance (or even an Apache mod_php instance) crashes, it's just that one instance. No problem, user hits F5, reloads, PHP's stateless, you get the session back, keep calm and carry on.

When Marc Zuckerberg or a number of other entrepreneurs started hacking out Facebook, they started out with PHP, just because it's light and fast, and easy to get something up on the wall. Nobody cares about the elegance of Python or Ruby, it's all about time to market.

Finally, nothing about "you can't debug PHP", in today's discussion, please. You can very well step through PHP code. Use Netbeans and something like xdebug. Or Eclipse.

KalvinB (205500) writes:

PHP: Paraphrasing Churchill, it's bad, but the alternatives are worse.

If PHP were as awful as the author claims, "Some fine, even historic work has been done in PHP" would not be possible.

Coders without the most basic grasp of object oriented designed, initial variable initialization, white-space use, code flow, etc are the problem. Languages that try to force coders to not be retarded are not the answer. It's very easy to spot coders you should never hire if they use a language that lets them reveal their ignorance and lack of organization skills.

It's far easier to modernize code while maintaining the same core language than it is to completely start from scratch with a new language.

While PHP's OO functionality is pretty lousy up until 5.3 when it finally got late static binding, it is perfectly sufficient and no excuse for crappy spaghetti code.

MightyMartian (840721) writes:

Millions of lines of fine, historic code were written in COBOL, but I don't exactly here anyone declaring it a wondous language.

edremy (36408) writes:

It was a wonderous language. It was (for the time) very easy to use, powerful and understandable. Millions of lines of code were written in it because it *worked*.

Fortran's pretty similar- nobody here is going to hold it up as a language marvel, but it was- it fit the niche of "powerful number processor" very well. Perl is noted for being a complete mess, but if you need a quick script to massage some text nothing is better. BASIC fit into its niche as well, and frankly so does PHP

tepples (727027) writes:

None of them were

This web host [securepaynet.net] offers PHP for $5.95 per month or Perl, Ruby, or Python for twice that. It's too bad because otherwise, they appear to be one of the least expensive entry-level hosting services that supports SSL. (Without SSL, your users can get Firesheeped.)

EmperorOfCanada (1332175) writes:

I would be less quick to blame PHP than blame the fact that many PHP programmers come from "Web" developers. People who started with MS Paint and some HTML, then some CSS and then jammed in some PHP. After a while they got pretty good at small PHP 50 line programs. But when faced with huge projects people like this just aren't prepared. A great programmer could use PHP just as well as any other language.

But the second half is that PHP should be bad at times. Often a simple unstructured script is the best. It needs to do a simple thing quickly and well. There is no need for templating, language abstraction, unit testing, separation of data, logic, and view. So if you are a bank deploying a mission critical system then it should be rigorous and perfect. But if your blog about car tires needs a widget that reads from your odometer then hack away.

I would say that all arguments that condemn PHP should whither under the light that Facebook was developed primarily in PHP with MySQL. Even now they have their Hip Hop that converts PHP to C++. Arguing against PHP is like saying that Carbon Fiber is a better material than steel for car frames. Absolutely true but most cars are still successfully made from steel for a wide variety of reasons. Next time I need to win an F1 challenge and it had better be Carbon Fiber. But for the next ride to the grocery store and I just don't care.
So to circle around one could argue that the best cars are made from this or that but the reality is that what made the truly terrible cars terrible was that the designer would have made a terrible car out of anything. So teach a "better" language to the people making messes with PHP and you will just have a different kind of mess.

Angst Badger (8636) writes:

I've programmed in every major language and several minor ones from the 1970's to the present day, never mind design methodologies. They all have their relative strengths and weaknesses, but at the end of the day, the only thing that really recommends one over the other is a) what's available, and b) what you're most familiar with. No widely used language is "broken" any more than any natural spoken language is broken. No one ever says, hey, this novel would be much easier to write if we were taking advantage of the greater expressive power of Indonesian instead of kludgy old Lithuanian.

Aside from juvenile cliquishness and fashion obsession, every language flamefest starts with people obsessing on some awkward feature of the dominant language du jour, and then concluding that all of their problems would be solved if we all switched to some other language without that awkward feature. Of course, tomorrow's language (or methodology, editor, coding standard, platform) has its own awkward qualities that will only become apparent once it collides with the real world on a large scale, setting the stage for the day after tomorrow's language. Rarely does anyone pull their head out of their compiler/interpreter long enough to recognize that it's the real world that's awkward, and no amount of switching between fundamentally equivalent machine-parseable languages is going to change that.

Instead, we keep implementing the same stuff over and over in one language after another until the pace of real progress slows so much that we can actually get excited that the document viewer we're trying to port everything over to is receiving a "major" new features in HTML5 that will allow it to get a little closer to matching the desktop GUI functionality of twenty years ago, only not as well and with the added requirement of several orders of magnitude more hardware power required to keep it going.

But by all means, let's get rid of PHP if that makes it easier to imagine that we're doing something besides reinventing the same old wheel and doing it badly.

melonman (608440) writes:

The assumption in TFA seems to be that PHP does something that couldn't be done otherwise now, or does it more easily, or something. But I don't think that's true. There are alternative languages and alternative ecosystems now. IMO, most PHP coders don't use PHP because they have looked at the alternatives and decided PHP is the best choice, or the least bad choice, or any other choice. People use PHP because either

1: It was forced upon them for some reason or

2: It was the first thing they found and it was good enough

If that's the case, it's irrelevant how fantastic the alternatives are.

Also, while PHP code can be truly terrible, people who are determined to write terrible code will do so whatever the tool. You can use almost anything as a hammer if you try hard enough. The myth that The One Right Language somehow makes bad programmers good is still alive, especially within the Python community, but it's stll a myth.

When good programmers have no choice but to use PHP, they'll find a way to build something that is workmanlike even if it isn't beautiful. When bad programmers program, the result is going to be bad regardless of the language.

Garble Snarky (715674) writes:

I've been using PHP for years, and not two days ago I decided it's probably worth learning python and switching to that for server-side scripts. I got a python cgi script working in about 10 minutes. Then, I just wanted to be able to run python scripts from arbitrary locations on my site. Looking into that, I could not find a single explanation or tutorial website to help me out. Is that just not how python works? Can anyone point me to some resources that will help an amateur familiar with PHP, learn to completely replace PHP with python, on a commercially hosted webserver?

DrVomact (726065) writes:

I am one of those "stupid" PHP users. It's not the first language I learned, nor is it the last. I'm well aware of Python as an alternative for developing web apps, and I've tried it, but I really do prefer PHP.

One reason is flexibility in flow control. PHP has do ... while loops. Also, I can do "continue 2" or "break 2" if there is a loop within a loop, to continue or break at the outer loop. I'm honestly puzzled that Python still hasn't added these obvious and useful things.

I've asked Python types about this, and gotten reasons like "you shouldn't be doing that in the first place," which pisses me off and makes me want to stick with PHP even more.

I'm going to tell you what you don't want to hear, and I'm going to tell you because it's true: you shouldn't be doing that. The reasons why you shouldn't be doing that have nothing to do with any one programming language, they are general to all programming languages. They are the same as the reasons why you shouldn't have GOTO statements, and these things were learned near the very beginnings of the study of programming as a discipline.

There are far too many people who equate the invention of new programming language with "progress". It ain't so. That being said, it's probably possible for a good programmer to write good code in any language. (I say "probably" because I don't know all the languages, including PHP.) However, not all programmers are equally good, so it might be wise to stick to languages that won't let you commit atrocities.

[Apr 19, 2012] PHP a fractal of bad design

This post is a great summary, but please read comments to this post on the original website. In a way there illustrate the points made in the post much better...

Apr 9, 2012 | fuzzy notepad

I'm cranky. I complain about a lot of things. There's a lot in the world of technology I don't like, and that's really to be expected-programming is a hilariously young discipline, and none of us have the slightest clue what we're doing. Combine with Sturgeon's Law, and I have a lifetime's worth of stuff to gripe about.

This is not the same. PHP is not merely awkward to use, or ill-suited for what I want, or suboptimal, or against my religion. I can tell you all manner of good things about languages I avoid, and all manner of bad things about languages I enjoy. Go on, ask! It makes for interesting conversation.

PHP is the lone exception. Virtually every feature in PHP is broken somehow. The language, the framework, the ecosystem, are all just bad. And I can't even point out any single damning thing, because the damage is so systemic. Every time I try to compile a list of PHP gripes, I get stuck in this depth-first search discovering more and more appalling trivia. (Hence, fractal.)

PHP is an embarrassment, a blight upon my craft. It's so broken, but so lauded by every empowered amateur who's yet to learn anything else, as to be maddening. It has paltry few redeeming qualities and I would prefer to forget it exists at all.

But I've got to get this out of my system. So here goes, one last try.

An analogy

I just blurted this out to Mel to explain my frustration and she insisted that I reproduce it here.

I can't even say what's wrong with PHP, because- okay. Imagine you have uh, a toolbox. A set of tools. Looks okay, standard stuff in there.

You pull out a screwdriver, and you see it's one of those weird tri-headed things. Okay, well, that's not very useful to you, but you guess it comes in handy sometimes.

You pull out the hammer, but to your dismay, it has the claw part on both sides. Still serviceable though, I mean, you can hit nails with the middle of the head holding it sideways.

You pull out the pliers, but they don't have those serrated surfaces; it's flat and smooth. That's less useful, but it still turns bolts well enough, so whatever.

And on you go. Everything in the box is kind of weird and quirky, but maybe not enough to make it completely worthless. And there's no clear problem with the set as a whole; it still has all the tools.

Now imagine you meet millions of carpenters using this toolbox who tell you "well hey what's the problem with these tools? They're all I've ever used and they work fine!" And the carpenters show you the houses they've built, where every room is a pentagon and the roof is upside-down. And you knock on the front door and it just collapses inwards and they all yell at you for breaking their door.

That's what's wrong with PHP.

Stance

I assert that the following qualities are important for making a language productive and useful, and PHP violates them with wild abandon. If you can't agree that these are crucial, well, I can't imagine how we'll ever agree on much.

A language must be predictable. It's a medium for expressing human ideas and having a computer execute them, so it's critical that a human's understanding of a program actually be correct.

A language must be consistent. Similar things should look similar, different things different. Knowing part of the language should aid in learning and understanding the rest.

A language must be concise. New languages exist to reduce the boilerplate inherent in old languages. (We could all write machine code.) A language must thus strive to avoid introducing new boilerplate of its own.

A language must be reliable. Languages are tools for solving problems; they should minimize any new problems they introduce. Any "gotchas" are massive distractions.

A language must be debuggable. When something goes wrong, the programmer has to fix it, and we need all the help we can get.

My position is thus:

PHP is full of surprises: mysql_real_escape_string, E_ACTUALLY_ALL

PHP is inconsistent: strpos, str_rot13

PHP requires boilerplate: error-checking around C API calls, ===

PHP is flaky: ==, foreach ($foo as &$bar)

PHP is opaque: no stack traces by default or for fatals, complex error reporting

I can't provide a paragraph of commentary for every single issue explaining why it falls into these categories, or this would be endless. I trust the reader to, like, think.

Don't comment with these things

I've been in PHP arguments a lot. I hear a lot of very generic counter-arguments that are really only designed to halt the conversation immediately. Don't pull these on me, please. :(

Do not tell me that "good developers can write good code in any language", or bad developers blah blah. That doesn't mean anything. A good carpenter can drive in a nail with either a rock or a hammer, but how many carpenters do you see bashing stuff with rocks? Part of what makes a good developer is the ability to choose the tools that work best.

Do not tell me that it's the developer's responsibility to memorize a thousand strange exceptions and surprising behaviors. Yes, this is necessary in any system, because computers suck. That doesn't mean there's no upper limit for how much zaniness is acceptable in a system. PHP is nothing but exceptions, and it is not okay when wrestling the language takes more effort than actually writing your program. My tools should not create net positive work for me to do.

Do not tell me "that's how the C API works". What on Earth is the point of using a high-level language if all it provides are some string helpers and a ton of verbatim C wrappers? Just write C! Here, there's even a CGI library for it.

Do not tell me "that's what you get for doing weird things". If two features exist, someday, someone will find a reason to use them together. And again, this isn't C; there's no spec, there's no need for "undefined behavior".

Do not tell me that Facebook and Wikipedia are built in PHP. I'm aware! They could also be written in Brainfuck, but as long as there are smart enough people wrangling the things, they can overcome problems with the platform. For all we know, development time could be halved or doubled if these products were written in some other language; this data point alone means nothing.

Ideally, don't tell me anything! This is my one big shot; if this list doesn't hurt your opinion of PHP, nothing ever will, so stop arguing with some dude on the Internet and go make a cool website in record time to prove me wrong :)

Side observation: I loooove Python. I will also happily talk your ear off complaining about it, if you really want me to. I don't claim it's perfect; I've just weighed its benefits against its problems and concluded it's the best fit for things I want to do.

And I have never met a PHP developer who can do the same with PHP. But I've bumped into plenty who are quick to apologize for anything and everything PHP does. That mindset is terrifying.

PHP

Core language

CPAN has been called the "standard library of Perl". That doesn't say much about Perl's standard library, but it makes the point that a solid core can build great things.

Philosophy
PHP was originally designed explicitly for non-programmers (and, reading between the lines, non-programs); it has not well escaped its roots. A choice quote from the PHP 2.0 documentation, regarding + and friends doing type conversion:

Once you start having separate operators for each type you start making the language much more complex. ie. you can't use '==' for stings [sic], you now would use 'eq'. I don't see the point, especially for something like PHP where most of the scripts will be rather simple and in most cases written by non-programmers who want a language with a basic logical syntax that doesn't have too high a learning curve.

PHP is built to keep chugging along at all costs. When faced with either doing something nonsensical or aborting with an error, it will do something nonsensical. Anything is better than nothing.

There's no clear design philosophy. Early PHP was inspired by Perl; the huge stdlib with "out" params is from C; the OO parts are designed like C++ and Java.

PHP takes vast amounts of inspiration from other languages, yet still manages to be incomprehensible to anyone who knows those languages. (int) looks like C, but int doesn't exist. Namespaces use \. The new array syntax results in [key => value], unique among every language with hash literals.

Weak typing (i.e., silent automatic conversion between strings/numbers/et al) is so complex that whatever minor programmer effort is saved is by no means worth it.

Little new functionality is implemented as new syntax; most of it is done with functions or things that look like functions. Except for class support, which deserved a slew of new operators and keywords.

Some of the problems listed on this page do have first-party solutions-if you're willing to pay Zend for fixes to their open-source programming language.
There is a whole lot of action at a distance. Consider this code, taken from the PHP docs somewhere.
 @fopen('http://example.com/not-existing-file', 'r');
What will it do?

If PHP was compiled with --disable-url-fopen-wrapper, it won't work. (Docs don't say what "won't work" means; returns null, throws exception?) Note that this flag was removed in PHP 5.2.5.

If allow_url_fopen is disabled in php.ini, this still won't work. (How? No idea.)

Because of the @, the warning about the non-existent file won't be printed.

But it will be printed if scream.enabled is set in php.ini.

Or if scream.enabled is set manually with ini_set.

But not if the right error_reporting level isn't set.

If it is printed, exactly where it goes depends on display_errors, again in php.ini. Or ini_set.

I can't tell how this innocuous function call will behave without consulting compile-time flags, server-wide configuration, and configuration done in my program. And this is all built in behavior.
The language is full of global and implicit state. mbstring uses a global character set. func_get_arg and friends look like regular functions, but operate on the currently-executing function. Error/exception handling have global defaults. register_tick_function sets a global function to run every tick-what?!

There is no threading support whatsoever. (Not surprising, given the above.) Combined with the lack of built-in fork (mentioned below), this makes parallel programming extremely difficult.

Parts of PHP are practically designed to produce buggy code.

json_decode returns null for invalid input, even though null is also a perfectly valid object for JSON to decode to-this function is completely unreliable unless you also call json_last_error every time you use it.

array_search, strpos, and similar functions return 0 if they find the needle at position zero, but false if they don't find it at all.

Let me expand on that last part a bit.

In C, functions like strpos return -1 if the item isn't found. If you don't check for that case and try to use that as an index, you'll hit junk memory and your program will blow up. (Probably. It's C. Who the fuck knows. I'm sure there are tools for this, at least.)

In, say, Python, the equivalent .index methods will raise an exception if the item isn't found. If you don't check for that case, your program will blow up.

In PHP, these functions return false. If you use FALSE as an index, or do much of anything with it except compare with ===, PHP will silently convert it to 0 for you. Your program will not blow up; it will, instead, do the wrong thing with no warning, unless you remember to include the right boilerplate around every place you use strpos and certain other functions.

This is bad! Programming languages are tools; they're supposed to work with me. Here, PHP has actively created a subtle trap for me to fall into, and I have to be vigilant even with such mundane things as string operations and equality comparison. PHP is a minefield.
I have heard a great many stories about the PHP interpreter and its developers from a great many places. These are from people who have worked on the PHP core, debugged PHP core, interacted with core developers. Not a single tale has been a compliment.

So I have to fit this in here, because it bears repeating: PHP is a community of amateurs. Very few people designing it, working on it, or writing code in it seem to know what they're doing. (Oh, dear reader, you are of course a rare exception!) Those who do grow a clue tend to drift away to other platforms, reducing the average competence of the whole. This, right here, is the biggest problem with PHP: it is absolutely the blind leading the blind.

Okay, back to facts.

Operators
== is useless.

It's not transitive. "foo" == TRUE, and "foo" == 0� but, of course, TRUE != 0.

== converts to numbers when possible (123 == "123foo"� although "123" != "123foo"), which means it converts to floats when possible. So large hex strings (like, say, password hashes) may occasionally compare true when they're not. Even JavaScript doesn't do this.

For the same reason, "6" == " 6", "4.2" == "4.20", and "133" == "0133". But note that 133 != 0133, because 0133 is octal. But "0x10" == "16" and "1e3" == "1000"!

=== compares values and type� except with objects, where === is only true if both operands are actually the same object! For objects, == compares both value (of every attribute) and type, which is what === does for every other type. What.

Comparison isn't much better.

It's not even consistent: NULL < -1, and NULL == 0. Sorting is thus nondeterministic; it depends on the order in which the sort algorithm happens to compare elements.

The comparison operators try to sort arrays, two different ways: first by length, then by elements. If they have the same number of elements but different sets of keys, though, they are uncomparable.

Objects compare as greater than anything else� except other objects, which they are neither less than nor greater than.

For a more type-safe ==, we have ===. For a more type-safe <, we have� nothing. "123" < "0124", always, no matter what you do. Casting doesn't help, either.

Despite the craziness above, and the explicit rejection of Perl's pairs of string and numeric operators, PHP does not overload +. + is always addition, and . is always concatenation.

The [] indexing operator can also be spelled {}.

[] can be used on any variable, not just strings and arrays. It returns null and issues no warning.

[] cannot slice; it only retrieves individual elements.

foo()[0] is a syntax error. (Fixed in PHP 5.4.)
Unlike (literally!) every other language with a similar operator, ?: is left associative. So this:
 $arg = 'T';
 $vehicle = ( ( $arg == 'B' ) ? 'bus' :
 ( $arg == 'A' ) ? 'airplane' :
 ( $arg == 'T' ) ? 'train' :
 ( $arg == 'C' ) ? 'car' :
 ( $arg == 'H' ) ? 'horse' :
 'feet' );
 echo $vehicle;
prints horse.
Variables

There is no way to declare a variable. Variables that don't exist are created with a null value when first used.

Global variables need a global declaration before they can be used. This is a natural consequence of the above, so it would be perfectly reasonable, except that globals can't even be read without an explicit declaration-PHP will quietly create a local with the same name, instead. I'm not aware of another language with similar scoping issues.

There are no references. What PHP calls references are really aliases; there's nothing that's a step back, like Perl's references, and there's no pass-by-object identity like in Python.

"Referenceness" infects a variable unlike anything else in the language. PHP is dynamically-typed, so variables generally have no type� except references, which adorn function definitions, variable syntax, and assignment. Once a variable is made a reference (which can happen anywhere), it's stuck as a reference. There's no obvious way to detect this and un-referencing requires nuking the variable entirely.

Okay, I lied. There are "SPL types" which also infect variables: $x = new SplBool(true); $x = "foo"; will fail. This is like static typing, you see.

A reference can be taken to a key that doesn't exist within an undefined variable (which becomes an array). Using a non-existent array normally issues a notice, but this does not.

Constants are defined by a function call taking a string; before that, they don't exist. (This may actually be a copy of Perl's use constant behavior.)

Variable names are case-sensitive. Function and class names are not. This includes method names, which makes camelCase a strange choice for naming.

Constructs

array() and a few dozen similar constructs are not functions. array on its own means nothing, $func = "array"; $func(); doesn't work.

Array unpacking can be done with the list($a, $b) = ... operation. list() is function-like syntax just like array. I don't know why this wasn't given real dedicated syntax, or why the name is so obviously confusing.

(int) is obviously designed to look like C, but it's a single token; there's nothing called int in the language. Try it: not only does var_dump(int) not work, it throws a parse error because the argument looks like the cast operator.

(integer) is a synonym for (int). There's also (bool)/(boolean) and (float)/(double)/(real).

There's an (array) operator for casting to array and an (object) for casting to object. That sounds nuts, but there's almost a use: you can use (array) to have a function argument that's either a single item or a list, and treat it identically. Except you can't do that reliably, because if someone passes a single object, casting it to an array will actually produce an array containing that object's attributes. (Casting to object performs the reverse operation.)

include() and friends are basically C's #include: they dump another source file into yours. There is no module system, even for PHP code.

There's no such thing as a nested or locally-scoped function or class. They're only global. Including a file dumps its variables into the current function's scope (and gives the file access to your variables), but dumps functions and classes into global scope.

Appending to an array is done with $foo[] = $bar.

echo is a statement-y kind of thing, not a function.

empty($var) is so extremely not-a-function that anything but a variable, e.g. empty($var || $var2), is a parse error. Why on Earth does the parser need to know about empty?

There's redundant syntax for blocks: if (...): ... endif;, etc.

Error handling

PHP's one unique operator is @ (actually borrowed from DOS), which silences errors.

PHP errors don't provide stack traces. You have to install a handler to generate them. (But you can't for fatal errors-see below.)

PHP parse errors generally just spew the parse state and nothing more, making a forgotten quote terrible to debug.

PHP's parser refers to e.g. :: internally as T_PAAMAYIM_NEKUDOTAYIM, and the << operator as T_SL. I say "internally", but as above, this is what's shown to the programmer when :: or << appears in the wrong place.

Most error handling is in the form of printing a line to a server log nobody reads and carrying on.

E_STRICT is a thing, but it doesn't seem to actually prevent much and there's no documentation on what it actually does.

E_ALL includes all error categories-except E_STRICT.

Weirdly inconsistent about what's allowed and what isn't. I don't know how E_STRICT applies here, but these things are okay:

Trying to access a non-existent object property, i.e., $foo->x. (warning)

Using a variable as a function name, or variable name, or class name. (silent)

Trying to use an undefined constant. (notice)

Trying to access a property of something that isn't an object. (notice)

Trying to use a variable name that doesn't exist. (notice)

2 < "foo" (silent)

foreach (2 as $foo); (warning)

And these things are not:

Trying to access a non-existent class constant, i.e., $foo::x. (fatal error)

Using a constant string as a function name, or variable name, or class name. (parse error)

Trying to call an undefined function. (fatal error)

Leaving off a semicolon on the last statement in a block or file. (parse error)

Using list and various other quasi-builtins as method names. (parse error)

Subscripting the return value of a function, i.e., foo()[0]. (parse error; okay in 5.4, see above)

There are a good few examples of other weird parse errors elsewhere in this list.

The __toString method can't throw exceptions. If you try, PHP will� er, throw an exception. (Actually a fatal error, which would be passable, except�)

PHP errors and PHP exceptions are completely different beasts. They don't seem to interact at all.

PHP errors (internal ones, and calls to trigger_error) cannot be caught with try/catch.

Likewise, exceptions do not trigger error handlers installed by set_error_handler.

Instead, there's a separate set_exception_handler which handles uncaught exceptions, because wrapping your program's entry point in a try block is impossible in the mod_php model.

Fatal errors (e.g., new ClassDoesntExist()) can't be caught by anything. A lot of fairly innocuous things throw fatal errors, forcibly ending your program for questionable reasons. Shutdown functions still run, but they can't get a stack trace (they run at top-level), and they can't easily tell if the program exited due to an error or running to completion.

There is no finally construct, making wrapper code (set handler, run code, unset handler; monkeypatch, run a test, unmonkeypatch) tedious and difficult to write. Despite that OO and exceptions were largely copied from Java, this is deliberate, because finally "doesn't make much sense in the context of PHP". Huh?

Functions
Function calls are apparently rather expensive.

Some built-in functions interact with reference-returning functions in, er, a strange way.

As mentioned elsewhere, a lot of things that look like functions or look like they should be functions are actually language constructs, so nothing that works with functions will work with them.
Function arguments can have "type hints", which are basically just static typing. But you can't require that an argument be an int or string or object or other "core" type, even though every builtin function uses this kind of typing, probably because int is not a thing in PHP. (See above about (int).) You also can't use the special pseudo-type decorations used heavily by builtin functions: mixed, number, or callback.
As a result, this:
 function foo(string $s) {}

 foo("hello world");
produces the error:
 PHP Catchable fatal error: Argument 1 passed to foo() must be an instance of string, string given, called in...
You may notice that the "type hint" given doesn't actually have to exist; there is no string class in this program. If you try to use ReflectionParameter::getClass() to examine the type hint dynamically, then it will balk that the class doesn't exist, making it impossible to actually retrieve the class name.

A function's return value can't be hinted.
Passing the current function's arguments to another function (dispatch, not uncommon) is done by call_user_func_array('other_function', func_get_args()). But func_get_args throws a fatal error at runtime, complaining that it can't be a function parameter. How and why is this even a type of error? (Fixed in PHP 5.3.)

Closures require explicitly naming every variable to be closed-over. Why can't the interpreter figure this out? Kind of hamstrings the whole feature. (Okay, it's because using a variable ever, at all, creates it unless explicitly told otherwise.)

Closed-over variables are "passed" by the same semantics as other function arguments. That is, arrays and strings etc. will be "passed" to the closure by value. Unless you use &.

Because closed-over variables are effectively automatically-passed arguments and there are no nested scopes, a closure can't refer to private methods, even if it's defined inside a class. (Possibly fixed in 5.4? Unclear.)

No named arguments to functions. Actually explicitly rejected by the devs because it "makes for messier code".

Function arguments with defaults can appear before function arguments without, even though the documentation points out that this is both weird and useless. (So why allow it?)

Extra arguments to a function are ignored (except with builtin functions, which raise an error). Missing arguments are assumed null.

"Variadic" functions require faffing about with func_num_args, func_get_arg, and func_get_args. There's no syntax for such a thing.
OO

The procedural parts of PHP are designed like C, but the objectional (ho ho) parts are designed like Java. I cannot overemphasize how jarring this is. The class system is designed around the lower-level Java language which is naturally and deliberately more limited than PHP's contemporaries, and I am baffled.

I've yet to find a global function that even has a capital letter in its name, yet important built-in classes use camelCase method names and have getFoo Java-style accessors.

Perl, Python, and Ruby all have some concept of "property" access via code; PHP has only the clunky __get and friends. (The documentation inexplicably refers to such special methods as "overloading".)

Classes have something like variable declaration (var and const) for class attributes, whereas the procedural part of the language does not.

Despite the heavy influence from C++/Java, where objects are fairly opaque, PHP often treats objects like fancy hashes-for example, the default behavior of foreach ($obj as $key => $value) is to iterate over every accessible attribute of the object.

Classes are not objects. Any metaprogramming has to refer to them by string name, just like functions.

Built-in types are not objects and (unlike Perl) can in no way be made to look like objects.

instanceof is an operator, despite that classes were a late addition and most of the language is built on functions and function-ish syntax. Java influence? Classes not first-class? (I don't know if they are.)

But there is an is_a function. With an optional argument specifying whether to allow the object to actually be a string naming a class.

get_class is a function; there's no typeof operator. Likewise is_subclass_of.

This doesn't work on builtin types, though (again, int is not a thing). For that, you need is_int etc.

Also the right-hand side has to be a variable or literal string; it can't be an expression. That causes� a parse error.

clone is an operator?!

Object attributes are $obj->foo, but class attributes are Class::$foo. ($obj::$foo will try to stringify $obj and use it as a class name.) Class attributes can't be accessed via objects; the namespaces are completely separate, making class attributes completely useless for polymorphism. Class methods, of course, are exempt from this rule and can be called like any other method. (I am told C++ also does this. C++ is not a good example of fine OO.)

Also, an instance method can still be called statically (Class::method()). If done so from another method, this is treated like a regular method call on the current $this. I think.

new, private, public, protected, static, etc. Trying to win over Java developers? I'm aware this is more personal taste, but I don't know why this stuff is necessary in a dynamic language-in C++ most of it's about compilation and compile-time name resolution.

PHP has first-class support for "abstract classes", which are classes that cannot be instantiated. Code in similar languages achieves this by throwing an exception in the constructor.

Subclasses cannot override private methods. Subclass overrides of public methods can't even see, let alone call, the superclass's private methods. Problematic for, say, test mocks.

Methods cannot be named e.g. "list", because list() is special syntax (not a function) and the parser gets confused. There's no reason this should be ambiguous, and monkeypatching the class works fine. ($foo->list() is not a syntax error.)

If an exception is thrown while evaluating a constructor's arguments (e.g., new Foo(bar()) and bar() throws), the constructor won't be called, but the destructor will be. (This is fixed in PHP 5.3.)

Exceptions in __autoload and destructors cause fatal errors.

There are no constructors or destructors. __construct is an initializer, like Python's __init__. There is no method you can call on a class to allocate memory and create an object.

There is no default initializer. Calling parent::__construct() if the superclass doesn't define its own __construct is a fatal error.

OO brings with it an iterator interface that parts of the language (e.g., for...as) respect, but nothing built-in (like arrays) actually implements the interface. If you want an array iterator, you have to wrap it in an ArrayIterator. There are no built-in ways to chain or slice or otherwise work with iterators as first-class objects.

Interfaces like Iterator reserve a good few unprefixed method names. If you want your class to be iterable (without the default behavior of iterating all of its attributes), but want to use a common method name like key or next or current, well, too bad.

Classes can overload how they convert to strings and how they act when called, but not how they convert to numbers or any other builtin type.

Strings, numbers, and arrays all have a string conversion; the language relies heavily on this. Functions and classes are strings. Yet trying to convert a built-in or user-defined object (even a Closure) to a string causes an error if it doesn't define __toString. Even echo becomes potentially error-prone.

There is no overloading for equality or ordering.

Static variables inside instance methods are global; they share the same value across all instances of the class.

Standard library

Perl is "some assembly required". Python is "batteries included". PHP is "kitchen sink, but it's from Canada and both faucets are labeled C".

General

There is no module system. You can compile PHP extensions, but which ones are loaded is specified by php.ini, and your options are for an extension to exist (and inject its contents into your global namespace) or not.

As namespaces are a recent feature, the standard library isn't broken up at all. There are thousands of functions in the global namespace.

Chunks of the library are wildly inconsistent from one another.

Underscore versus not: strpos/str_rot13, php_uname/phpversion, base64_encode/urlencode, gettype/get_class

"to" versus 2: ascii2ebcdic, bin2hex, deg2rad, strtolower, strtotime

Object+verb versus verb+object: base64_decode, str_shuffle, var_dump versus create_function, recode_string

Argument order: array_filter($input, $callback) versus array_map($callback, $input), strpos($haystack, $needle) versus array_search($needle, $haystack)

Prefix confusion: usleep versus microtime

Case insensitive functions vary on where the i goes in the name.

About half the array functions actually start with array_. The others do not.

htmlentities and html_entity_decode are inverses of each other, with completely different naming conventions.

Kitchen sink. The libary includes:

Bindings to ImageMagick, bindings to GraphicsMagick (which is a fork of ImageMagick), and a handful of functions for inspecting EXIF data (which ImageMagick can already do).

Functions for parsing bbcode, a very specific kind of markup used by a handful of particular forum packages.

Way too many XML packages. DOM (OO), DOM XML (not), libxml, SimpleXML, "XML Parser", XMLReader/XMLWriter, and half a dozen more acronyms I can't identify. There's surely some kind of difference between these things and you are free to go figure out what that is.

Bindings for two particular credit card processors, SPPLUS and MCVE. What?

Three ways to access a MySQL database: mysql, mysqli, and the PDO abstraction thing.

C influence

This deserves its own bullet point, because it's so absurd yet permeates the language. PHP is a high-level, dynamically-typed programming language. Yet a massive portion of the standard library is still very thin wrappers around C APIs, with the following results:

"Out" parameters, even though PHP can return ad-hoc hashes or multiple arguments with little effort.

At least a dozen functions for getting the last error from a particular subsystem (see below), even though PHP has had exceptions for eight years.

Warts like mysql_real_escape_string, even though it has the same arguments as the broken mysql_escape_string, just because it's part of the MySQL C API.

Global behavior for non-global functionality (like MySQL). Using multiple MySQL connections apparently requires passing a connection handle on every function call.

The wrappers are really, really, really thin. For example, calling dba_nextkey without calling dba_firstkey will segfault.

There's a set of ctype_* functions (e.g. ctype_alnum) that map to the C character-class detection functions of similar names, rather than, say, isupper.

Genericism

There is none. If a function might need to do two slightly different things, PHP just has two functions.

How do you sort backwards? In Perl, you might do sort { $b <=> $a }. In Python, you might do .sort(reverse=True). In PHP, there's a separate function called rsort().

Functions that look up a C error: curl_error, json_last_error, openssl_error_string, imap_errors, mysql_error, xml_get_error_code, bzerror, date_get_last_errors, others?

Functions that sort: array_multisort, arsort, asort, ksort, krsort, natsort, natcasesort, sort, rsort, uasort, uksort, usort

Functions that find text: ereg, eregi, mb_ereg, mb_eregi, preg_match, strstr, strchr, stristr, strrchr, strpos, stripos, strrpos, strripos, mb_strpos, mb_strrpos, plus the variations that do replacements

There are a lot of aliases as well, which certainly doesn't help matters: strstr/strchr, is_int/is_integer/is_long, is_float/is_double, pos/current, sizeof/count, chop/rtrim, implode/join, die/exit, trigger_error/user_error�

scandir returns a list of files within a given directory. Rather than (potentially usefully) return them in directory order, the function returns the files already sorted. And there's an optional argument to get them in reverse alphabetical order. There were not, apparently, enough sort functions. (PHP 5.4 adds a third value for the sort-direction argument that will disable sorting.)

str_split breaks a string into chunks of equal length. chunk_split breaks a string into chunks of equal length, then joins them together with a delimiter.

Reading archives requires a separate set of functions depending on the format. There are six separate groups of such functions, all with different APIs, for bzip2, LZF, phar, rar, zip, and gzip/zlib.

Because calling a function with an array as its arguments is so awkward (call_user_func_array), there are some pairings like printf/vprintf and sprintf/vsprintf. These do the same things, but one function takes arguments and the other takes an array of arguments.

Text

preg_replace with the /e (eval) flag will do a string replace of the matches into the replacement string, then eval it.

strtok is apparently designed after the equivalent C function, which is already a bad idea for various reasons. Nevermind that PHP can easily return an array (whereas this is awkward in C), or that the very hack strtok(3) uses (modifying the string in-place) isn't used here.

parse_str parses a query string, with no indication of this in the name. Also it acts just like register_globals and dumps the query into your local scope as variables, unless you pass it an array to populate. (It returns nothing, of course.)

explode refuses to split with an empty/missing delimiter. Every other string split implementation anywhere does some useful default in this case; PHP instead has a totally separate function, confusingly called str_split and described as "converting a string to an array".

For formatting dates, there's strftime, which acts like the C API and respects locale. There's also date, which has a completely different syntax and only works with English.

"gzgetss - Get line from gz-file pointer and strip HTML tags." I'm dying to know the series of circumstances that led to this function's conception.

mbstring

It's all about "multi-byte", when the problem is character sets.

Still operates on regular strings. Has a single global "default" character set. Some functions allow specifying charset, but then it applies to all arguments and the return value.

Provides ereg_* functions, but those are deprecated. preg_* are out of luck, though they can understand UTF-8 by feeding them some PCRE-specific flag.

System and reflection

There are, in general, a whole lot of functions that blur the line between text and variables. compact and extract are just the tip of the iceberg.

There are several ways to actually be dynamic in PHP, and at a glance there are no obvious differences or relative benefits. classkit can modify user-defined classes; runkit supersedes it and can modify user-defined anything; the Reflection* classes can reflect on most parts of the language; there are a great many individual functions for reporting properties of functions and classes. Are these subsystems independent, related, redundant?

get_class($obj) returns the object's class name. get_class() returns the name of the class the function is being called in. Setting aside that this one function does two radically different things: get_class(null)� acts like the latter. So you can't trust it on an arbitrary value. Surprise!

The stream_* classes allow for implementing custom stream objects for use with fopen and other fileish builtins. "tell" cannot be implemented for internal reasons. (Also there are A LOT of functions involved with this system.)

register_tick_function will accept a closure object. unregister_tick_function will not; instead it throws an error complaining that the closure couldn't be converted to a string.

php_uname tells you about the current OS. Unless PHP can't tell what it's running on; then it tells you about the OS it was built on. It doesn't tell you if this has happened.

fork and exec are not built in. They come with the pcntl extension, but that isn't included by default. popen doesn't provide a pid.

session_decode is for reading an arbitrary PHP session string, but it only works if there's an active session already. And it dumps the result into $_SESSION, rather than returning it.

Miscellany

curl_multi_exec doesn't change curl_errno on error, but it does change curl_error.

mktime's arguments are, in order: hour, minute, second, month, day, year.

Data manipulation

Programs are nothing more than big machines that chew up data and spit out more data. A great many languages are designed around the kinds of data they manipulate, from awk to Prolog to C. If a language can't handle data, it can't do anything.

Numbers

Integers are signed and 32-bit on 32-bit platforms. Unlike all of PHP's contemporaries, there is no automatic bigint promotion. So your math might work differently based on CPU architecture. Your only option for larger integers is to use the GMP or BC wrapper functions. (The developers have proposed adding a new, separate, 64-bit type. This is crazy.)

PHP supports octal syntax with a leading 0, so e.g. 012 will be the number ten. However, 08 becomes the number zero. The 8 (or 9) and any following digits disappear. 01c is a syntax error.

0x0+2 produces 4. The parser considers the 2 as both part of the hex literal and a separate decimal literal, treating this as 0x002 + 2. 0x0+0x2 displays the same problem. Strangely, 0x0 +2 is still 4, but 0x0+ 2 is correctly 2. (This is fixed in PHP 5.4. But it's also re-broken in PHP 5.4, with the new 0b literal prefix: 0b0+1 produces 2.)

pi is a function. Or there's a constant, M_PI.

There is no exponentiation operator, only the pow function.

Text

No Unicode support. Only ASCII will work reliably, really. There's the mbstring extension, mentioned above, but it kinda blows.

Which means that using the builtin string functions on UTF-8 text risks corrupting it.

Similarly, there's no concept of e.g. case comparisons outside of ASCII. Despite the proliferation of case-insensitive versions of functions, not one of them will consider � equal to �.

You can't quote keys in variable interpolation, i.e., "$foo['key']" is a syntax error. You can unquote it (which would generate a warning anywhere else!), or use ${...}/{$...}.

"${foo[0]}" is okay. "${foo[0][0]}" is a syntax error. Putting the $ on the inside is fine with both. Bad copy of similar Perl syntax (with radically different semantics)?

Arrays

Oh, man.
This one datatype acts as a list, ordered hash, ordered set, sparse list, and occasionally some strange combination of those. How does it perform? What kind of memory use will there be? Who knows? Not like I have other options, anyway.

=> isn't an operator. It's a special construct that only exists inside array(...) and the foreach construct.

Negative indexing doesn't work, since -1 is just as valid a key as 0.

Despite that this is the language's only data structure, there is no shortcut syntax for it; array(...) is shortcut syntax. (PHP 5.4 is bringing "literals", [...].)

The => construct is based on Perl, which allows foo => 1 without quoting. (That is, in fact, why it exists in Perl; otherwise it's just a comma.) In PHP, you can't do this without getting a warning; it's the only language in its niche that has no vetted way to create a hash without quoting string keys.
Array functions often have confusing or inconsistent behavior because they have to operate on lists, hashes, or maybe a combination of the two. Consider array_diff, which "computers the difference of arrays".
 $first = array("foo" => 123, "bar" => 456);
 $second = array("foo" => 456, "bar" => 123);
 echo var_dump(array_diff($first, $second));
What will this code do? If array_diff treats its arguments as hashes, then obviously these are different; the same keys have different values. If it treats them as lists, then they're still different; the values are in the wrong order.

In fact array_diff considers these equal, because it treats them like sets: it compares only values, and ignores order.
In a similar vein, array_rand has the strange behavior of selecting random keys, which is not that helpful for the most common case of needing to pick from a list of choices.
Despite how heavily PHP code relies on preserving key order:
 array("foo", "bar") != array("bar", "foo")
 array("foo" => 1, "bar" => 2) == array("bar" => 2, "foo" => 1)
I leave it to the reader to figure out what happens if the arrays are mixed. (I don't know.)
array_fill cannot create zero-length arrays; instead it will issue a warning and return false.

All of the (many�) sort functions operate in-place and return nothing. There is no way to create a new sorted copy; you have to copy the array yourself, then sort it, then use the array.

But array_reverse returns a new array.

A list of ordered things and some mapping of keys to values sounds kind of like a great way to handle function arguments, but no.
Not arrays

The standard library includes "Quickhash", an OO implementation of "specific strongly-typed classes" for implementing hashes. And, indeed, there are four classes, each dealing with a different combination of key and value types. It's unclear why the builtin array implementation can't optimize for these extremely common cases, or what the relative performance is.

There's an ArrayObject class (which implements five different interfaces) that can wrap an array and have it act like an object. User classes can implement the same interfaces. But it only has a handful of methods, half of which don't resemble built-in array functions, and built-in array functions don't know how to operate on an ArrayObject or other array-like class.

Functions

Functions are not data. Closures are actually objects, but regular functions are not. You can't even refer to them with their bare names; var_dump(strstr) issues a warning and assumes you mean the literal string, "strstr". There is no way to discern between an arbitrary string and a function "reference".

create_function is basically a wrapper around eval. It creates a function with a regular name and installs it globally (so it will never be garbage collected-don't use in a loop!). It doesn't actually know anything about the current scope, so it's not a closure. The name contains a NUL byte so it can never conflict with a regular function (because PHP's parser fails if there's a NUL in a file anywhere).

Declaring a function named __lambda_func will break create_function-the actual implementation is to eval-create the function named __lambda_func, then internally rename it to the broken name. If __lambda_func already exists, the first part will throw a fatal error.

Other

Incrementing (++) a NULL produces 1. Decrementing (--) a NULL produces NULL. Decrementing a string likewise leaves it unchanged.

There are no generators.

Web framework

Execution

A single shared file, php.ini, controls massive parts of PHP's functionality and introduces complex rules regarding what overrides what and when. PHP software that expects to be deployed on arbitrary machines has to override settings anyway to normalize its environment, which largely defeats the use of a mechanism like php.ini anyway.

PHP looks for php.ini in a variety of places, so it may (or may not�) be possible to override your host's. Only one such file will ever be parsed, though, so you can't just override a couple settings and call it a day.

PHP basically runs as CGI. Every time a page is hit, PHP recompiles the whole thing before executing it. Even dev servers for Python toy frameworks don't act like this.
This has led to a whole market of "PHP accelerators" that just compile once, accelerating PHP all the way to any other language. Zend, the company behind PHP, has made this part of their business model.

For quite a long time, PHP errors went to the client by default-I guess to help during development. I don't think this is true any more, but I still see the occasional mysql error spew at the top of a page.

PHP is full of strange "easter eggs" like producing the PHP logo with the right query argument. Not only is this completely irrelevant to building your application, but it allows detecting whether you're using PHP (and perhaps roughly guessing what version), regardless of how much mod_rewrite, FastCGI, reverse proxying, or Server: configuration you're doing.

Blank lines before or after the <?php ... ?> tags, even in libraries, count as literal text and is interpolated into the response (or causes "headers already sent" errors). Your options are to either strictly avoid extra blank lines at the end of every file (the one after the ?> doesn't count) or to just leave off the ?> closing token.

Deployment

Deployment is often cited as the biggest advantage of PHP: drop some files and you're done. Indeed, that's much easier than running a whole process as you may have to do with Python or Ruby or Perl. But PHP leaves plenty to be desired.

Across the board, I'm in favor of running Web applications as app servers and reverse-proxying to them. It takes minimal effort to set this up, and the benefits are plenty: you can manage your web server and app separately, you can run as many or few app processes on as many machines as you want without needing more web servers, you can run the app as a different user with zero effort, you can switch web servers, you can take down the app without touching the web server, you can do seamless deployment by just switching where a fifo points, etc. Welding your application to your web server is absurd and there's no good reason to do it any more.

PHP is naturally tied to Apache. Running it separately, or with any other webserver, requires just as much mucking around (possibly more) as deploying any other language.

php.ini applies to every PHP application run anywhere. There is only one php.ini file, and it applies globally; if you're on a shared server and need to change it, or if you run two applications that need different settings, you're out of luck; you have to apply the union of all necessary settings and pare them down from inside the apps themselves using ini_set or in Apache's configuration file or in .htaccess. If you can. Also wow that is a lot of places you need to check to figure out how a setting is getting its value.

Similarly, there is no easy way to "insulate" a PHP application and its dependencies from the rest of a system. Running two applications that require different versions of a library, or even PHP itself? Start by building a second copy of Apache.

The "bunch of files" approach, besides making routing a huge pain in the ass, also means you have to carefully whitelist or blacklist what stuff is actually available, because your URL hierarchy is also your entire code tree. Configuration files and other "partials" need C-like guards to prevent them from being loaded directly. Version control noise (e.g., .svn) needs protecting. With mod_php, everything on your filesystem is a potential entry point; with an app server, there's only one entry point, and only the URL controls whether it's invoked.

You can't seamlessly upgrade a bunch of files that run CGI-style, unless you want crashes and undefined behavior as users hit your site halfway through the upgrade.

Despite how "simple" it is to configure Apache to run PHP, there are some subtle traps even there. While the PHP docs suggest using SetHandler to make .php files run as PHP, AddHandler appears to work just as well, and in fact Google gives me twice as many results for it. Here's the problem.
When you use AddHandler, you are telling Apache that "execute this as php" is one possible way to handle .php files. But! Apache doesn't have the same idea of file extensions that every human being on the planet does. It's designed to support, say, index.html.en being recognized as both English and HTML. To Apache, a file can have any number of file extensions simultaneously.

Imagine you have a file upload form that dumps files into some public directory. To make sure nobody uploads PHP files, you just check that they don't have a .php extension. All an attacker has to do is upload a file named foo.php.txt; your uploader won't see a problem, but Apache will recognize it as PHP, and it will happily execute.

The problem here isn't "using the original filename" or "not validating better"; the problem is that your web server is configured to run any old code it runs across-precisely the same property that makes PHP "easy to deploy". CGI required +x, which was something, but PHP doesn't even do that. And this is no theoretical problem; I've found multiple live sites with this issue.

Missing features

I consider all of these to be varying levels of critical for building a Web application. It seems reasonable that PHP, with its major selling point being that it's a "Web language", ought to have some of them.

No template system. There's PHP itself, but nothing that acts as a big interpolator rather than a program.

No XSS filter. No, "remember to use htmlspecialchars" is not an XSS filter. This is.

No CSRF protection. You get to do it yourself.

No generic standard database API. Stuff like PDO has to wrap every individual database's API to abstract the differences away.

No routing. Your website looks exactly like your filesystem. Many developers have been tricked into thinking mod_rewrite (and .htaccess in general) is an acceptable substitute.

No authentication or authorization.

No dev server. ("Fixed" in 5.4. Led to the Content-Length vuln below. Also, you have to port all your rewrite rules to a PHP wrapper thing, because there's no routing.)

No interactive debugging.

No coherent deployment mechanism; only "copy all these files to the server".

Security

Language boundaries

PHP's poor security reputation is largely because it will take arbitrary data from one language and dump it into another. This is a bad idea. "<script>" may not mean anything in SQL, but it sure does in HTML.

Making this worse is the common cry for "sanitizing your inputs". That's completely wrong; you can't wave a magic wand to make a chunk of data inherently "clean". What you need to do is speak the language: use placeholders with SQL, use argument lists when spawning processes, etc.

PHP outright encourages "sanitizing": there's an entire data filtering extension for doing it.

All the addslashes, stripslashes, and other slashes-related nonsense are red herrings that don't help anything.

There is, as far as I can tell, no way to safely spawn a process. You can ONLY execute a string via the shell. Your options are to escape like crazy and hope the default shell uses the right escaping, or pcntl_fork and pcntl_exec manually.

Both escapeshellcmd and escapeshellarg exist with roughly similar descriptions. Note that on Windows, escapeshellarg does not work (because it assumes Bourne shell semantics), and escapeshellcmd just replaces a bunch of punctuation with spaces because nobody can figure out Windows cmd escaping (which may silently wreck whatever you're trying to do).

The original built-in MySQL bindings, still widely-used, have no way to create prepared statements.

To this day, the PHP documentation on SQL injection recommends batty practices like type-checking, using sprintf and is_numeric, manually using mysql_real_escape_string everywhere, or manually using addslashes everywhere (which "may be useful"!). There is no mention of PDO or paramaterization, except in the user comments. I complained about this very specifically to a PHP dev at least two years ago, he was alarmed, and the page has never changed.

Insecure-by-default

register_globals. It's been off by default for a while by now, and it's gone in 5.4. I don't care. This is an embarrassment.

include accepting HTTP URLs. Likewise.

Magic quotes. So close to secure-by-default, and yet so far from understanding the concept at all. And, likewise.

Core

The PHP interpreter itself has had some fascinating security problems.

In 2007 the interpreter had an integer overflow vulnerability. The fix started with if (size > INT_MAX) return NULL; and went downhill from there. (For those not down with the C: INT_MAX is the biggest integer that will fit in a variable, ever. I hope you can figure out the rest from there.)

More recently, PHP 5.3.7 managed to include a crypt() function that would, in effect, let anyone log in with any password.

PHP 5.4's dev server is vulnerable to a denial of service, because it takes the Content-Length header (which anyone can set to anything) and tries to allocate that much memory. This is a bad idea.

I could dig up more but the point isn't that there are X many exploits-software has bugs, it happens, whatever. The nature of these is horrifying. And I didn't seek these out; they just happened to land on my doorstep in the last few months.

Conclusion

Some commentary has rightfully pointed out that I don't have a conclusion. And, well, I don't have a conclusion. If you got all the way down here, I assumed you agreed with me before you started :)

If you only know PHP and you're curious to learn something else, give the Python tutorial a whirl and try Flask for the web stuff. (I'm not a huge fan of its template language, but it does the job.) It breaks apart the pieces of your app, but they're still the same pieces and should look familiar enough. I might write a real post about this later; a whirlwind introduction to an entire language and web stack doesn't belong down here.

Later or for bigger projects you may want Pyramid, which is medium-level, or Django, which is a complex monstrosity that works well for building sites like Django's.

If you're not a developer at all but still read this for some reason, I will not be happy until everyone on the planet has gone through Learn Python The Hard Way so go do that.

There's also Ruby with Rails and some competitors I've never used, and Perl is still alive and kicking with Catalyst. Read things, learn things, build things, go nuts.

Credits

Thanks to the following for inspiration:

PHP turtles

PHP sadness

PHP WTF

YourLanguageSucks

PHP in contrast to Perl

Pi's dense, angry, inspirational rant

PHP is not an acceptable COBOL

the PHP documentation

a ton of PHP fanatics and PHP counter-fanatics

and, of course, Rasmus Lerdorf for his wild misunderstanding of most of Perl

Let me know if you have any additions, or if I'm (factually!) wrong about something.

Posted by Eevee Apr 9th, 2012 php, programming

[Aug 27, 2011] Digg PHP's Scalability and Performance

Apr 10, 2006 | O'Reilly ONLamp Blog

Several weeks ago there was a notable bit of controversy over some comments made by James Gosling, father of the Java programming language. He has since addressed the flame war that erupted, but the whole ordeal got me thinking seriously about PHP and its scalability and performance abilities compared to Java. I knew that several hugely popular Web 2.0 applications were written in scripting languages like PHP, so I contacted Owen Byrne - Senior Software Engineer at digg.com to learn how he addressed any problems they encountered during their meteoric growth. This article addresses the all-to-common false assumptions about the cost of scalability and performance in PHP applications.

At the time Gosling's comments were made, I was working on tuning and optimizing the source code and server configuration for the launch of Jobby, a Web 2.0 resume tracking application written using the WASP PHP framework. I really hadn't done any substantial research on how to best optimize PHP applications at the time. My background is heavy in the architecture and development of highly scalable applications in Java, but I realized there were enough substantial differences between Java and PHP to cause me concern. In my experience, it was certainly faster to develop web applications in languages like PHP; but I was curious as to how much of that time savings might be lost to performance tuning and scaling costs. What I found was both encouraging and surprising.

What are Performance and Scalability?

Before I go on, I want to make sure the ideas of performance and scalability are understood. Performance is measured by the output behavior of the application. In other words, performance is whether or not the app is fast. A good performing web application is expected to render a page in around or under 1 second (depending on the complexity of the page, of course). Scalability is the ability of the application to maintain good performance under heavy load with the addition of resources. For example, as the popularity of a web application grows, it can be called scalable if you can maintain good performance metrics by simply making small hardware additions. With that in mind, I wondered how PHP would perform under heavy load, and whether it would scale well compared with Java.

Hardware Cost

My first concern was raw horsepower. Executing scripting language code is more hardware intensive because to the code isn't compiled. The hardware we had available for the launch of Jobby was a single hosted Linux server with a 2GHz processor and 1GB of RAM. On this single modest server I was going to have to run both Apache 2 and MySQL. Previous applications I had worked on in Java had been deployed on 10-20 application servers with at least 2 dedicated, massively parallel, ultra expensive database servers. Of course, these applications handled traffic in the millions of hits per month.

To get a better idea of what was in store for a heavily loaded PHP application, I set up an interview with Owen Byrne, cofounder and Senior Software Engineer at digg.com. From talking with Owen I learned digg.com gets on the order of 200 million page views per month, and they're able to handle it with only 3 web servers and 8 small database servers (I'll discuss the reason for so many database servers in the next section). Even better news was that they were able to handle their first year's worth of growth on a single hosted server like the one I was using. My hardware worries were relieved. The hardware requirements to run high-traffic PHP applications didn't seem to be more costly than for Java.

Database Cost

Next I was worried about database costs. The enterprise Java applications I had worked on were powered by expensive database software like Oracle, Informix, and DB2. I had decided early on to use MySQL for my database, which is of course free. I wondered whether the simplicity of MySQL would be a liability when it came to trying to squeeze the last bit of performance out of the database. MySQL has had a reputation for being slow in the past, but most of that seems to have come from sub-optimal configuration and the overuse of MyISAM tables. Owen confirmed that the use of InnoDB for tables for read/write data makes a massive performance difference.

There are some scalability issues with MySQL, one being the need for large amounts of slave databases. However, these issues are decidedly not PHP related, and are being addressed in future versions of MySQL. It could be argued that even with the large amount of slave databases that are needed, the hardware required to support them is less expensive than the 8+ CPU boxes that typically power large Oracle or DB2 databases. The database requirements to run massive PHP applications still weren't more costly than for Java.

PHP Coding Cost

Lastly, and most importantly, I was worried about scalability and performance costs directly attributed to the PHP language itself. During my conversation with Owen I asked him if there were any performance or scalability problems he encountered that were related to having chosen to write the application in PHP. A bit to my surprise, he responded by saying, "none of the scaling challenges we faced had anything to do with PHP," and that "the biggest issues faced were database related." He even added, "in fact, we found that the lightweight nature of PHP allowed us to easily move processing tasks from the database to PHP in order to deal with that problem." Owen mentioned they use the APC PHP accelerator platform as well as MCache to lighten their database load. Still, I was skeptical. I had written Jobby entirely in PHP 5 using a framework which uses a highly object oriented MVC architecture to provide application development scalability. How would this hold up to large amounts of traffic?

My worries were largely related to the PHP engine having to effectively parse and interpret every included class on each page load. I discovered this was just my misunderstanding of the best way to configure a PHP server. After doing some research, I found that by using a combination of Apache 2's worker threads, FastCGI, and a PHP accelerator, this was no longer a problem. Any class or script loading overhead was only encountered on the first page load. Subsequent page loads were of comparative performance to a typical Java application. Making these configuration changes were trivial and generated massive performance gains. With regard to scalability and performance, PHP itself, even PHP 5 with heavy OO, was not more costly than Java.

Conclusion

Jobby was launched successfully on its single modest server and, thanks to links from Ajaxian and TechCrunch, went on to happily survive hundreds of thousands of hits in a single week. Assuming I applied all of my new found PHP tuning knowledge correctly, the application should be able to handle much more load on its current hardware.

Digg is in the process of preparing to scale to 10 times current load. I asked Owen Byrne if that meant an increase in headcount and he said that wasn't necessary. The only real change they identified was a switch to a different database platform. There doesn't seem to be any additional manpower cost to PHP scalability either.

It turns out that it really is fast and cheap to develop applications in PHP. Most scaling and performance challenges are almost always related to the data layer, and are common across all language platforms. Even as a self-proclaimed PHP evangelist, I was very startled to find out that all of the theories I was subscribing to were true. There is simply no truth to the idea that Java is better than scripting languages at writing scalable web applications. I won't go as far as to say that PHP is better than Java, because it is never that simple. However it just isn't true to say that PHP doesn't scale, and with the rise of Web 2.0, sites like Digg, Flickr, and even Jobby are proving that large scale applications can be rapidly built and maintained on-the-cheap, by one or two developers.

Further Reading

Scalability:

Why PHP Scales

Large Scale PHP

The PHP Scalability Myth

The J2EE guy still doesn't get PHP

Performance:

High performance PHP

A subjective analysis of two high-level, object-oriented languages

Making the Case for PHP at Yahoo!

PHPXref 0.7.1

PHPXref is a Perl script that cross-references classes, functions, variables, and SQL tables used in a PHP-based Web site and generates simple HTML output designed to make browsing through code easy.

Slashdot PHP 6 and What to Expect

March 14 2006

kestasjk (933987)

Lack of backwards compatibility (Score:5, Interesting)

phpBB, vBulletin, mysqladmin, postnuke, phpDiplomacy [kuliukas.com] (shameless self promotion), etc, etc; none will work until they've been ported to the new PHP5 OO model, and once they've been ported they won't work on PHP4.

They should leave in backwards compatibility for the class based OO model which <PHP5 uses. Once they bring out PHP6, PHP5 will be the only version which runs new and legacy PHP scripts, so PHP5 will clearly become the standard for a long time.

I'm a big fan of PHP, but with so many apps (e.g. my university's timetabling app) still in PHP3, all the rest in PHP4, both becoming obsolete, changes to the API, even changes to what's allowed within the same version [phpbb.com]; I'm starting to wonder if I should have focused on a more stable language like python or perl instead.

CHaN_316 (696929)

Namespace (Score:4, Insightful)

It'd be great if variables, functions, classes, and constants could be defined in their own namespaces. For really big projects, it's too easy for names to collide in the global namespace. An annoying workaround has always been to make names unique by prepending them with something.

What's new in PHP V5.3, Part 5 Upgrading from PHP V5.2

Feb 24, 2009

Syntax changes

Additions to the language, with namespaces and closures (discussed in Part 2 and Part 3), have added more reserved words. Starting in PHP V5.3, namespace can no longer be used as an identifier. The closure class is now a reserved class, but it is still a valid identifier. Listing 1 shows examples of statements that no longer work in PHP V5.3 because of the additional reserved words.

Listing 1. Invalid PHP statements
// the function definition below will throw a fatal error in PHP 5.3, but is perfectly 
// valid in 5.2
function namespace() 
{
....
}

// same with this class definition
class Closure
{
....
}
Support for the goto statement was also added in PHP V5.3. Now goto is a reserved word. goto statements are not common in modern languages (you might remember using them in BASIC), but there are occasionally use cases where they are handy. Listing 2 has an example of how they work.
Listing 2. goto statements in PHP
echo "This text will get outputted";
goto a;

echo "This text will get skipped";

a:
echo "This text will get outputted"; 
One possible use case for gotos is for breaking out of deeply nested loops and if statements. This will make the code much clearer to read.

Changes to functions and methods

Though there are no major changes to functions and methods in PHP V5.3, there are a few enhancements to help with outstanding issues in PHP and to improve performance. This section discusses a few of the more notable changes.

In previous versions of PHP, the array functions atsort, natcasesort, usort, uasort, uksort, array_flip, and array_unique let you pass objects instead of arrays as parameters. The functions then treat the properties of the objects as the array keys and values. This is no longer available in PHP V5.3, so you need to cast the objects to arrays first. Listing 3 shows how to change your code.
Listing 3. Changing code to cast objects to arrays for certain functions
$obj = new stdClass;
$obj->a = '1';
$obj->b = '2';
$obj->c = '3';

print_r(array_flip($obj)); // will NOT work in PHP 5.3, but will in PHP 5.2

print_r(array_flip((array) $obj)); // will work in PHP 5.3 and 5.2
The magic class methods are now much more strictly enforced. The following methods must have public visibility:

__get

__set

__isset

__unset

__call

You can use the new __callStatic() magic method in cases where __call was used in a static context as a workaround for this change. The required arguments for these methods are enforced and must be present with the exception of the __isString() magic method, which accepts no parameters. Listing 4 shows how to use these methods and the required parameters for them.
Listing 4. Using the magic methods
class Foo
{
    public function __get($key) {} // must be public and have one parameter
    public function __set($key,$val) {} // must be public and have two parameters

    public function __toString() {} must be public and have no parameters
}
Several functions that previously were not supported on PHP with Windows are now supported in PHP V5.3. For example, the getopt() function is designed to parse the options for calling a PHP script from the command line. inet_ntop() and inet_pton(), the functions for encoding and decoding Internet addresses, now work under Windows� as well. There are several math functions, such as asinh(), acosh(), atanh(), log1p(), and expm1(), which now have Windows support.

Extension changes

The PHP Extension C Library (PECL), has been the breeding ground for new extensions in PHP. Once an extension is mature and stable and is viewed as a useful function for part of the core distribution, it is often added during major version changes. In this spirit, starting in PHP V5.3, the following extensions are part of the core PHP distribution.

FileInfo

Provides functions that help detect the content type and encoding of a file by looking at certain magic byte character sequences in the file.

intl

A wrapper for the International Components for Unicode (ICU) library, providing functions for unicode and globalization support.

Phar

A PHP archiving tool discussed in Part 4.

mysqlnd

A native PHP driver for MySQL database access that's a replacement for the earlier MySQL and MySQLi extension which leveraged the libmysql library.

SQLite3

A library for using SQLite V3 databases.

When an extension is no longer actively maintained, or is deemed unworthy of distribution with the core PHP distribution, it is often moved to PECL. As part of the shuffling in PHP V5.3, the following extensions have been removed from the core PHP distribution and are maintained as part of PECL.

ncurses

An emulation of curses, which is used to display graphical output on the command line.

fpdf

Handles building and using forms and form data within PDF documents.

dbase

Provides support for reading and writing dbase compatible files.

fbsql

Supports database access for Frontbase database servers.

ming

An open source library that allows you to create Flash 4 animations.

The Sybase extension has been removed entirely and is superseded by the sybase_ct extension. The sybase_ct extension is fully compatible with the former and should be a drop-in replacement. The newer function will use the Sybase client libraries you need to install on your Web server.

Build changes

With the strong focus on refining the build process in PHP V5.3, it's easier to build PHP on all platforms. To maintain consistency between PHP builds and to provide a guaranteed set of components in PHP, the PCRE, Reflection, and SPL extensions can no longer be disabled in the build. You can build distributable PHP applications that use these extensions and are guaranteed that they will be available for use.

A new team took over the PHP Windows build in the last year. Starting in PHP V5.3, the team will provide several improvements for users on Windows. The new builds will target the 586 architecture (Intel� Pentium� or later) and will require Windows 2000/XP or later, removing support for Windows 98/NT and earlier. PHP builds built with Microsoft� Visual Studio� 2008 and builds targeting the x86-64 architecture will be built. They offer improved performance when working with FastCGI on the Microsoft IIS Web server or with Apache built with the same compiler and architecture. The Windows installer is also being improved to better configure PHP with the Microsoft IIS Web server. The team launched a Web site specific to PHP on Windows (see Resources).

.ini changes

An important feature of PHP is that its behavior can be configured using an .ini file. In PHP V5.3, several problematic directives for this file have been removed, such as the zend.ze1_compatibility_mode setting. You now have tremendously improved flexibility when using this file.

There are two major improvements to the php.ini file:
You can have variables within the php.ini file. This is very handy for removing redundancies within the file, and it's easier to update the file if changes are needed. Listing 5 shows an example.
Listing 5. Variables in php.ini file
 
foo = bar 

[section] 
newfoo = ${bar} 
foo and newfoo have the same value.
You can make per-directory and per-site PHP ini settings, similar to making those same settings with the Apache configuration files. The advantage here is that the syntax becomes consistent across all of the various SAPIs PHP can run under. Listing 6 shows how this works.
Listing 6. Per-site and per-directory .ini settings
[PATH=/var/www/site1] 

; directives here only apply to PHP files in the /var/www/site1 directory 

[HOST=www.example.com] 

; directives here only apply to PHP files requested from the www.example.com site.
      
You can also have these .ini directives created in user-specified .ini files, located in the file system itself, in the same way that .htaccess files work under the Apache HTTP Web server. The default name for this file is specified by the user_ini.filename directive. The feature can be disabled by setting this directive to an empty value. Any per-site and per-directory directives cannot be overridden in a user-specified .ini file.

Deprecated items

PHP V5.3 starts officially deprecating older functions that will no longer be available in future versions of PHP. When you use these functions, an E_DEPRECATED error will be emitted. The following functions are deprecated for PHP V5.3:

Ticks (declare(ticks=N) and register_tick_function() ), which were designed to have a function call for every n statements executed by the parser within the declare() block. They're being removed because of numerous breaks in their function and because the feature isn't used very often.

define_syslog_variables(), which initializes all syslog related variables. This function isn't required because the constants it defines are already defined globally. Simply removing this function call should be all that is necessary.

The ereg regular-expression functions. It's recommended that you use the PCRE regular-expression functions instead, since they are much faster and more consistent with regular expressions used in other languages and applications. Support for the ereg functions is being removed so PHP can standardize with one regular-expression engine.

It is recommended that you migrate away from these features with PHP V5.3. Future major PHP releases will drop support for the above items.

Summary

PHP V5.3 has numerous new features and has "cleaned up" several items. There are some backward-compatibility issues. This article provides some guidance for migrating your Web application to work with PHP V5.3. For the latest details regarding PHP V5.3 see the PHP wiki, which has notes on any other changes that might affect your applications.

Resources
Learn

Learn more about closures from Wikipedia.

PHP For Windows is dedicated to supporting PHP on Microsoft Windows. It also supports ports of PHP extensions or features, and provides special builds for the various Windows architectures.

Visit the PHP wiki to learn all about changes to PHP V5.3.

Read "A PHP V5 migration guide" to learn how to migrate code developed in PHP V4 to V5.

"Connecting PHP Applications to Apache Derby" shows you how to install and configure PHP on Windows (some steps are applicable to Linux�).

For a series of developerWorks tutorials on learning to program with PHP, see "Learning PHP, Part 1," Part 2, and Part 3.

Planet PHP is the PHP developer community news source.

The PHP Manual has information about PHP data objects and their capabilities.

Visit Safari Books Online for a wealth of resources for open source technologies.

PHP.net is the central resource for PHP developers.

Check out the "Recommended PHP reading list."

Browse all the PHP content on developerWorks.

Follow developerWorks on Twitter.

Expand your PHP skills by checking out IBM developerWorks' PHP project resources.

To listen to interesting interviews and discussions for software developers, check out developerWorks podcasts.

Using a database with PHP? Check out the Zend Core for IBM, a seamless, out-of-the-box, easy-to-install PHP development and production environment that supports IBM DB2 V9.

Get products and technologies

PHPMyAdmin is a popular PHP application that has been packaged in Phar to use as an example of how easy using Phar archives are.

[Jul 3, 2008] Debugging PHP using Eclipse and PDT

The PHP Development Tools (PDT) plug-in, when installed with Eclipse Europa, gives you that ability to quickly write and debug PHP scripts and pages. PDT supports two debugging tools: XDebug and the Zend Debugger. Learn how to configure PDT for debugging PHP scripts and discover which perspectives you use when taking closer looks at your scripts.

In this tutorial

This tutorial demonstrates how to configure the PHP Development Tools (PDT) plug-in for Eclipse to debug your PHP scripts. It also introduces the perspectives you'll use (namely, PHP Debug) when taking closer looks at your PHP scripts.

After completing this tutorial, you'll be able to set up either XDebug - an open source project that allows you to debug executable scripts and scripts running on a Web server - or the Zend Debugger in Eclipse using the PDT project to develop PHP applications. You'll understand the various parts of the PDT project's PHP Debug perspective and learn how to set up, view, and work with breakpoints. You also learn how to inspect the values of variables as you are stepping through the code, as well as how to debug PHP Web applications on your local server so you can run through your PHP Web application with the debugger.

Prerequisites

To get the most out of this tutorial, you should have done a bit of PHP development. But what matters more is that you've done software development in general. You'll understand the debugging concepts better if you're familiar with debugging any other language. I wrote this to be helpful to those who are fairly new to Eclipse, rather than to those who have been using Eclipse for a while.

System requirements

To complete this tutorial, you need:

Computer running Microsoft� Windows�, Mac OS X, or Linux�

The examples of the php.ini file shown in this tutorial are for Mac OS X and Linux. Because both debuggers require a configuration that tells PHP where the debugger extensions are located, the only noticeable difference - if you're looking for Windows examples - is the path to the debugger extension. Library names end in .so. for Mac OS X and Linux and .dll for Windows; also, paths use a forward slash (/) instead of a backslash (\) as a directory-separator character.

PHP V5.x

Linux users can install PHP using the software package system included in their distribution. OS X, and Windows users can find PHP V5.x at PHP.net.
Note: The examples in this tutorial were written using PHP V5.2.5.

Eclipse V3.3

Again, Linux users have it easy: Eclipse is usually available through the package system included in their distribution. Everyone else can find the Eclipse integrated development environment (IDE) at the Eclipse downloads.

Apache or Microsoft Internet Information Services (IIS) for serving Web applications

You need a Web server installed to run the examples that demonstrate how to debug PHP Web pages on the server. However, if you're interested only in debugging PHP scripts that aren't Web pages, you won't need a Web server. For this tutorial, we have Apache V2 set up as the Web server. If you're using Windows and would rather use IIS, that works, too. This tutorial assumes you have the proper access to write to directories inside the document root of the Web server.

Eclipse PHP Development Tools framework

If you don't already have PHP Development Tools (PDT) installed, you may want to read ahead to the "Overview of the PDT project" section so you can decide whether you want to download and install PDT already bundled with the Zend Debugger. The Eclipse Foundation PDT/Installation wiki is brief, but helpful.

Zend Studio Web Debugger

Download a 30-day trial version of the Zend Studio Web Debugger.

[Jun 20, 2008] BitRock Download Web Stacks

BitRock Web Stacks provide you with the easiest way to install and run the LAMP platform in a variety of Linux distributions. BitRock Web Stacks are free to download and use under the terms of the Apache License 2.0. To learn more about our licensing policies, click here.

You can find up-to-date WAMP, LAMP and MAMP stacks at the BitNami open source website. In addition to those, you will find freely available application stacks for popular open source software such as Joomla!, Drupal, Mediawiki and Roller. Just like BitRock Web Stacks, they include everything you need to run the software and come packaged in a fast, easy to use installer.

BitRock Web Stacks contain several open source tools and libraries. Please be sure that you read and comply with all of the applicable licenses. If you are a MySQL Network subscriber (or would like to purchase a subscription) and want to use a version of LAMPStack that contains the MySQL Certified binaries, please send an email to [email protected].

For further information, including supported platforms, component versions, documentation, and support, please visit our solutions section.

[May 6, 2008] Ortro 1.3.0 by Luca Corbo

PHP based

About: Ortro is a framework for enterprise scheduling and monitoring. It allows you to easily assemble jobs to perform workflows and run existing scripts on remote hosts in a secure way using ssh. It also tests your Web applications, creates simple reports using queries from databases (in HTML, text, CSV, or XLS), emails them, and sends notifications of job results using email, SMS, Tibco Rvd, Tivoli postemsg, or Jabber.

Changes: Key features such as auto-discovery of hosts and import/export tools are now available. The telnet plugin was improved and the mail plugin was updated. The PEAR libraries were updated.

Oracle PHP Developer Center

Installation Guides
Installing Oracle Database 10g Express Edition and Zend Core for Oracle

Installing Apache, PHP, JDeveloper, and the PHP Extension on Linux

Installing PHP and the Oracle 10g Instant Client for Linux and Windows

Installing Oracle, PHP, and Apache on Linux

Installing Oracle, PHP, and Apache on Windows 2000/XP

Set Up Oracle Database 10g and PHP on Mac OS X OTN Installfest Scripts (.txt format):
�Zend Core for Oracle, Apache, PHP5, Oracle JDeveloper 10.1.2, and JDeveloper PHP Extension on RHEL4
� Oracle 10g Release 2, Apache, and PHP5 on RHEL4
� Oracle 10g, Apache, PHP4, and Oracle JDeveloper/PHP Extension on RHEL4
� Oracle 10g, Apache, PHP5, and Oracle JDeveloper/PHP Extension on RHEL4
� Oracle 10g, Apache, PHP4, and Oracle JDeveloper/PHP Extension on SLES9
� Oracle 10g, Apache, PHP5, and Oracle JDeveloper/PHP Extension on SLES9

Oracle Develop 2007 - PHP Presentations

Scale Your PHP Application to Tens of Thousands of Connections

The Way to the Web with PHP and Oracle Database

Recent Oracle+PHP Cookbook Recipes

Creating an Ajax Process Using PHP

Building a Locator with ZIP Data

Creating Oracle-Powered SOAP Services in PHP

Online PayPal Payments with PHP

Adding Google-like Search Operators to Simple Search Boxes

Read More Recipes... | Read other Tech Articles...

Sample Book Chapters

Oracle Database 10g Express Edition PHP Web Programming from Oracle Press

Learning PHP5 from O'Reilly & Associates

PHP Cookbook from O'Reilly & Associates

PHP Programming from O'Reilly & Associates

IBM Redbooks Bringing PHP to Your IBM eServer iSeries Server

January 29, 2003 | IBM

Programming with PHP on the iSeries server
Prerequisites
Installation instructions
Compiling (make)
Testing PHP
Configuring HTTP Server (powered by Apache) to use PHP
Creating a sample database
Limitations
PHP 4.2.2 errata

[Apr 18, 2008] IBM Redbooks Developing PHP Applications for IBM Data Servers

Chapter 1. Technology overview
Chapter 2. Sample scenario description
Chapter 3. Zend installation and configuration
Chapter 4. PHP application development with DB2
Chapter 5. PHP applications with Informix database servers
Chapter 6. Port PHP applications from MySQL V5 to DB2 UDB V8.2
Appendix A. An introduction to Service Data Objects for PHP

[Mar 12, 2008] Tiny Eclipse 3.3.2 by Eric Suen

About: Tiny Eclipse is distribution of Eclipse for development with dynamic languages for the Web, such as JSP, PHP, Ruby, TCL, and Web Services. It features a small download size, the ability to choose the features you want to install, and GUI installers for Win32 and Linux GTK x86.

[Dec 1, 2007] freshmeat.net Project details for PHD Help Desk

PHD Help Desk is software conceived for the registry and follow-up of help desks incidents. Registry of incidents allows classification in two levels (type and subtype), the state of the incident, a description, ticket assignment and priority, historical registry, and an audit. Information can be reported in consultation format, to give reports or export the information for later processing in a database or spreadsheet.
Release focus: Minor feature enhancements

Changes:
Now it's possible attach a file in the users support request web form. Minors changes were made. In the code for modifying a ticket, an SQL statement that was incompatible with MySQL 3.23 was fixed. When you had one ticket opened for modification in one window and then you modified another ticket in another window, the change would incorrectly modify the first ticket although it would show information about the second ticket. PHD now warns you about this situation and prevents the change. All scripts now correctly start with "<?PHP".

[Jul 16, 2007] Zend Developer Zone PHP 101 PHP For the Absolute Beginner

PHP 101 (part 1): Down the Rabbit Hole [July 17, 2004]
An introduction to PHP's variables and operators.
PHP 101 (part 2): Calling All Operators [July 18, 2004]
The rest of the PHP operators (there are many), and simple form processing.

PHP 101 (PART 3): Looping the Loop [July 19, 2004]
Basic control structures explained.

PHP 101 (PART 4): The Food Factor [July 20, 2004]
Arrays, PHP array functions, and what it all means.

PHP 101 (PART 5): Rank and File [July 21, 2004]
Everything you're ever likely to need to know about dealing with external files from a PHP script.

PHP 101 (PART 6): Functionally Yours [July 28, 2004]
All about functions, arguments, passing by reference, globals and scope.

PHP 101 (PART 7): The Bear Necessities [August 07, 2004]
A gentle introduction to object oriented programming in PHP 4 and PHP 5.

PHP 101 (PART 8): Databases and Other Animals [August 31, 2004]
All about connecting to a MySQL database from PHP, using the mysql or mysqli extensions.

PHP 101 (PART 9): SQLite My Fire! [September 16, 2004]
Introducing another database: SQLite.

PHP 101 (part 10): A Session In The Cookie Jar [October 3, 2004]
Sessions and cookies � how to keep track of visitors to your site.

Creating a Code Search Engine with PHP and MySQL

I'm just a few days away from launching a comprehensive support website for my book, "Beginning PHP and MySQL 5, Second Edition", and among other features, have built a search engine for sifting through the more than 500 code snippets found throughout the book. This was an interesting exercise because it involves a number of storing a fairly significant amount of text within a MySQL database, using MySQL's full-text search facility, and devising an effective way to extract and display the code in the browser.

In this article I'll offer a simplified version of this search engine, introducing you to some compelling PHP and MySQL features along the way. You might adopt what you learn towards building your own search engine, or towards other applications.

The Database Schema

Just a single table is required for the engine's operation. The table, code, serves as the code repository. Each example is stored along with a suitable title and the chapter number in which it appears. Because the search engine should retrieve examples based on keywords found in the example title or in the code itself, a FULLTEXT index has been added for these columns. Because the table contents will rarely change beyond the occasional bug fix, its backed by the read-optimized MyISAM storage engine. The table follows:
CREATE TABLE code (
 id SMALLINT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
 title VARCHAR(50) NOT NULL,
 chapter TINYINT UNSIGNED NOT NULL,
 code TEXT NOT NULL,
 FULLTEXT (title,code)
) TYPE = MYISAM;

[Nov 14, 2006] Fantastico -- LAMP application setup for idiots by Steven J. Vaughan-Nichols

Feb. 22, 2006 (Linux-watch.com). Do you want to use PHP-based programs on a hosted Web server, but you don't want to go through the hassle of setting up MySQL, PHP, and Apache so that they're in perfect alignment to run your blog, CMS (content management system), or photo gallery? If that's you, you need to find a Web host that uses Netenberg's Fantastico De Luxe.
This Linux-based program enables Web host companies to offer you a menu of popular PHP-based programs for near-instant installation.

For example, with CMSs alone, Fantastico will let you install the latest editions of:

Drupal (4.6.5)
Geeklog (1.3.11sr1)
Joomla! (1.0.7)
Mambo Open Source
PHP-Nuke (7.8)
phpWCMS (1.1-RC4 Rev. A)
phpWebSite (0.10.2)
Post-Nuke (0.760)
Siteframe (3.1.9)
Typo3 (3.8.0)
Xoops (2.0.13.1)
If it's a PHP-based, open-source Web application, chances are Fantastico can install it for you. It's not just for PHP programs, though. Fantastico can also install such programs as PerlDesk, the Web-based commercial help desk program.
Many Web host companies offer Fantastico as a service. I haven't had enough time or experience with them to recommend one over the other. Hosting Review, however, does a decent job of evaluating Web hosting companies and its list of the top eight, because they couldn't find ten, Web hosting businesses that deploy Fantastico is a useful place to start.

When choosing a Fantastico-enabled host, you should make sure the company is using a current version of Fantastico. Older versions abound, and they do not install the latest PHP programs.

You should also keep in mind that Fantastico is not going to get you any kind of fine control over your installation. What it will do, though, is set up the basic LAMP (Linux, Apache, MySQL, PHP) framework for your particular application to work.

This, as any of you who've followed my adventures in setting up Drupal by hand, is not insignificant.

Now, some might say, "Real men do it all by hand." To which, I can only say, "Real men don't have time to do it all by hand sometimes."

That's the situation I faced once I finally got Drupal and my test Web site up and running on my local SUSE 10 system. I decided that I shouldn't tempt BellSouth into shutting down my consumer DSL connection by running a Web site off it. So, my next step was to look for a Web hosting site where I could clone over my test site without having to go through the hassle of reintegrating yet another LAMP stack to work with Drupal.

It was during that search that I ran into Fantastico. And, it was fantastic.

Instead of spending hours working out how to get Drupal running with Red Hat Enterprise Linux 4, as opposed to SUSE Linux 10, MySQL 4.0.25 instead of MySQL 4.1.13, Apache 1.3.34 in place of Apache 2.0.54, and never least, PHP 4.4.1 in place of PHP 4.4.0-6, my system was set up in less than a minute.

Now, you may think that all those slightly different versions really wouldn't have made much of a difference, but you'd be wrong. Those seemingly subtle differences can make your development life miserable.

If I can have a script do all the pain-in-the-rump tweaking work for me, that's just fine in my book.

After all, even after Fantastico does its work, I still have to face such amusements as restoring a MySQL 4.1.13-based database schema to a MySQL 4.0.25 DBMS. They are not, in case you didn't know, automatically compatible.

Make no mistake about it, though. Although Fantastico makes setting up a LAMP application a lot easier, it doesn't completely spare you from all the hard work of getting your LAMP program working properly.

Still, in a hosted environment where your access to system resources are far more limited than they are on your own system, anything that makes the initial setup easier is likely to save you many hours of work. For that reason alone, whenever I set up a Web site on a hosted system in the future, the first thing I'm going to look for is a hosting company that includes Fantastico in its offerings. It's that important.

[Oct 29, 2006] A PHP V5 migration guide by Jack D. Herrington

With the new language features of PHP V5, you can significantly improve your code's maintainability and stability. Learn how to migrate code developed in PHP V4 to V5 while taking advantage of these new features.

PHP V5 is a quantum step up from V4. The new language features make building reliable and maintaining class libraries much easier. In addition, the reworking of the standard libraries helped bring PHP more in line with its cousin Web languages, such as the Java� programming language. Take a tour through some of PHP's new object-oriented features and learn how to migrate existing PHP V4 code into V5.

First, a bit about the new language features and how PHP's creators have changed the approach to objects from PHP V4. The idea with V5 was to create an industrial-strength language for Web application development. That meant understanding the limitations of PHP V4, then pulling known good language constructs from other languages (such as the Java, C#, C++, Ruby, and Perl languages) and incorporating them into PHP.

The first and most important addition was access protection for methods and instance variables on classes -- the public, protected, and private keywords. This addition allows class designers to retain control over the internals of their classes while expressing to the client of the class what he should or should not touch.

In PHP V4, everything was public. In PHP V5, class designers can say what is externally visible (public) and what is visible only internally to the class (private) or to descendants of the class (protected). Without these access controls, working on code in large groups or distributing code as libraries was hindered because consumers of those classes could easily use the wrong methods or access what should have been private member variables.

Another big addition were the keywords interface and abstract, which allow for contract programming. Contract programming means that one class provides a contract to another -- in other words: "Here is what I will do, and you don't need to know how it's done." Any class that implements that interface agrees to the contract. Any consumer of the interface agrees to use only the methods specified in the interface. The abstract keyword makes using interfaces a lot easier, as I show later.

These primary two features -- access control and contract programming -- allow for much larger teams of coders to work on much larger code bases more smoothly. They also allow IDEs to provide a much richer set of language intelligence features. Although this article covers several migration issues, I also spend a lot of time showing how to use these new key language features.

[Oct 29, 2006] freshmeat.net Project details for doxygen

Dimitri van Heesch

doxygen 1.5.1

About: Doxygen is a cross-platform, JavaDoc-like documentation system for C++, C, Objective-C, C#, Java, IDL, Python, and PHP. Doxygen can be used to generate an on-line class browser (in HTML) and/or an off-line reference manual (in LaTeX or RTF) from a set of source files. Doxygen can also be configured to extract the code-structure from undocumented source files. This includes dependency graphs, class diagrams and hyperlinked source code. This type of information can be very useful to quickly find your way in large source distributions.

Changes: This release fixes a number of bugs that could cause it to crash under certain conditions or produce invalid output.

[Oct 24, 2006] Microsoft Hosts Project to Run PHP on .Net

PHP is slow unless you buy an accelerator. Microsoft might change that

Extending its support for scripting and dynamic languages, Microsoft is hosting a project on its CodePlex site to deliver a PHP language compiler for the .Net Framework.
Known as Phalanger, the project reached Version 2.0 Beta 2 on July 30.

The primary goal of the project, released under Microsoft Shared Source Permissive License, is to enable full functionality of existing PHP scripts on .Net without any modification, Microsoft said.

Unlike the original PHP interpreter, Phalanger compiles scripts into MSIL (Microsoft Intermediate Language).

Phalanger offers Web application developers the ability to leverage both the ease-of-use and effectiveness of the PHP language and the power and richness of the .Net platform, the company said.

And the compiler developers can deploy and run existing PHP code on an ASP.Net Web server and develop cross-platform extensions to that code.

Meanwhile, the object model in Phalanger is compatible with PHP 5.0, and it lets developers combine PHP objects with .Net ones.

[Oct 24, 2006] Microsoft's IIS 7 will aid PHP developers' Windows deployments

At the Microsoft Web Developer's Summit, held in Redmond, Wash., last week, Microsoft announced their efforts to improve PHP's stability and performance on the Windows platform.

During a session wherein key Microsoft developers met with a group of PHP-minded Web developers, IIS product unit manager Bill Staples and program manager Mike Volodarsky discussed IIS 7 and their efforts to improve PHP's performance on the Windows platform.

Staples recapped the numerous security-related enhancements poured into IIS 6 in light of the server's notorious track record of high-profile security gaffes, including the likes of Nimda and Code Red. Then, he underscored the effort's success, noting that there has been no need for any critical IIS security patches in more than three years.

The discussion soon moved on to PHP's relationship with the Windows platform. Staples and Volodarsky acknowledged that many PHP developers build applications on Windows -- generally running Apache's Windows port -- but deploy on Linux. They said new features will support developers who wish to take this path. This means inclusion of features long available to Apache, such as URL rewriting, and an open extensibility model to encourage community-driven development.

Staples and Volodarsky also addressed the historical stability issues surrounding running PHP on IIS, due to incompability issues pertinent to IIS' multithreaded environment. Using CGI improves stability, but comes at a cost of significant performance degradation. Volodarsky noted the team's interest in improving on both fronts, mentioning they were exploring a FastCGI-based solution, but nothing concrete has yet come of it.

While it's clear much work remains before IIS and PHP will work efficiently in a production environment, those wishing to simply experiment with running PHP on IIS will be pleased to know the ISAPI configuration process has been greatly simplified. Staples recently published a blog entry highlighting the required steps.

[Oct 24, 2006] The ionCube PHP Accelerator Home

Yahoo! have been testing PHPA for some months whilst exploring PHP caching solutions, and have selected PHPA as a caching solution for PHP projects.

[Sep 25, 2006] Microsoft's IIS 7 will aid PHP developers' Linux deployments

At the Microsoft Web Developer's Summit, held in Redmond, Wash., last week, Microsoft announced their efforts to improve PHP's stability and performance on the Windows platform.

During a session wherein key Microsoft developers met with a group of PHP-minded Web developers, IIS product unit manager Bill Staples and program manager Mike Volodarsky discussed IIS 7 and their efforts to improve PHP's performance on the Windows platform.

Staples recapped the numerous security-related enhancements poured into IIS 6 in light of the server's notorious track record of high-profile security gaffes, including the likes of Nimda and Code Red. Then, he underscored the effort's success, noting that there has been no need for any critical IIS security patches in more than three years.

The discussion soon moved on to PHP's relationship with the Windows platform. Staples and Volodarsky acknowledged that many PHP developers build applications on Windows -- generally running Apache's Windows port -- but deploy on Linux. They said new features will support developers who wish to take this path. This means inclusion of features long available to Apache, such as URL rewriting, and an open extensibility model to encourage community-driven development.

Staples and Volodarsky also addressed the historical stability issues surrounding running PHP on IIS, due to incompability issues pertinent to IIS' multithreaded environment. Using CGI improves stability, but comes at a cost of significant performance degradation. Volodarsky noted the team's interest in improving on both fronts, mentioning they were exploring a FastCGI-based solution, but nothing concrete has yet come of it.

While it's clear much work remains before IIS and PHP will work efficiently in a production environment, those wishing to simply experiment with running PHP on IIS will be pleased to know the ISAPI configuration process has been greatly simplified. Staples recently published a blog entry highlighting the required steps.

[Aug 26, 2006] Cooltools Cool Tools at OpenSPARC T1 Better late then never: Sun started to provides precompiled (with Sun Studio) OSS packages:

CSQamp. This package includes Apache HTTP Server 2.0.58, MySQL 5.0.22 and PHP 5.1.4 built to work together. Apache httpd is built with MPM pre-fork and modules to support PHP, SSL and Perl. PHP has support for MySQL. Note, to work with PHP, MySQL included in this package is a 32-bit version. For the database server, we recommend you install the CSQmysql package which is a 64-bit version, allowing the use of larger caches to deliver improved performance for large databases. Note that the CSQamp package will work with the CSQmysql database server.
CSQmysql. This package includes a 64bit version of MySQL 5.0.22 and is built with innodb. See the README file in /usr/local/mysql for details.
CSQperl. This package includes Perl 5.8.8. Note that Solaris 10 ships with the same version of Perl. However, CSQperl is compiled with optimization and the Sun Studio compiler and will provide better performance. To use this version of perl, rather than the default one, include /usr/local/bin in your PATH before /usr/bin.
CSQphp. This package provides a stand-alone installation of PHP 5.1.4 and installs in /usr/local/php_fastcgi. This PHP can also be used via FastCGI from any other web server. This package should not be confused with the version of PHP in CSQamp - that version installs in /usr/local/php and is only for use with Apache HTTP Server. For instance, there is no 'php' executable in CSQamp.
CSQsquid. This package includes Squid 2.5.STABLE14 Web Proxy Cache. Squid is a single-threaded application and as such does not scale well on SMP platforms. You may need to run multiple instances to achieve scalability.
CSQtomcat. This package includes Apache Tomcat 5.5.17 which is a pure Java application. It is provided for convenience as it is no different from the one on tomcat.apache.org.

[Jun 19, 2006] Enterprise Systems IBM's Embarks on SOA Blitz

Touts SOA-friendly PHP Integration Kit
Also last week, IBM announced a new PHP integration kit for its WebSphere Application Server (WAS) Community Edition (CE). IBM officials say the new kit-which is available as a free download on its AlphaWorks Web site-will help customers build PHP-based application front-ends using Big Blue's Apache-based application server, WAS CE.

IBM representatives took pains to spin the PHP kit as an SOA-friendly offering, but the reality, officials acknowledge, is that customers can and will tap the kit in a huge variety of different scenarios.

"What it'll allow a developer to do is basically build a J2EE application that includes PHP, so that introduces the opportunity to use PHP for what it's good for, for building Web front ends and simple logic. By making the integration kit available, we're presenting that as an alternative for people building J2EE applications with WAS CE," says Paul Buck, director of gluecode development with IBM.

Buck says PHP is an open-source scripting language that's ideal for building lightweight applications, particularly as front-ends for J2EE app servers. The new kit helps improve the interoperability between the open source PHP runtime and the WAS CE app server: "The PHP run-time that's generally used is what's picked up at php.net-it's all open-source technology, but with the integration into WebSphere, you can actually use WebSphere to serve up the PHP requests, so with the integration kit, as the requests come in to WebSphere, it will know exactly what to do with it and will dispatch it off to the PHP runtime."

As far as service-enablement is concerned, Buck alludes to skyrocketing PHP usage-some estimates put the number of PHP-enabled Web sites at 20 million-and suggests the technology provides a fast and extensible way to expose data sources. "PHP is really good for Web front-ends. That's really where it cut its teeth on the Web, with building Web front-ends to access data, to collect data, to present user interfaces to update back end systems."

It's likely IBM will provide PHP integration for the pay-for-use version of WebSphere, too, Buck says.

WAS CE is a lightweight J2EE application server that's based on the Apache Software Foundation's Geronimo technology. "You can download it, it's free, [and] the license you get allows you to use it as a commercial application server, but there's no support. If you want support, then we sell three levels of service agreements," he notes. "The service agreements are per-server, and for server that's a system that includes up to four CPUs."

[May 17, 2006] The Idea Basket " Blog Archive " Winning the PHP 5 Framework Wars

The latest stats for PHP market share are in from Nexen.net, and (assuming they're reasonably accurate) this does not bode well for PHP 5. After nearly two years since PHP 5.0 was released (back in July of 2004), the PHP 5.x series commands a whopping�7.2% of the PHP market. That means that PHP 4.x is still at 92.8% marketshare! Furthermore, according to the Nexen.net survey, only 34.5% of PHP 5 servers are running PHP 5.1.x which contains crucial new features and is a far more solid platform than any of the 5.0.x builds.

[Apr 13, 2006] 2006 April Chovy's Blog

Interview Question:

If PHP could PHP a PHP page, how much PHP would a PHP page take to PHP a PHP page?

Related Posts

PHP Database Programming Mistakes - There's a good article from IBM about the five common

FireFox Extensions - Here's my list of FireFox extensions:Web Developer - excellent toolbar

[Feb 1, 2006] AMPS for Solaris 10 AMPS (Apache MySQL PHP SSL) for Solaris 10 by Mel Lester Jr. ([email protected]) Version: 1.01 January 25, 2006

The strategy is to utilize as much of the Open Source and other free software bundled with Solaris 10 as possible and integrate Apache2, MySQL, PHP and SSL in a environment that can take full advantage of Solaris 10 zones, resource management and highly scaleable, secure System Administration.

A Configure and Test Start Apache2:

M Configure and Start MySQL:

P Download and Configure PHP:

S Create a SSL Encryption Key and Certificate:

[Jan 22, 2006] Slashdot Taking the Sting Out of PHP 5 Programming

bfioca writes "Where are the all-in-one PHP frameworks that make building well-factored and maintainable applications as easy as building simple sites? O'Reilly ONLamp's recent article Simplify PHP Development with WASP shows how to make a simple database-backed site with WASP in just a few lines of code. Other PHP 5 frameworks such as symfony and PRADO have been getting a lot of recent attention as well."
Using a Framework for YOUR applications!?
by Archi87 (946032) on Sunday January 22, @06:42PM (#14534794)
If you simply want a site with some 0815 stuff (like a Guestbook, News, Articles, Photogallerie) use PHP-Nuke [phpnuke.org] and try to create you're own template (or ask a friend to do it for free).
If you want to create anything else (like a corporate site with support system [ticketbased], shop [enduser and reseller], productinfo,... or a browserbased) do it yourself or have a company done it ;-)

And if you really want to stick to a framework - create your own framework :D

Anonymous Coward on Sunday January 22, @05:59PM (#14534612)
Give me a break, depending on such things is terribly bad for maintainable code. Exactly the opposite of the billing given above. Will code written with it be compatible with PHP 6? How long after PHP 6's release will such tools be made compatible? If you need tools to simplify php coding, you might as well just forget it.
If you want a quality product, there are no shortcuts. There is no such thing as a free lunch.

A big thumbsdown on this kind of crap. "Sting" to PHP 5 programming? Get real.

Re:Bogus

(Score:4, Insightful)
by afd8856 (700296) on Sunday January 22, @06:20PM (#14534702)
You are either ignorant to what a real open source framework would represent (limit code reinvention, benefit from community effort, etc) or are not in the target group of such a framework (maybe you work for a big company that has a large programming team, who knows).
Either way, I can tell you that, from my personal experience, learning and adopting a framework in your work can have a lot of benefits, for me, as a small custom business solutions provider.

Missing the point!
(Score:1, Insightful)

by Anonymous Coward on Sunday January 22, @07:12PM (#14534936)

By demonstrating that it is possible to create and use complicated, "enterprise-class" frameworks effectively in PHP 5, WASP will help more developers make the switch.

Complicated? I didn't realize that complicated frameworks were the pinnacle of modern software development. Here's a newsflash: PHP is popular not because of its rigid structure, nor the availability of misguided "frameworks", but because it allows people to solve problems in a flexible way with little overhead. Yes, a lot of people take it too far in this direction and turn their code into a disaster area, but others manage to build maintainable, useful apps without obsessing over whether or not their program fits into a particular "model". In addition, future maintainers of these apps won't have to read manuals about how to use the framework of the day to make changes. Strict interpretations of pseudo-standards or the use of mind-bending frameworks do not help to develop applications faster, or even better.

I wonder how many "enterprise-class" applications fall flat on their faces because the frameworks on which they are built are not flexible enough to support what their users really need. I know it's happened where I work, and the answer "oh, the framework doesn't support that" led to the success of other projects that came out of nowhere and took hold because they met the demands of users as opposed to the technical demands of project managers. In the real world, a simple PHP app may very well push an "enterprise-class" and "three-tier" monolith out of its way if it does what the users want.
I also rolled my own farmework and...
by AnthongRedbeard (948052) on Sunday January 22, @08:05PM (#14535166)
I have my own framework I've used for several years now and slowly upgraded. I enjoyed writing it because it forced me to learn the principles of what all the other frameworks were doing. I couldn't understand why people wrote frameworks the way they did until I ran into the same situation. However, I made some significant apps with my framework that companies are using and I found myself writing lots of documentation on them and brushing up the comments... It would have been great if I used published and documented framework just so I wouldn't have to do the tedious stuff for other people to ever maintain it.

a framework is NOT a shortcut (or a CMS!)

(Score:4, Insightful)

by webwright (910240) on Sunday January 22, @08:17PM (#14535222)
I tear my eyes out everytime someone calls a framework a "shortcut". Usually they follow it by "There's no substitute for good coders writing good code." The business reality is that most coders are not exceptional, and some are pretty lousy. You can spend all of your budget on human resources finding epic-quality coders (and then scratch some more to come up with their epic-salaries) or you can do what the rest of the world does-- get the best programmers they can find and afford. A framework helps un-exceptional coders write better (and more consistent/maintainable) code. This arguments seems akin to saying "forget word processors! Just get someone who can make Vi or Emacs dance and turn 'em loose." It seems to me that the evolution of software is pretty much the act of layering increasingly-smart frameworks on top of machine language to allow high quality results more accessible to more people.

Stupid article, obfuscated and biased examples.

(Score:1, Interesting)

by Anonymous Coward on Sunday January 22, @08:31PM (#14535288)
This article appears to be written for fools. One of the author's examples of WASP's superiority is that this:
<li flexy:foreach="arTasks,key,task">{task[Name]} - {task[Due]}</li>

is better than this:

<?php
$arTasks = array();
foreach ($arTasks as $key => $task)
{
?>
<li><?php echo $task['Name']; ?> - <?php echo $task['Due']; ?></li>
<?php
}
?>

Because "Already you can see one of the biggest benefits of working with WASP: no need for embedded PHP code."

Well, it might look that way, because he deliberately coded the PHP version in the messiest way possible. He could have simply done this:

<? foreach ($arTasks as $key=>$task) { echo '<li>' . $task['Name'] . '-' . $task['Due'] . '</li>'; } ?>

The WASP sample doesn't look so much better now, does it? Not so much so that it's worth downloading some unknown framework and inheriting someone else's bugs and execution overhead and security holes?

What's problem?

(Score:1, Flamebait)

by hotfireball (948064) on Sunday January 22, @09:40PM (#14535583)
PHP coders really needs some framework. Because I don't realize how else they can work with the "technology"-like thingy which has bad recursion, lots of not-thread-safe stuff, poor OO, hell slow interpreter, no namespaces, non-standard date format, 4x more built-in functions than Perl (however the functionality of them just same), inconsequent function naming convention and no unicode so far. For those who dislikes Python and likes PHP, I would like to offer one experiment. Please do the simple task: make array of arrays of dict of dict of array of dicts structure (you may feel free to make it slightly other) and then try to change/replace/remove/add and compare each element of any place. Afterall compare perfomance and readability of the code.

Re:Just use Ruby or Python

(Score:3, Insightful)

by onion2k (203094) on Sunday January 22, @06:25PM (#14534714)
(http://www.phpgd.com/)

Currently I'd discount Ruby from any sizable web development as it's still very much a minority language and it'd be practically impossible, or outragously expensive, to hire a Ruby developer. If your development team or company vanish (run over by a bus, move to Australia, whatever) you need to be able to get someone else who can come in and maintain the code quickly. That just wouldn't happen for a site written in Ruby. Of course, it'd be fine for any small development like a homepage or a blog .. but PHP would be equally fine for such an unimportant venture despite it's shortcomings. To a lesser extent the same can be said for Python. There's a lot fewer Python developers about than PHP, but there are some.
Caveat: IAAPD (I Am A PHP Developer), so perhaps I'm horribly biased.

[Nov 29, 2005] Debugging techniques for PHP programmers

Explore various methods for debugging PHP applications, including turning on error reporting in Apache and PHP, and by placing strategic print statements to locate the source of more difficult bugs through a simple example PHP script. The PHPeclipse plug-in for Eclipse, a slick development environment with real-time syntax parsing abilities, will also be covered, as well as the DBG debugger extension for PHPeclipse.

[Apr 4, 2005] PHP5 Could PHP Soon Be Owned by Sun

Slashdot

At first glance, the obvious changes to PHP are a result of the success of the Java platform and the weaknesses of PHP revealed in comparison. With the release of PHP 5, it's apparent that the developers of PHP and the Zend Engine (essentially a single group) felt compelled to make PHP much more like Java with respect to object-oriented programming. Zend, the Israeli company backing the development of PHP, promises on their web site that "full integration with Java will be closer than ever before." Hmmm, full integration with Java, huh?

On November 4th, 2003, Zend announced a strategic partnership with Sun. This deal also included advisors from Borland, Macromedia, MySQL and others. The purported purpose of this deal was to make PHP part of Sun's web server and bring it to the corporate world of development that previously had been dominated by ASP and ColdFusion. Now with the release of PHP 5, it's far more apparent which path PHP is taking.

PHP's object model was re-written from the ground up and mimics the abstract properties of Java's object method. There are private and protected members and methods, abstract classes and interfaces, in practice, identical to Java's object model. The extent of the influence that Sun has on PHP today is clear. If you have experience with Java and PHP, reading the details of the object model reveals the absolute cloning of the Java object model within PHP 5. From throwing exceptions to static variables, PHP 5's object model mimics Java in concept all the way to the syntactical level.

This is great for enterprise developers using Sun products, but with the release of PHP 5, what does this mean for the half-million PHP developers worldwide who have depended on PHP for open-source development, or for the developers whose ideas and efforts have brought PHP up through the ranks from its inception in 1995? When PHP goodies were bundled with Sun's web server on November 4th, 2003, with a $775 price tag, PHP began down the path of corporate ownership. For years developers have eagerly contributed their ideas and efforts to be a part of the success of PHP. Now that all the hard work and volunteering has paid off and PHP is a worldwide success, it appears that PHP could soon be another corporate shill owned by Sun, MySQL, Borland and Macromedia, if not on paper, then by direct influence on the people at Zend. Of course it will remain open source so that those half-million developers can continue to contribute their time and genius to its success, but if those thousands of contributions lead to direct financial gain for companies whose coffers are already overflowing and are simultaneously using those contributions to manufacture software with price tags out of reach to anyone but corporations, is PHP still the language developers should be focusing on for use in the open-source community?

On the positive side, this edition of PHP does bring improved performance and a new suite of MySQL functions. Backward incompatibility is limited to a list of ten issues. Additionally, there are only minor configuration file changes that need to be made to the web server. Several directives have been introduced for configuring php.ini files, mainly dealing with hashes for encryption.

Some very useful functions have been added to PHP5. It's been nine years in the making, but PHP5 now includes two functions to uuencode and uudecode. Combining those functions with the new socket and stream functions, developers can create a lots of "kewl" applications. An application to automatically encode and decode files to and from news servers comes to mind as an example of how to incorporate these new functions. At that point of course, a developer could use any of PHP's existing functions to continue to manipulate the files, store the contents in databases, and so on.

An addition to error reporting aids developers in keeping their code up-to-date. The E_STRICT message tells developers when their code is using deprecated functions or is in danger of not being forward compatible. However, don't assume that E_STRICT will be output if using E_ALL, because it won't. E_STRICT must be explicitly declared to output its suggestions to PHP 5 code.

While the rewriting of PHP's object model to essentially that of the Java object model does raise flags about the direction of PHP, it is still a powerful addition to the PHP5 release. Java became successful for a reason: it's intelligently designed and facilitates code reuse. By borrowing the best features of Java's object model, PHP has leveraged itself with far more credibility as a programming language that can stand on its own two feet (even if Sun, Borland and Macromedia are holding it by its arms).

Some vital re-workings in the PHP object model lie in how objects are treated in low-level fashion. Instead of passing the actual object itself, PHP's object model passes by reference. Now when operating on objects, developers can pass around multiple handles to the actual object allowing for more powerful and efficient applications. Existing PHP objects do not need to be re-written to take advantage of this change in PHP 5.

In general, developers who have experience with Java will easily adapt to PHP 5's object model. On the downside, if PHP is a developer's primary language and he or she hasn't been introduced to the world of static variables, public and private methods and the host of aspects included with this new model, they may have a bit of a learning curve adopting the higher-level format of object-oriented programming in this release. Overall, though, this change will be a plus for creating large-scale, object-oriented applications with PHP.

Keeping pace with the developments in MySQL and PHP's tight relationship, PHP5 has added a new suite of MySQL functions relating to the new features added since MySQL 4.1. Denoted as Improved MySQL Extension, its purpose is to allow developers to take advantage of prepared statements and the other additions to MySQL 4.1 and above.

Something very interesting to note with the addition on the Improved MySQL Extension is the absence of bundled MySQL client libraries with PHP5. There are numerous reasons given for this, including the different licenses that PHP and MySQL are under (PHP is under a BSD/Apache type license and MySQL is under a GPL license). The PHP5 documentation also assures developers that "there will always be MySQL support in PHP of one kind or another," but doesn't go into details as to the future of MySQL support. This perhaps is further evidence that the long-lasting popularity of LAMP environments (Linux, Apache, MySQL, PHP) will soon be replaced by SLOP environments (Sun, Linux, Oracle, PHP). If Zend continues to shy away from MySQL and completely joins forces with Sun, MySQL may soon no longer be part of the picture, and cheap, fast development may no longer be possible for PHP developers in the same capacity as it is today.

Zend clearly has underplayed the extent of the shift that has taken place concerning the future of PHP. While this version of PHP does provide a much better object model and added features, is this the beginning of the end of PHP as the choice of web scripting language for the open-source community and developers not under the employ of corporations? Will the average developer still be using PHP five years from now, or will the usefulness of PHP be limited to companies who can afford to shell out thousands of dollars for all of the necessary software that may be required to make PHP a viable option for development (along with the purchase of products from Sun, Macromedia, Oracle, Borland and others)?

While today this is still speculation, the evidence and tone lends credence to the thought that with the success of PHP, built on the backs of developers worldwide, the near future of it may include an alienation of it from those who energized it at its genesis, propelling it to the corporate enterprise status that those in control of PHP are seeking today. No matter what actually happens, developers should be aware of the major developments with PHP beyond the surface level function additions and new object model. Companies and developers who are employing PHP 5 for large-scale applications today at a reasonably low price may be in for a surprise in the next few years, if operating PHP at full capacity involves the purchase of additional, expensive software.

by Matt Perry on Friday August 06, @04:48PM (#9903178)
There's a great overview [kuro5hin.org] of PHP5's new OO capabilities at Kuro5hin.

[Aug 12, 2004] PHP Debugging Basics by David Sklar

Whether you're a PHP newbie or a wizard, your programs are going to have bugs in them. Nobody's perfect. This article gives you some techniques for finding and fixing the problems in your programs. It covers three topics:

How to get the PHP interpreter to report the errors that interest you.

How to locate basic syntax errors in your program.

How to check the values of variables as your program is running.

Configuring Error Reporting

First of all, you need to configure the PHP interpreter so that when an error happens, you can see information about it. The error info can be sent along with program output to the web browser. It can also be included in the web server error log. A common way to set things up is to have error output go to the web browser when you're debugging your program, and then to the web server error log once the program is finished and (supposedly) working properly. That way, web site users can't see any potentially sensitive data included with error output.

To make error messages display in the browser, set the display_errors configuration directive to On. To send errors to the web server error log, set log_errors to On. You can set them both to On if you want error messages in both places.

An error message that the PHP interpreter generates falls into one of five different categories:

Parse error: A problem with the syntax of your program, such as leaving a semicolon off of the end of a statement. The interpreter stops running your program when it encounters a parse error.

Fatal error: A severe problem with the content of your program, such as calling a function that hasn't been defined. The interpreter stops running your program when it encounters a fatal error.

Warning: An advisory from the interpreter that something is fishy in your program, but the interpreter can keep going. Using the wrong number of arguments when you call a function causes a warning.

Notice: A tip from the PHP interpreter, playing the role of Miss Manners. For example, printing a variable without first initializing it to some value generates a notice.

Strict notice: An admonishment from the PHP interpreter about your coding style. Most of these have to do with esoteric features that changed between PHP 4 and PHP 5, so you're not likely to run into them too much.

You don't have to be notified about all of the different error categories. The error_reporting configuration directive controls which kinds of errors the PHP interpreter reports. The default value for error_reporting is E_ALL & ~E_NOTICE & ~E_STRICT, which tells the interpreter to report all errors except notices and strict notices.

PHP defines some constants you can use to set the value of error_reporting so that only errors of certain types get reported: E_ALL (for all errors except strict notices), E_PARSE (parse errors), E_ERROR (fatal errors), E_WARNING (warnings), E_NOTICE (notices), and E_STRICT (strict notices).

Because strict notices are rare (and new to PHP 5), they are not included in E_ALL. To tell the PHP interpreter that you want to hear about everything that could possibly be an error, set error_reporting to E_ALL | E_STRICT.

Interview--Core Web Application Development with PHP and MySQL - Getting to the Core

LinuxPlanet

LinuxPlanet: Why did you set out to write this book?

Marc Wandschneider: Over the years, I've put together a number of small web applications or web sites for various small businesses and charities. Despite being a very accomplished programmer with over a decade's worth of experience, I always found myself floundering and making a lot of mistakes as I adapted to a completely new way of writing "programs." At the same time, I was shocked at how unbelievably productive PHP was as a language. I was able to crank out large amounts of code in short order.

I would periodically look for books or other resources, but find they weren't answering the questions I was asking: how do I design a web application for security? What is the best way to address globalization issues in my application? How do i design a database for efficient access? I also found that, coming from a background mostly in C/C++, Java, and .NET, there were a number of mistakes I was making time and time again when learning the new environment that were tricky and time consuming to figure out.

After writing a number of web applications and slowly learning the answers to the questions I had been asking, I decided to sit down and write a book about my experiences. Instead of just being a tutorial into a number of topics like such as PHP, MySQL, and relevant technologies such as sessions and cookies, I decided to write a book that worked the developer through the questions and processes required to write robust web applications.

LP: There are a good two-dozen or more other books on the same subject matter. Why is yours special?

Wandschneider: There are a number of good PHP books available today for purchase, but the one thing I found lacking in most of them is a systematic approach to some of the more fundamental concerns in writing a web application. Many will merely present security as a single chapter with a list of things to "check" to make sure your site is properly protected. Others will have a chapter covering strings, but not really address how you deal with people writing in foreign languages.

Core Web Application Development with PHP and MySQL doesn't just tell you how to use a particular technology such as sessions, XML, or file uploading--it discusses how they fit into the rest of your application, how they interact with other features, and how you use them in a safe and effective manner.

The other big problem I had were samples that seemed kind of contrived--e-commerce applications that left out key portions of the process or samples that were simply not something you're going to buy a book to help write at all. To solve this, I developed three full samples--an appointment/calendaring system, a blogging engine, and a poster store e-commerce system. With the full code included on a CD ROM (and updates available from the author's web site), you can actually play with completely working and usable web applications, debugging through them and fiddling with various features.

LP: What would you say sets this book apart from others?

Wandschneider: In addition to the samples and systematic approaches to topics critical to writing effective web applications, this book also shows programmers a lot of the tricks and traps hiding in the PHP language. I'm the kind of person who makes every single mistake possible, so I had a lot of experience in doing stupid things and was able to put a lot of that into this book, to hopefully help the reader avoid making those same mistakes.

I am also the kind of person who likes to understand how things work and why things are done. Without bogging down in pedantic details, I tried to justify and explain topics and technologies as I worked through them. Later on, you might not remember the exact details of the PHP function call or SQL Statement, but you might recall that this was something important enough to worry about and look it up again.

LP: Why do other books neglect these topics, do you think?

Wandschneider: I actually think that most other books do address these topics, but often in a disorganized way that gives them the feel of being tutorials crammed together into one big binding. A chapter on security that merely offers a simple list of things to check in your web server or php.ini don't adequately address the problem, nor does discussing programming without discussing all the ways in which things can (and inevitably do) go wrong.

LP: Why MySQL?

Wandschneider: I actually didn't want to write this book for only MySQL. While it is the database I use most frequently (strictly because it's the first I picked up and learned), the concepts in this book are not unique to that package. I had originally hoped to keep the book database server agnostic, but as I wrote more and more, I came to discover this was not possible, so I decided to focus on MySQL, and provide hints and tips to users of other DBMSes whenever possible (such as Appendix II: "Database Function Equivalents").

There is nothing in this book that should prevent the user from being able to develop web applications with other servers.

LP: Marc, what is your background?

Wandschneider: I got my degree in Computer Science from McGill University in Canada and moved to the United States to work for Microsoft in the mid-1990s. I spent most of my time there working on Visual Basic and various component technologies associated with it. In the end, I was the manager of the WinForms team for the .NET platform. I left in 1998 after increasing dissatisfaction with my job and the direction the company was going led to me to explore other opportunities.

Amusingly enough, in my early days at Microsoft, I found databases quite frustrating and aggravating to work with, and it wasn't until I began working with MySQL that I began to truly enjoy working with them again.

I have spent the last six years traveling the world, helping companies with various software development problems, and writing open source software in my spare time. I have lived in various countries such as Italy, Germany, and Japan, and have seen how mono-lingual web applications can be problematic for users.

LP: Microsoft? Aren't you worried that will reduce your credibility in the open source community?

Wandschneider: I've met some people who figure that since I worked for Microsoft, I must eat babies or something in my spare time. And yet, I maintain that my years at Microsoft were very valuable and rewarding. The company was still very much a fun place to work in the mid 1990s and I learned innumerable things about robust programming and truly testing and shipping effective software.

It is these good habits that I have tried to carry forward with me in my web application development. Everybody benefits when software is written well, and I hope to contribute more written open source.

LP: How long did it take to write the book?

Wandschneider: I went to a local caf� and started writing this book. Six months and many, many, many double espressos later, I had written the first draft of it, and it was off to editing (which took a few more months). I wasn't working at the time, so I was basically spending 40-50 hours a week writing it. I would spend a few days writing code and samples for a particular chapter or group of chapters, plan strategy for what I was going to write, and then I would actually begin typing it all up.

LP: Did you enjoy writing this book?

Wandschneider: There is nothing like trying to explain a particular concept or technology others to make sure you really understand how it works. I spent a lot of time writing little scripts and samples, and would sometimes sit there scratching my head, while at other times I would learn something completely new and interesting I had never known before. After a while you start dreaming in SQL and PHP. That's probably not the best thing to admit!

LP: What experience will readers of this book be expected to have?

Wandschneider: I wrote this book for people who have "programmed" before. I make no stronger requirement than that. If they have written a number of VB scripts or programs, written Perl for a while, or indeed written large applications in Java or C/C++, this book was designed to be accessible to the reader.

Since I knew next to nothing about databases before beginning to write web applications, I likewise assumed the reader would know little about those as well. With that in mind, the book sets out to teach the reader not only the syntax of PHP and SQL, but also the problems they will encounter, and how to use them most effectively in their applications.

LP: What platform do you think readers of this book should be using?

Wandschneider: There are absolutely no requirements on what the reader uses. I myself, to make sure that there was nothing too restrictive in what I was writing, developed, tested, and ran all samples on Windows, Linux, FreeBSD, and Mac OS X. I used PHP versions from PHP 5.0 to 5.0.4, as well as MySQL Versions from 4.1.7 and on (including the newest 5.0 releases).

I have recently worked on commercial PHP/MySQL web applications where development has occurred on Windows, Mac OS X, and servers running multiple flavors of Linux. In only the most extreme cases did we ever even notice that the versions were running on different platforms.

LP: What are the major features of PHP5 about which you're excited? What about MySQL?

Wandschneider: The object oriented features in PHP 5 are a very welcome addition to the language. I've found that it massively helps design of application and encourages clean organization of your code. The strict syntax checking has also proved helpful to avoid undefined variable errors, as well as numerous other little coding issues that have been hiding in my code. Add to that the new MySQLi (Improved MySQL) extension, and I've found programming PHP 5 to be a true joy.

MySQL has grown to be a truly interesting and robust database system. Versions greater than 4.1.7 have massively improved Unicode support, which has allowed me to develop applications that are completely ignorant of what language the user sends us data in. The database just stores them all as UTF-8 strings, and the application shuttles these data to the client. With a robust set of data types and the choice between MyISAM and InnoDB tables, there is a real sense of control when using this server.

LP: Where can users go for more help with this book?

Wandschneider: I maintain a blog at http://www.chipmunkninja.com, where I post not only updates and notes on this book, but also other tutorials and other things that developers might find useful.

Conclusion

Core Web Application Development with PHP and MySQL is organized into five core parts:

learning PHP

learning Databases

designing your web applications

implementing your web applications

complete web application samples

With this progression through the topics, and systematic approach to design and security, the reader, whether they be inexperienced or advanced, will find this a valuable tool to have around as they explore the world of writing web applications. With a remarkable attention to detail, a light and easy writing style, and a complete explanation for how things work, you will absolutely love working through this text.

Book Information

Title: Core Web Application Development with PHP and MySQL (Core) (Paperback)
Author: Marc Wandschneider
Publisher: Prentice Hall PTR; Bk&CD-Rom edition (September 26, 2005)
ISBN: 0131867164
Price: $49.99

Software Engineering for Internet Applications

by Eve Andersson, Philip Greenspun, and Andrew Grumet
MIT Press 2006; ISBN 0262511916; order a hardcopy from amazon.com
Preface
Acknowledgments
Chapters:

Introduction

Basics

Planning

Software Structure

User Registration and Management

Content Management

Software Modularity

Discussion

Adding Mobile Users To Your Community

Voice (VoiceXML)

Scaling Gracefully

Search

Planning Redux

Distributed Computing with HTTP, XML, SOAP, and WSDL

Metadata (programs that write programs)

User Activity Analysis

Writeup

Project details for Conary by Michael K. Johnson

Michael K. Johnson, the author of Linux Application Development. see his homepage

freshmeat.net

Conary is a distributed software management system for Linux distributions. It replaces traditional package management solutions (such as RPM and dpkg) with one designed to enable loose collaboration across the Internet. It enables sets of distributed and loosely connected repositories to define the components which are installed on a Linux system. Rather than having a full distribution come from a single vendor, it allows administrators and developers to branch a distribution, keeping the pieces which fit their environment while grabbing components from other repositories across the Internet.

Project details for Andy's PHP Knowledgebase

freshmeat.net

Andy's PHP Knowledgebase is a database-driven knowledge base management system. It features bookmark friendly URLs, easy search with browsing by category, article submission, and a professional and attractive interface. It is intended to be used to store, manage, and update article content for a knowledge base, but is very customizable and enables any number of creative uses.

SQLiteManager by Fr�d�ric HENNINOT

SQLiteManager is a multilingual Web-based tool to manage SQLite databases. It features multiple database management, creation, and connectivity, property and options management, table, data, and index manipulation, the ability to import data from a file, conversion from MySQL queries, view, trigger, and custom function management, and exporting of database structure and data.

Archive of old news...

Web Database Applications with PHP and MySQL Chapter 11: Authentication and Security (PDF Format)

Programming PHP (First edition) Chapter 5: Arrays (HTML Format)

Programming PHP (2-d edition) Chapter 8: Databases (PDF Format)

Learning PHP 5 Chapter 8: Remembering Users with Cookies and Sessions (PDF Format)

PHP Cookbook Chapter 8: Web Basics (PDF Format)

Web Database Applications with PHP, and MySQL Chapter 8: Sessions (HTML Format) See also Chapter 8: PHP Session Management With Cookies

Learning PHP and MySQL Chapter 9: Getting PHP to Talk to MySQL (PDF Format)

Upgrading to PHP 5 Chapter 4: SQLite (PDF Format)

PHP in a Nutshell Chapter 16: Manipulating Images (PDF Format)

Essential PHP Security Chapter 4: Sessions and Cookies (PDF Format)

Chapter 3: Record Selection Techniques (PDF Format)

MySQL Cookbook

Chapter 7: Generating Summaries (excerpt)
Chapter 11: Generating and Using Sequences (excerpt)
Chapter 12: Using Multiple Tables (excerpt)
Chapter 14: Handling Duplicates (excerpt)

PHP Hacks

Hack 33: Access Your iPhoto Pictures with PHP (PDF Format)

Hack 49: Create Excel Spreadsheets Dynamically (PDF Format)

Hack 55: Fix the Double Submit Problem (PDF Format)

Hack 90: Read RSS Feeds on Your PSP (PDF Format)

Hack 95: Create Custom Google Maps (PDF Format)

PHP Pocket Reference Introduction

Webmonkey databases PHP-MySQL Tutorial

http://ca.php.net/manual/ -- annotated PHP manual.

PHP Tutorial - Part 1

Recommended Papers and Interviews

Interview with with Rasmus Lerdorf

FAQs

FAQ - PHP3
http://www.php.net/FAQ.php3

Scripts Archives

Berber's PHP3 Example Page
http://php.netvision.net.il/examples/

Computers and Internet: Software: Internet: World Wide Web: Servers: Server Side Scripting

Zend - engine for PHP server-side scripting language for Internet applications.

PHP vs Perl

Perl versus PHP 5 - O'Reilly ONLamp Blog

Critique

[Apr 20, 2006.] What I don't like about PHP by Edwin Martin <[email protected]>.

August 6, 2004; Last update: April 20, 2006.
I have been developing in PHP for six years now. PHP is very easy to program in. But PHP also has some serious flaws.

Below I give some reasons why you have to do some serious thinking before implementing a large scale web application in PHP.

1. Bad recursion

Recursion is the mechanism in which a function calls itself. This is a powerful feature which can make something complex something simple. An example of a function using recursion is quicksort. Unfortunately, PHP is not good at recursion. Zeev, one or the developers of PHP, says this: "PHP 4.0 (Zend) uses the stack for intensive data, rather than using the heap. That means that its tolerance recursive functions is significantly lower than that of other languages." See bug 1901. This is a poor excuse. Every programming language should provide good recursion support.

2. Many PHP-modules are not thread safe

A couple of years ago, Apache released version 2.0 of its web server. This version supports multithreaded mode, in which one piece of software can run multiple times simultaneously. The makers of PHP say that the core of PHP is thread safe, only the non-core modules often aren't. But nine out of ten times, you do want to use such a module in your PHP-script, making your script unsuitable for Apache's multithreaded mode. That's why The PHP Group doesn't recommend running PHP on Apache 2 in multithreaded mode. The bad multithreaded mode support of PHP is often seen as the reason Apache 2 still didn't catch on.

Read the discussion about this on Slashdot: Sites Rejecting Apache 2?.

3. PHP is crippled for commercial reasons

The performance of PHP can be increased to 500% by using caching [benchmarks]. So why is caching not build into PHP? Because Zend, the maker of PHP is selling its own Zend Accelerator and of course, they don't want to cannibalize on there own commercial products.

But there is an alternative: APC.

4. No namespaces

Suppose someone creates a PHP-module that can read files. One of the functions in this module is called read. And someone else's module can read web pages and also contains a function read. Then it is impossible to use these modules together because PHP will not know which read function you want.

An easy solution to this is namespaces. It was a suggested feature for PHP 5, but unfortunately it didn't make it. Now, without namespaces, every function has to be prefixed with the module name, to prevent name collisions. This leads to terrible long function names like xsl_xsltprocessor_transform_to_xml which makes code harder to write and read.

5. Non-standard date format characters

Many programmers are familiar with the date format characters known from UNIX and the C programming language. Other programming languages adopted this standard, but strangely enough, PHP has its own, completely incompatible date format characters. While in C, "%j" stands for the day of the year, in PHP this stands for the day of the month. To make things even more confusing: the function strftime and the date_format of Smarty, a PHP templating engine, do use the C/UNIX format characters.

6. Confusing licenses

You might think PHP is free and all PHP-modules in the manual are free too. Wrong. For example, if you want to generate a PDF-file from PHP you will find two modules in the manual: PDF or ClibPDF. But both come with commercial licenses. So for every module you use, you have to make sure you agree with its license.

7. Inconsequent function naming convention

Some function names consist of more than one word. There are three conventions for combining these words:

Glued together: getnumberoffiles

Separated with underscores: get_number_of_files

Camel case: getNumberOfFiles

Most Languages choose one of these variants. PHP uses all of them.

For example, it you want to convert special characters to HTML entities, you use the function htmlentities (Words glued together). If you want to do the opposite, you use its little brother function html_entity_decode. For some reason the words are now separated by underscores. Why is this bad? You know there is a function named strpad. Or was it str_pad? Every time you have to look up what the notation is or wait for an error to occur. Functions are case insensitive, so for PHP there is no difference between rawurldecode and RawUrlDecode. This is bad too, because both are used and because they look different, they will confuse the reader.

8. Magic quotes hell

Magic quotes prevents PHP-scripts from SQL injection attacks. That's okay. But for some reason, you can turn this off in the php.ini configuration file. So if you want to write a portable script, you always have to check whether magic quotes is turned on or off. So a "feature" to make programming easier, actually makes it more complex.

9. No standard framework

A website wihout a framework which grows will eventually become a maintanance nightmare. A framework can make a lot of work easier. The most popular model for a framework is the MVC-model, in which layout, business logic and interaction with the database are seperated.

Many PHP web sites don't use the MVC-model. They don't even use a framework. Although some PHP frameworks do exist and you can also write your own, articles or manuals about PHP don't say a word about frameworks. While JSP-developers use frameworks like Struts and ASP-developers use .Net, it looks like the concept of a framework is largely unknown by PHP developers. This says something about how professional PHP really is.

Update: Zend, the developer of PHP, is working on a framework: Zend PHP Framework.

10. No Unicode

With Unicode it is possible to use every language in the world, for example Chinese, Arabic and Hebrew. While every other serious programming language supports Unicode for many years, PHP still has a very hard time dealing with this. Unicode is planned for PHP 6, so we still have to wait a long time before PHP supports this trivial feature.

11. Slow

You think Java is slow? PHP is much slower! See this Computer Language Shootout. Normally that's not a big issue, because most PHP-scripts only pull data from the database and render it in HTML, a very simple job and fast enough for page views. So how can PHP be used on all these popular websites with lots of visitors? Because of caching. These sites use MCache and APC to get performance. It doesn't proof anything about PHP, only that it's cachable.

Conclusion

For very small projects, it can be a nice programming language. But for larger and more complex projects, PHP can show its weakness. When you search long enough, you'll find solutions to some of the mentioned problems. So when a solution is known, why isn't it fixed? And why are the fixes not mentioned in the manual?

It's good that an open source language is very populair. Unfortunately, it's not a great language. I hope all problems will be solved once (in PHP 6?) and we will have an open source language that's open source and good.

Until then, when you start a project larger than five scripted pages, you might also consider C#/ASP.Net or Java/JSP as a better solution.

After I wrote this page, some people informed me about other, similar pages:

Experiences of Using PHP in Large Websites

I'm sorry, but PHP sucks

"PHP in contrast to Perl"

I hate PHP

PHP Annoyances

Spyced Why PHP sucks Jonathan's Python Blog

(July 8 2005)

Apparently I got linked by some PHP sites, and while there were a few well-reasoned comments here I mostly just got people who only knew PHP reacting like I told them their firstborn was ugly. These people tended to give variants on one or more themes:

All environments have warts, so PHP is no worse than anything else in this respect

I can work around PHP's problems, ergo they are not really problems

You aren't experienced enough in PHP to judge it yet

As to the first, it is true that PHP is not alone in having warts. However, the lack of qualitative difference does not mean that the quantitative difference is insignificant.

Similarly, problems can be worked around, but languages/environments designed by people with more foresight and, to put it bluntly, clue, simply don't make the kind of really boneheaded architecture mistakes that you can't help but run into on a daily baisis in PHP.

Finally, as I noted in my original introduction, with PHP, familiarity breeds contempt. You don't need years of experience with PHP before an urge to get the hell out and into a more productive environment becomes almost overwhelming -- provided that you have enough experience to realize what that nagging lack of productivity is telling you when you go to consult the documentation for the fifth time in one morning.

Basically these all boil down to, "I don't have enough experience to recognize PHP's flaws because I haven't used anything better." Many years ago, I had this same attitude about Turbo Pascal: it was the only language I knew at the time, so anyone who pointed out its flaws was in for a heated argument.

There's nothing wrong with being inexperienced, as long as you have an open mind. If you do, try Spyce. Try RoR, if you must. Better toolkits are out there, for those who aren't satisfied with mediocrity.

I've done a fair bit of web development. I've written HTML-generating code in C CGI scripts, Cold Fusion, TCL (with OpenACS), ASP.NET, and, of course, Python with Spyce.

Two technologies I've steered clear of are any J2EE stack and PHP. I've seen enough of each to know that I'd be immensely frustrated with either. Briefly, although they are quite different, neither is elegant, and elegance counts.

Recently, though, I had to spend a few days extending a small amount of PHP code. (I'm just glad for two of those qualifiers: "few" and "small.") The more I used it, the less impressed I was, which is why I don't think a longer experience would make this post any more favorable to PHP.

This is far from an exhaustive list. It may have some reasoning in common with other voices of reason, but I'm writing this primarily from a Python developer's perspective. So, I won't waste time bashing PHP for being dynamic, which some Java zealots do; nor will I fault it for mixing code and markup, which also has its uses (and Spyce recognizes this). PHP's problems are much, much deeper.

First, let's try to be a bit more specific. Does PHP the language suck, or does PHP the environment suck?

They both suck.

In fact, they suck for the same reason: PHP-the-language and PHP-the-environment both grew by accretion of random features, not by any purposeful design for orthogonality. So you have idiot "features" like magic quotes ("Assuming it to be on, or off, affects portability. Use get_magic_quotes_gpc() to check for this, and code accordingly) and register globals (same disclaimer applies, only more so).

Trying to write "portable" php code is such a disaster that it's no wonder almost nobody tries; you can't even code for a least-common-denominator version because (a) so much is subject to change on the whim of the site's config file and (b) even if it weren't, the PHP designers change the defaults almost as often, even within minor version releases. (E.g., the registerglobals change for 4.2.)

The PHP community realizes this to a degree, even if the fanboys won't admit it. PHP5 uptake is almost as glacial as MySQL4 was/is because it breaks so much code. One of the biggest ways is, "all your copy-on-assign code, isn't anymore."

That bears explaining if you haven't coded in PHP4: any time you make an assignment in PHP4, what other languages would call a "deep copy" is performed. So you might naiively expect this code to add a new key/value pair to the associative array at $a[0]:

<?
$a = array(array('foo' => 'bar'));
foreach ($a as $item) {
   $item['new key'] = 'new value';
}
print_r($a);
?>

This, of course, changes $a not at all, because the assignment to $item is a deep copy. (It's also slow as hell if the items you're deep-copying are substantial.) The workarounds for this are truly ugly.

This changes completely in PHP5, which is a good thing, unless you're trying to upgrade an existing body of code. That's not a small "unless;" if you weren't using PHP4, there's really no excuse to start out in PHP5 instead of Spyce or CherryPy or Rails.

Even with a willingness to break backwards compatibility, a lot of broken behavior persists in PHP5. For instance, since I brought up PHP arrays: an array in PHP is really a map. When you're using it as a linear array, it's really mapping keys 0, 1, etc. to your values. (I don't want to know what it does when you're using it as a 2D array.) This might seem like a good idea, until you spend about two seconds thinking about it, at which point those of you who have had a basic introduction to data structures will be thinking, "What the hell? The performance will SUCK!" And you are entirely correct. The only other language I can think of that does this is AWK, and it was a bad idea there, too, but less of a problem since, well, when was the last time you wrote an AWK script longer than 10 lines?

PHP-the-language also shares with Perl the unfortunate tendency to guess what the programmer "really meant" instead of raising errors. (String where an integer makes more sense? No problem, we'll just throw in zero!) Unlike perl, there's no "use strict" option to mitigate this.

I could keep going, on how, for instance, the PHP environment doesn't give you any way to have a single, multithreaded long-running process, which is probably why you see so much PHP code that sticks everything into the session object. Or how PHP's string processing library adopted the C stdlib functions without improving on them. Or a dozen things, but a comprehensive enumeration of PHP design flaws would be a daunting task indeed.

In short, PHP sucks because, PHP's authors are prone to confuse "pragmatism" (a fine design goal, if done well) with "adding random features without considering how they impact the language as a whole." Thus, its authors have found it necessary to correct obvious flaws in both minor and major releases, with the result that the recent PHP5 breaks with the past to an unprecedented degree while still leaving many fundamental flaws un-addressed. I don't know if this is because they didn't recognize those flaws, or more likely, because they were willing to impose "requires a lot of pain to upgrade" but not "requires a complete re-write."

Ian Bicking wrote that "Python could have been PHP" (in popularity for web development). If I were a PHP developer, I'd be pretty disenchanted with how the language has evolved; I don't think it's impossible that Python could have a second chance.

- posted by Jonathan Ellis @ 10:52 AM

Comments:

I'm a PHP developer, and have been for three years, but I have to agree with some of your comments.

magic quotes, and register globals should have never been added as a "feature" and is just a pain to have to code work around today, to get the script's to work with it on and off.

I also agree with PHP5 breaking most PHP4 script's, that's what, in my opinion, will hold back PHP5 becoming main stream, we won't have much luck with it until popular script's are updated to work with PHP5, and server's by popular demand will need to upgrade. Until then we won't see much changes to these problems.

I love how python works, but really haven't taken the time how actually learn it, only downside is that mod_python isn't installed on many server's.

# posted by Justin Shreve : 3:40 PM

Spyce will run as a CGI/FastCGI script, Justin. :)

# posted by Justin Shreve : 5:05 PM

Magic quotes and register globals were features designed to lower the bar more, for newbie developers who didn't understand databases, or HTTP as well as for seasoned professionals to write code quicker by making certain assumptions. You can write secure code with both of those settings if you're careful and know what you're doing. These two extremes: easy for newbies, and short cut for seasoned developers don't mix.

Unfortunately, delivering web apps for use by others cannot make those assumptions.

You really don't have to worry if a user has register globals on or off. After all, you the app developer should be using the global arrays anyway. So, it's really just magic quotes which can be a pain. And is it a pain to detect it and do an ini_set? That's just a couple lines in a global include.

Ok, next subject: arrays. There is no pretense on what arrays are, see here:

http://us2.php.net/manual/en/language.types.array.php

And the manual notes that they are maps, and are optimized so that they can be treated as lists, hash tables, queues, stacks, etc.

I would venture so far to say that PHP arrays are extremely powerful, flexible, and straight forward. Moreover, I trust that the many PHP engine developers - many of which hold degrees in comp sci and know of The Big O and data structures, have in fact optimized the arrays for the best speed possible. As far as I can tell, using arrays heavily in PEAR::SOAP is that the performance is great.

Last but not least, PHP5. There are incompatibilities everywhere in software development. There is a compatible mode for PHP5, and going through your code and fixing reference changes is a do-it-once and your done exercise. You bit the bullet for the day / week, and then you're good to go and ready to take full advantage of all the new features. It's a small price to pay, and gradually people are making that change.

I have no qualms against Python, but flaming another language wihout due course, now that just sucks.

# posted by Anonymous : 9:03 PM

Been working with PHP recently (sadly version 4) and couldn't agree more with your observations.

# posted by matt : 11:21 AM

Couldn't agree more, Jonathan. I have really tried to like PHP several times now, but the features have been adopted so haphazard that I go crazy with it. Many are duplicated and the API is nonstandard to itself. The database layer(s!) are one of the best examples of this type of evolution.

# posted by Anonymous : 6:50 PM

I have to use PHP at work, and it does indeed suck. I could lengthen your list of gripes by a factor of 100!

But as my friend is fond of arguing, my main beef with PHP is that (like MySQL) it does exactly what it's supposed to do, it just shouldn't be used for a lot of stuff it's used for. It's a fast and easy-to-use web scripting language, not a strictly typed scalable enterprise language. :-)

Too many people choose PHP for the wrong projects!

# posted by Anonymous : 1:02 PM

Another anonymous commentator said, "I trust that the many PHP engine developers - many of which hold degrees in comp sci and know of The Big O and data structures, have in fact optimized the arrays for the best speed possible."

Holding a degree in computer science does not make you magically able to alter the fundamental properties of fundamental data structures.

If PHP's "arrays" are implemented as balanced trees, their performance will be O(lg n) for all operations, compared to O(1) accesses on real arrays, or O(1) prepends on real lists. If they're implemented as hash tables, then however good the hashing function, there will inevitably be many degenerate cases where insertion and lookup complexity rises to O(n). This is called "not scaling well".

However they're implemented, memory usage on simple arrays will ALWAYS be considerably higher than it would have been for a specialised array type. You've got great performance on your code? Then either you have incredible resources at your disposal, or you only have half a dozen unique visitors in a year.

PHP simply doesn't scale as well as other alternatives. That's not bashing PHP; the world needs a simplistic language that newbies can put together a homepage in, and PHP handles hobbyist sites beautifully. But claiming it's ideal for every kind of programming is stupid. Let's just say there's a reason Doom 3 and Longhorn are not written in PHP...

# posted by Anonymous : 3:37 AM

All this bashing from someone with little experience in php. Funny you dont mention your experience with coldfusion.

Coldfusion is a notoriously bad framework that allows you to do stupid easy things quickly and then takes forever to do anything real. Talk about arrays not being implemented properly, coldfusion doesnt know what arrays are. A sort on two dimensional arrays sorts a single dimension only. It was obviously written by and for folks that have no programming experience or knowledge.

The reason I bring this up is you bash php, which you admit to steering clear of and yet you dont bash the much horribly worse language that you admit to using. So your argument boils down to "I dont know this very well, so it sucks."

Php is head and tails above most scripting languages. Yes, it has quirks, but they are logical and easy to work around, unlike most baby languages, where you spend all your time fighting the language/framework.

# posted by Anonymous : 11:34 AM

I developed in coldfusion for about a year because I was paid to do so. What's your excuse for using PHP so long that you've apparently become allergic to the obvious?

# posted by Jonathan Ellis : 12:35 PM

Is that your way of agreeing with me without saying it? You only used cf because you were paid to?

The obvious here is that you have limited experience with php and the flaws in php you put forth are trivial to work around.

CF sucks 10 times worse than php in exactly the things you bashed php for. That to me makes php a MUCH better choice over atleast cf.

The fact that you cant understand that obvious point makes your whole post suspect.

# posted by Anonymous : 6:23 PM

Grasping at "coldfusion sucks" as a straw man because I mentioned it along with 4 other web technologies is pretty weak. Nowhere did I say that CF was good technology; neither would I be writing CGI in C these days.

But PHP is a real train wreck, the sort, as I mentioned, that doesn't require long experience to recognize if you have a broader experience by which to judge it.

# posted by Jonathan Ellis : 8:11 PM

"Grasping at "coldfusion sucks" as a straw man because I mentioned it along with 4 other web technologies is pretty weak. Nowhere did I say that CF was good technology; neither would I be writing CGI in C these days."

That is why PHP is so popular. It is better (and cheaper) the CF -- and not as ancient as CGI.....No other technologies or web based scripting languages have really stepped in and claimed the ground that PHP covers. I.E. -- easy enough for the beginner to get their arms around and start using, but powerful enough to grow.

Granted, I agree with most of what you said -- but I fail to see any real alternatives in this arena.

# posted by sog : 2:29 PM

I use PHP quite extensively in my (day) job as a programmer at a radio station, and find the arrays to be immensely useful compared to other languages, even other web-based scripting languages. The fact that exceeding array indices is virtually impossible in PHP is immensely helpful, since it greatly simplifies the logic of the program, delegating bounds-checking to the preprocessor. Indexed iteration through an array is the only time I've accidentally overstepped the bounds, to my memory. I must also point out that large datasets rarely occur in PHP scripts; I cannot recall ever requiring an array of a size where the big-O efficiency was an issue; that sort of computation I generally leave to the backend data storage engines, which are already optimized for large datasets anyway. I do agree that the function libraries are designed in a vastly unstructured way, but this hardly bothers me; perhaps this is only because I have a good memory for function names.

Software engineers who point out superficial problems with a given language (like inconsistent function names) always seemed like pansies to me. The loose-typing of variables has never caused me too much grief (I just have a small library of type-validation code I've written for PHP as an include file--it works miracles), but the ability to dynamically create variables ex nihilo is a large source of subtle bugs arising from typos, and this is one of my major gripes about the language.

Magic quotes doesn't seem too horrible either; if you control your server, they are a nice shortcut. If you do not, simply encapsulate query string variables in a set of functions to properly escape or unescape them; you'd have to do it anyway every time you stored them in the database, so it's not any extra work at all, really. It is odd that your article complains of the time wasted on these things, which all have very quick remedies, when it ignores the time which would be wasted debugging array index problems, creating customized datastructures of great complexity where nested PHP associative arrays are much simpler, and other such things.

Granted, if you actually MUST use large amounts of data in arrays, I can see the problem of inefficiency . . . but why would you be using PHP for such things anyway?

No language is meant for all purposes. In the end, I find your arguments against PHP (the language) to be valid, but misdirected and, in some cases, trivially worked around. Your arguments about the management of the PHP project, however (regarding changes in APIs, initialization files, and other things), all have great merit; these sorts of problems are generally part-and-parcel to most open source / free software projects.

# posted by Anonymous : 2:39 PM

Once I was complaining about PHP to a colleague who then informed me that he had the unfortunate position of writing a lot of VB Script and I should be thankful for how lucky I was to be able to use PHP.

As for the PHP environment inconsistencies, this is a non-issue. 1) you can detect and correct the problems at runtime, and/or 2) you can change php.ini or modify php flags in apache when setting up a domain. It only takes 5 minutes. Compared to the hundreds of hours of programming I do, complaining about flags in php.ini is petty. Every other environment I have ever encountered has similar configuration issues -- be it flags to a C compiler, classpaths, or whatever.

As for the incompatibilties between PHP4 and PHP5, I have never seen this actually be a significant problem with any project. I have never seen code that actually depended on copy-on-set. All I have ever seen is &= statements to prevent it from happening, which are now just redundant code.

What is the internal structure of an array() ? I don't care -- it may as well be a linked list, because for any data set large enough to matter, I use a database.

The fact that PHP is an accretion of random features has two sides -- one its bad because everything is in a huge shared namespace and sometimes the argument style is inconsistent. but its also good because it means that PHP has a lot of features! Instead of worrying about how things are organized, a lot of work has been put into cramming PHP to the brim with every possible feature. That makes it easy to use -- no hunting for some module to import, its all just there.

Let me add that I *love* python, C, perl, mathematica and a bunch of other languages. Each of them have their moments -- just don't misuse them. I don't write web pages in C, and I don't write real-time interactive programs in PHP.

Finally, there are some really deep problems with PHP that also fall in its scope of pratical use (i.e. for web pages), but those problems are bigger than just PHP -- things related transaction processing on large scale and complex websites going from the browser all the way into the database. AFAIK the various "enterprise" Java products (JSP et al) come the closest to dealing with them properly.

# posted by Anonymous : 3:14 PM

I write lots of PHP code and I find annoyances:
* messy standard library. inconsistent arguments require often manual lookups.
* classes require use of $this-> for every method/var.

but some of your points are not valid or exagerrated:
* register_globals doesn't matter in well-designed code and it takes one line to remove magic_quotes.
* My PHP4 code just works on PHP5. Switch can be painful, but doesn't have to be. It depends on coding style.
* PHP, and its arrays, are fast. Fast enough for their purpose. PHP arrays flexible and easy to use. Programming speed is often more important (and expensive) than server speed.

# posted by kL : 4:08 PM

Writing portable code is not that hard if you know what you are doing. I assume that if you had problems with register_globals is because you were not using the superglobals in the first place, or HTTP_SERVER_VARS, or well...you kept the default install. I've been using superglobal arrays even back in the days when the default was ON.

I don't see how the magic_quotes represents an obstacle to writing portable code. There's plenty of functions to help you out: stripslashes(), ereg_replace(), set_magic_quotes_runtime(), etc
Just write a globally included script that deals with all submitted vars accordingly by processing the superglobals according to whatever the setting is. Not impossible, really.

Also, if you RTFM you'd know right away that foreach operates on a copy. And if all your complaints are because you want to use foreach() and you can't because it makes a copy first, then use a for() and stop whining. Babies are NOT dying.

don't get me wrong: I am not saying PHP is great. I am just saying that if you had the magic_quotes and the register_globals problem, is because you kept the default install. Ever since that setting was there, everybody I know set it to off when the default was on back in the 4.1 days or whatever.

If an user bothered learning how to properly install PHP instead of keeping the defaults like a moron, he'd have developed 10 lines of code and include them globally and never have the register_globals or magic_quotes problem again.

# posted by Anonymous : 4:58 PM

sorry, forgot one thing: I didn't mean to flame the post nor anything, I am just saying those reasons are not valid enough to say that PHP sucks.

Yes, I think it sucks, but those are not the reasons.

# posted by Anonymous : 5:00 PM

I've developed in PHP for about 5 years, on a number of hobbyist sites and several commercial sites. I tend to agree that the issues brought up in the post, but disagree with the apparent conclusion -- that PHP should be consigned to "teh suck" bin and used only by newbies. It has its advantages: huge libraries / open modules, the flip side of the poor orthogonality is a veritable everything-and-the-kitchen-sink feature set, the syntax hits a right point between the familiarity of C-derived stuff and flexibility of Perl (and avoiding, for the most part, the WTF? moments of Perl), large support community, choice of development styles. It's comfortable. Though I also see the appeal of Python, or Ruby.

The better title would have been "What Sucks About PHP." See Mark-Jason Dominus' "Why I Hate Advocacy" for hints.

# posted by Anonymous : 5:24 PM

The magic quotes and register globals issue is old, old, old.. And if your going to be naive about the particulars of a language then things are going to break aren't they..?

Im really fed up with peoples problems with PHP. Ive been programming for 20 years (C/C++) on Windows (flame, yawn), I have used Perl, which I quite like but it has its problems, elitism being a big one, ASP and PHP. I dont get on with Java, my preference.

PHP is good for web sites, thats what it is for. Yes, a lot of new programmers start off with it, it is easy to pick up. yes it is still maturing, and yes it will evolve and change.

Don't get me wrong, i DONT use it for everything, i use it when it suits the the job in hand.

How long are people going to bring up old issues? Is it that people are scared of the ease of use of this language and the influx of programmers it is bringing in? if it sucks so much you have nothing to worry about.

paul dot simmonds at gmail dot com

# posted by Anonymous : 1:36 AM

before this all becomes another flamed egos-war, I just want to tell you that you should have spent a little more time developing php before start complaining about it. There's so many things you can easily do with php that these pure beginner problems mean nothing

# posted by calin : 1:40 AM

php is absolutely fine. the choice of making it good and solid, or leaving it to feel like you're hacking in stuff rather than coding nice and clean, is entirely up to you. you can grab all of your programming concepts knowledge and apply it successfully in php to a good extent. it's practical, rapid to develop, and if you do it right, you can just leave it there and it will run without stopping. you can slag off just about any platform out there.

# posted by george : 2:49 AM

The problem I have with PHP that I can't work out how to fix is typos in variable names. If I type $choice one time, and $chioce the second time, but I wanted them to be the same variable, how can I get PHP to tell me about this?

# posted by Anonymous : 3:04 AM

I agree with much of what you've said, although I must take issue with one thing. You complain (justifiably) about cruft-by-accretion. How do you deal with that? You drop it in a major version hop. Which is what they did with the jump to PHP5 - threw out their brain-dead object model and brought in a better one. So I don't agree with your complaints against that move. -- Jon Dowland

# posted by Anonymous : 7:28 AM

My point was that with only a little thought in the early days, major breakage in PHP5 wouldn't have been necessary. (And even so they left some of the fundamental flaws alone.)

# posted by Jonathan Ellis : 7:57 AM

With regards to your comment of "I don't have any problems working around PHP's limitations so you must be wrong," Mr. Ellis, I must respectfully disagree. At least as regards the workarounds (not the fundamental design decisions of PHP's implementation itself, such as the argument over arrays versus hash tables), I would never consider something like avoiding register_globals or magic quotes or references to $this to be "flaws" in the language. I would consider them quirks. Indeed, some of these are pure syntactical issues, and nothing more than a matter of taste! While it may be tempting to initially respond that this is merely a matter of semantics, I find it not to be the case. A flaw is a fundamental problem with a language; other arguments in this thread may count as flaws, but none of those for which workarounds have been presented are flaws to my mind at all. They are features of the language that must be taken into account, when worrying about portability, just like C++'s nonstandard data types must be taken into account. In C++, you can never know the size of an integer or a long when writing (portable) code; it always must be discovered at runtime, since C++ sets no standard data sizes, only required minimum storage sizes. Yet C++ is a highly portable language, within its purview; if set data type sizes had been built in from the beginning, we'd never have pointers of 64 bits, after all; they'd be sixteen or smaller! Nonetheless, assuming that an "unsigned char" is one byte makes for hypothetically unportable code, though in reality this will always be fine, since it is such an established convention that no compiler writer would ever alter the size of the char data type nowadays. Bah, my mind wanders again. Anyway, the quirks mentioned are akin to, say, Visual Basic's automatic 1-based array indexing feature; it could be forced to index arrays at 0 with the "Option Base 0" directive, but this provided portability problems. Regardless, Visual Basic 6 was virtually the best language out there for what it was meant to do: rapidly develop business applications, whether simple or complex, where efficiency of execution time was not a major consideration; only morons would try to build applications in VB 6 which were computationally intensive, but to build a simple program for your secretary to track appointments or the like, no other language could compete.
I think what you have here is a similar idea of PHP as many had about VB 6; the superficial design quirks and flaws are blinding you to the power of the language, when applied in the right arena. When people tried to write huge, complicated, data-intensive systems in VB 6, they found it to be woefully inadequate; this should have been obvious at the outset! A language for which a function to add two numbers equates to 42 machine instructions is not designed for that, whereas C++ (with about six to twelve machine instructions, depending on architecture) most certainly is, as long as you know what you're doing. Similarly, array efficiency is only important if my PHP site is geting millions of hits a day, and if that were the case I would either stick with PHP but design a multi-tiered and distributed web-serving and data-management system, or write a C-based CGI application using some off-the-shelf CGI libraries to simplify my life. (The former is, incidentally, not as hard as you'd suspect, really; many large web businesses are somehow married to the fact that a $500,000 server will solve their latency problems, when a trivial array of a dozen or so older web servers would do the trick for less than three thousand dollars in hardware costs and setup; a distributed network of antiquated Sun Microsystems SPARC Ultra 1s, with clock speeds of 350 MHz (keep in mind they are RISC) will do amazing things, let me tell you, and they run about $50 apiece on eBay these days.) Well, I guess the point of all this rambling is this: end results are all that matter; I would rather have an efficient system in terms of time and money than an elegant one, and PHP is very fast to develop in (saving development and code maintenance costs) and is not significantly less efficient than other languages in time or space, when deployed in a reasonable manner and with a backend data architecture designed well. What irks me about the astonishing desire to make everything elegant, as opposed to quick to write or powerful, is the end result; you get encapsulation of data objects like in the .NET architecture. If I create some highly abstract "data connection" between half a dozen foreign key relationship fields in a database, and then the system gives me my dataset, I can guarantee that the SQL it generates will be hortribly unoptimized for any nontrivial query. If, instead, I use the simple DataReader class .NET provides, and supply my own SQL, I have an application whose SQL is harder to port, but which will run hundreds of times faster, making hardware costs minimal and latency very short. Encapsulation and other clean degisn principles are usually good, but I detest them when they make their way into the cores of complicated systems, since they are rarely ever efficient when applied to their logical conclusions. Considering the powerful refactoring tools available today, there is no excuse for writing methods to get and set variables inside classes that are private to other classes anyway, but are used in time-criticalm subsystems . . . if you REALLY must have encapsulated methods, refactor them in later. A good IDE can do it in a quarter second. I suppose, though, that refactoring applies less to PHP, since its object-oriented model is not very full-fledged in the first place, and since I am not aware of any good refactoring systems for the language. Nonetheless, the basic point remains valid; when you are worried about efficiency, use efficient language constructs (and to Hell with fluffy software engineering practices when time is really critical; the rest of the program can be software-engineered to your heart's content) and languages, or compensate in good hardware design (which is NOT the same as expensive hardware).
I do apologize for my rambling, but yesterday was my six-month anniversary, and so it was a late night out celebrating. Also, I should get an account here; these anonymous posts are confusing to follow clearly. Adieu!

# posted by Anonymous : 10:50 AM

One other thing, though; the idea that changing the php.ini settings is a valid way to overcome the portability problems of magic_quotes and register_globals and the like is astonishingly wrong. The original poster had the right idea about these as portability issues of some consequence, since not everyone hosts their own servers, and therefore not everyone has access to the initialization files and directive. It is best, if you are truly mindful of portability, to encapsulate these features out by simple functions (see? I'm not a total anti-encapsulation Nazi :-) ), or to presume they are always off in some cases where being on provides extra functionality, not different functionality from when they are off. While I maintain that these checks are not a fundamental problem, or even anything a programmer should be overly concerned about since a function call takes three seconds to type (and would be necessary anyway when dealing with escaping database field data; see my first (long) post about PHP in the radio station), the fact that you can "edit the options yourself" is not a valid solution to portability. On this, myself and the original poster certainly agree.

# posted by Anonymous : 10:57 AM

I've posted a response to your rant elsewhere:
http://www.daholygoat.com/jaws/html/index.php?gadget=Blog&action=SingleView&id=8

# posted by daholygoat : 5:21 AM

I find your entire article rather ignorant and somewhat school-girlish. How can you possibly be even remotely qualified to give any kind of adequate opinion on something you piddled with for a few days.

I've been developing using PHP as my primary language for over 6 years. I would totally agree that there are some annoying issues with it (as with all languages) and that the majority of the code I see out there makes me sick. However, like all languages, you need to use it for some time, get used to it's little nuances and expectations. And of course you need to adapt to new ways of doing things that you used to do in other languages. Some thing are easier, some are more difficult.

PHP, more that the other languages I've used, has been extremely flexible and has allowed me to be creative while allowing me to create very robust and complex systems.

Bottom line: An idiot is going to write idiot code regardless of what language he's using.

# posted by Brian Grayless : 12:48 PM

I'm a young developer (17, soon to be 18), and I have been working with PHP for close to 5 years. It was the first language I learned outside of HTML (granted, neither are programming, they're scripting). I agree with a lot you have said. I hate how features are just thrown in. I also hate how PHP5 breaks a lot of PHP4 apps. However, many work fine. I run a server with PHP5 and rarely have trouble running anything on it. And if it doesn't work, no big deal. Most of the stuff I look at is to poke around in anyway. I've been looking around at Rails and I like what I see. Sadly, PHP is a lot more common on web servers than Ruby/Rails.
# posted by James Logsdon : 7:17 PM

Hey Ellis, it could also mean that you are inexperienced and see a problem where there isn't one, or that you are overrating a design annoyance.

All languages have design flaws/annoyances somewhere along the road. Some people can see more contingencies ahead and do a system design that contemplates them, and others just complain about magic quotes in their pajamas while having chocolate icecream.

To me, when someone says "language X sucks" is a sign that they are language Y advocates, and discussions like that often lead nowhere.
# posted by Anonymous : 6:19 AM

Humor

BBspot - Student Suspended Over Suspected Use of PHP By Brian Briggs

Topeka, KS - High school sophomore Brett Tyson was suspended today after teachers learned he may be using PHP.

"A teacher overheard him say that he was using PHP, and as part of our Zero-Tolerance policy against drug use, he was immediately suspended. No questions asked," said Principal Clyde Thurlow. "We're not quite sure what PHP is, but we suspect it may be a derivative of PCP, or maybe a new designer drug like GHB."

Parents are frightened by the discovery of this new menace in their children's school, and are demanding the school do something. "We heard that he found out about PHP at school on the internet. There may even be a PHP web ring operating on school grounds," said irate parent Carol Blessing. "School is supposed to be teaching our kids how to read and write. Not about dangerous drugs like PHP."

In response to parental demands the school has reconfigured its internet WatchDog software to block access to all internet sites mentioning PHP. Officials say this should prevent any other students from falling prey like Brett Tyson did. They have also stepped up locker searches and brought in drug sniffing dogs.

Interviews with students suggested that PHP use is wide spread around the school, but is particularly concentrated in the geeky nerd population. When contacted by BBspot.com, Brett Tyson said, "I don't know what the hell is going on dude, but this suspension gives me more time for fraggin'. Yee haw!"

PHP is a hypertext preprocessor, which sounds very dangerous. It is believed that many users started by using Perl and moved on to the more powerful PHP. For more information on how to recognize if your child may be using PHP please visit http://www.php.net.

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers : Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda : SE quotes : Language Design and Programming Quotes : Random IT-related quotes : Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce : Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 : Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds : Larry Wall : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS : Programming Languages History : PL/1 : Simula 67 : C : History of GCC development : Scripting Languages : Perl history : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month : How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater�s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

Copyright � 1996-2021 by Softpanorama Society. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.

This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

You can use PayPal to to buy a cup of coffee for authors of this site

Disclaimer:

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: May, 29, 2021

Softpanorama May the source be with you, but remember the KISS principle ;-)	Home	Switchboard	Unix Administration	Red Hat	TCP/IP Networks	Neoliberalism	Toxic Managers
	(slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and bastardization of classic Unix

News	Scripting Languages	Recommended Links	LAMP	Recommended Papers	Tutorials and Sample Chapters
PHP on AIX	Reference	DB Scripting	MySQL	ACID
Command line PHP	Many faces of Facebook	History and philosophy	Debugging	Critique	Humor

Top Visited <p>Your browser does not support iframes.</p>					Switchboard
					Latest
					Past week
					Past month

Oracle Develop 2007 - PHP Presentations
	Scale Your PHP Application to Tens of Thousands of Connections
	The Way to the Web with PHP and Oracle Database

Recent Oracle+PHP Cookbook Recipes
	Creating an Ajax Process Using PHP
	Building a Locator with ZIP Data
	Creating Oracle-Powered SOAP Services in PHP
	Online PayPal Payments with PHP
	Adding Google-like Search Operators to Simple Search Boxes
	Read More Recipes... \| Read other Tech Articles...

Sample Book Chapters
	Oracle Database 10g Express Edition PHP Web Programming from Oracle Press
	Learning PHP5 from O'Reilly & Associates
	PHP Cookbook from O'Reilly & Associates
	PHP Programming from O'Reilly & Associates