PHP 5.2.0 Released

ShaunC writes "The PHP Group and Zend have released PHP 5.2.0, and upgrades are encouraged. The 5.2.0 update offers several security fixes, including patches for a couple recently announced buffer overflows in input parsing. This release also includes a number of library upgrades, bug fixes, and default bundling of the popular JSON extension to help with AJAX development. See the full changelog for more details."

Comments

What backwards compatibility has it broken?

[melonman]

Our company does web hosting, and every single time we get an enquiry involving PHP it comes with a caveat along the lines of "but I need version 4.x.y with version z of the q module and safe mode turned off". The best one yet was someone who wanted us to promise never to upgrade PHP because his XSLT module needs pre-version 4.4 - a bit of googling revealed that there's a whole section of the PHP community hunting for servers that will never upgrade for that reason. We never ever get this with perl, because backwards compatibility works over decades.

Re:What backwards compatibility has it broken?

[CopaceticOpus]

First of all, it's trivial to run two versions of PHP on the same server, and to use one version or the other on a per-directory or per-file basis. So there's no reason old code needs to stop being run if it's still useful.

Secondofly, the changes from back around 4.0 to where we are now with 5.2 are fundamentally huge, and they move PHP to a much more serious, professional class. Breaking backwards compatibility was worth it. It's sad that there has been so much resistance to change. Personally, these changes are the reason I now favor PHP as my language of choice for web development.

Re:Oh look...

[mrjb]

In my not so humble opinion, PHP does not deserve the reputation of being a toy language- I've found it stable and functional enough for very serious stuff (here in Holland, the eBay company "Marktplaats.nl" runs on PHP).

Yes, it has backwards compatibility issues. Most any upgrade path does. I personally deal with this by wrapping core functionality into a library. I've written sites that are insensitive to PHP versioning- they work equally well on PHP 3, 4 and 5. Programmers that require a specific PHP version 4.4.something should be ashamed of themselves.

There are a lot of good reasons to use PHP:
- PHP is very accessible, it is very easy to start working with
- Very stable
- it offers a ton of functionality right out of the box
- No need to buy extra components for trivial functionality such as reading binary files
- It's free (as in beer/speech), just like perl
- ...but it doesn't "feel" quite as complex as perl, partially because of
- the excellent documentation- which blows the competition out of the water.

Most likely, being this accessible causes it to attract quite a lot of not-so-experienced programmers. Which is probably the *real* problem. The main complaint I hear people make about PHP is that invariably, the sites built with it are a huge mess. Don't blame the language for that- blame its users.

Re:Perl vs PHP

[ImustDIE]

Perl is stable -- Perl 5 has been out what... 10 years now? CPAN is also an amazing module repository and makes installing modules a breeze. Perl is also more powerful than php, and the syntax allows for certain things to be done more succinctly.

The best thing about PHP is that it's easy. The syntax is simpler than Perl, so it is easier to pick up. It also has a ton of built-in functionality so you don't have to go looking for modules as often, but that mass of bundled functionality combined with the fact that PHP doesn't have namespaces makes for a mess, compounded by the fact that the included functions are often named inconsistently.

Having done hundreds of thousands of lines of code in both languages, I favor perl; but don't hate PHP either. Both have tons of documentation (PHP's being more newbie friendly, but Perl's being more extensive). Both are very fast when coded properly.

Argh.

[Balinares]

Urbanradar,

Your comment pisses me off, but there's something I want to say all the same: I think you are, essentially, right. Whatever one's woes with PHP might be, they don't justify trolling and unsubstantiated mouthing off. Besides, "toy language" is a purely inflammatory statement that doesn't even have any factual content.

However.

However, the implicit underlying assumption I think I perceive in your comment -- that PHP criticism must be trolling -- annoys me a lot. Please allow me to expand on this.

You see, one constant characteristic of the Internet in general is the noise. Look here on Slashdot: do you read all the comments on any given story?

The noise is a bigger problem than you'd think. The noise means that it's hard to get heard. It means that to be heard, unless you're a remarkable writer (which I, and most people, aren't), you have to exaggerate your message. "PHP is a toy language" is one such exaggeration; and perhaps even actually worthy of being modded up if followed with factual information to support it. And much likelier to catch a moderator's attention with its use of strong language.

Which you would, undoubtedly, consider a troll all the same, wouldn't you?

As you can probably guess by now, I have crates of such information against PHP. (In my defense, I do try hard to gather evidence against my own tools of choice as well, for two reasons. One, being aware of their own idiosyncrasies allows me to work better with them. Two, it's a simple matter of intellectual honesty.)

The vagaries of life have landed me into a managerial-ish position in a small company that develops and hosts large-scale PHP websites. My responsibility here is twofold: ensuring that the sites work, and ensuring that they keep working.

I didn't know PHP before joining this company; I had a generally positive opinion of it beforehand, from reading Slashdot. So I got to discover it through that new role.

Let us just say, to put it mildly, that my opinion of PHP has quickly become very poor.

I think that managing a language's design and development is one of those jobs that's freaking damn hard. It takes a LOT of experience, critical thinking, introspection, knowing to prioritize issues, knowing to tap into the decades of experience in language design to understand what works and what doesn't, why, and in what context. And different people with different backgrounds and objectives are more or less successful with it.

And I don't feel the people behind PHP -- I'm sorry, guys, I don't know how to put it nicely... -- are doing the best possible job of it.

More precisely, my primary issue with PHP is its culture as a project. Cultures are inherently difficult to describe, but if I had to put it in a few words, I'd call it the "Works for me" culture.

Simply put, the sort of attitude that PHP seems to encourage -- by which I mean, the shortest-path-to-arrival approach to doing most things in PHP -- work fine for the developper producing the code, but are formally broken in a way that WILL come back to bite the ass of whomever poor dude is in charge of keeping the thing working.

For instance: I understand PHP uses a function based on the tolower() C call to make method calls case insensitive, and leaves it at it. It works for them, doesn't it? Except that in the real world, it breaks. Deploying PHP sites on servers that use a Turkish locale yields blank pages. The workaround is to never use that particular locale. Easy, isn't it? No, it isn't: PHP's gettext functions for dynamic translation require the locale to be set appropriately (unlike that of other languages). And I have my Turkish clients on the phone a lot.

Until recently, before the introduction of PDO, the canonical native way of addressing databases was to use PHP functions named after the database itself (mysql_*, etc, making the process of migrating databases, or creating a site that may have to be deployed client-side on varying database backends, an utte

Re:Argh.

[Balinares]

All of my criteria? None. That's my point. There is no technology that doesn't deserve its share of criticism.

(Actually, asking people what their preferred tools' most important drawbacks are is generally a good litmus test for their competence. If they can't tell you what the pitfalls are and how to work around them, or why they don't affect the task at hand, watch out.)

Simply, some tools are a better match than others for any given task.

For instance, I think that PHP makes for a good, simple and effective templating language.

But of course, there's a world of difference between 'HTML templating' and 'development, deployment and ongoing maintenance of a Web site or set of sites.'

And no, I'm not going to tell you what I personally favor for the tasks in question in this thread. That's not the point. What matters is not the tools I favor, but WHY I favor them. It is important that you figure out for yourself what makes for a suitable tool, from your own experience, because that's how you'll know how to make the best use of that tool, and what to watch for.

The next, much trickier step, is to figure out where your own blind spots are, and learn to take them into account when making your choices. (Mine, for instance, tend to involve underestimating the importance of community support -- a point where PHP, incidentally, scores high.)

I hope I'm not sounding too patronizing here (I'm not very good at finding the right tone in online forums). I'm no better than any other computer dude who's had to deal with a wide set of technologies and their respective fans. But I learnt what I did thanks to other people sharing their experience, and I can only hope that, by sharing my views on what I think really matters at heart, I can help others broaden their own experience. The first step toward learning, after all, is recognizing that there's stuff you need to learn.

Mod Parent Up!

[Builder]

This post explains most of my issues with PHP far more eloquently than I ever could.

Arghmen

[Bogtha]

I think this is what people mean when they call the management and design of the PHP language 'amateurish'. Blatant lack of good engineering practice.

Totally agree 100%. Another example: did you ever use nl2br() to convert newlines into <br> elements? It's an extremely common thing to do. In a minor patch release, they changed the function to generate XHTML instead of HTML. In one stroke, everybody who thought they were generating valid HTML had errors in their code. This might not sound that bad, until you realise that nl2br() can appear a lot in large projects, there's no way to get the old behaviour of nl2br() back, and if you have a decent QA process in place, you'd be being notified of the errors across all the websites you maintain. You end up having to go back and change all your code to use generic string replacement functions.

Now, maybe you might say that it's a sensible thing to change (I disagree, there should be different functions for HTML and XHTML), but at the very least, they should have put a change in semantics in a major version update, not sneaked it in between 4.0.4 and 4.0.5.

It's not really the design of the language that's the real problem (although it's not pretty), it's the cavalier attitude from people who don't seem to take a professional attitude to their work that really grates.

Re:Arghmen

[nuzak]

Amen to the cavalier attitude. You know about PHP's Javascript-esque === operator? (that's the one with three equals signs). That got designed on the spot in an IRC session with Zeev and some other devs. Because I actually had to explain to these folks what the concept of "object identity" was, i.e. what lisp does with 'eq', python does with 'is', and Javascript does with ===. Yes, because PHP's is different. Not only does === fail to do object identity testing, it's simply '==', does all the "deep comparison" of ==, but also bothers to compare the type.

In other words, I was unsuccessful in explaining this rather basic concept. They got it blisteringly wrong, and hacked this wrongness into the language for all time. I attempted to explain (much more patiently than here) that no, this is not what === is supposed to do, but I wasn't heard. Not by Zeev, not by anyone else on channel. No one got it at all.

I passionately hated PHP for a long time after that, but it's just not relevant enough to my work anymore to hate. I have choices, I don't have outside clients demanding I use PHP anymore, and my choice of languages is respected where I work. I've chosen python for some projects, perl for another, C++ for another (the C++ one was of course not web). I could probably write my next project in Haskell and no one would bat an eye (though I will be stuck with maintaining it for all eternity). I'm even eying Prado -- a PHP library -- for an upcoming project, though I've still no desire whatsoever to write actual business logic in PHP, so it'll have to be solely at the view end of things.

Re:Perl vs PHP

[Qbertino]

PHP is a descendent of Perl - it was originally programmed in Perl to extend Perl with templating functionality. That's long ago, but it still shows in the overall quirkyness of PHP wich is of a simular 'flavour'.

That been said, PHP has by far the largest set of available tools to help you do big projects of any web-oriented PL. Tons of commercial and/or OSS IDEs (PHPEclipse - especially the easyeclipse distribution - is awesome for a free tool), Debuggers, etc. It's pratically maried to MySQL (tons of tools aswell) and half of googles database is filled with PHP tutorials and forum threads on common PHP/MySQL gotchas.

If you want to do web stuff and unless you're in on some super complex parsing and data migration problem I'd strongly recommend PHP. If you're doing serial data-migration and plan on heavy use of Regular Expressions to solve your problem or have some other exotic procedural problem to solve that doesn't involve building a webapp, I'd suggest Perl over PHP. ... I'd actually recommend looking at Python aswell (my personal favourite), but that's not what you asked for. ;-)