Here's one good reason why i still put my faith in PHP.

As a developer with over a million lines of PHP code to maintain, I don't want the headache of keeping up to date with the latest gee-whiz features that break backward compatibility. PHP5 is great because by sticking to a few simple rules, I have code that runs well on both PHP4 and 5.

Rasmus Lerdorf was brainstorming the other day and suggested some wholesale changes for PHP6. I presume the post was just to test the waters, but I was frightened to see so many of the brilliant programmers (who design and develop PHP internals) were keen on breaking backward compatibility. Fortunately, I found the biggest voice of reason was Zeev Suraski:

At 20:48 12/08/2005, Rasmus Lerdorf wrote:
>Since we are breaking a lot of stuff in 6.0, at least with
>Unicode_semantics=On I am wondering if it may not be time to break some
>more stuff and do a bit of spring cleaning.  It would mean many apps
>would need some work to work on PHP 6, but at the same time I think it
>is work people would welcome since it would mostly involve removing
>hacks instead of adding them.  And yes, I know this is pretty
>controversial, so take a few deep breaths before replying, please.

First of all, in general - I don't subscribe to the school of 'we broke 
something, why not break more'.  With every feature we break, we reduce the 
chances of people upgrading, of legacy apps working, and we reduce the 
overall success chances of the new version.  Compatibility breakup is not 
binary, it accumulates.  The more features are broken, the worse the 
situation becomes.

>1. Remove register_globals completely
>
>2. Remove magic_quotes_*

Given what I said above, I don't see any motivation to remove 
register_globals or magic_quotes.  I don't see how it buys us anything 
other than pissed off users and hordes of (sometimes exploitable) bugs that 
will result from sloppy audits.  These changes alone would mean that a 
great deal of the applications would have to be 100% audited before an 
upgrade.  Between us, developers welcoming forced labor due to upgrades is 
wishful thinking.  People never like to be forced to go over their or other 
people's code regardless of the circumstances.

If we are to do anything about register_globals, perhaps we can change the 
name of the directive to something else (e.g. unprotected_globals), and of 
course keep its default 0.  Admins will have to make an informed decision 
to turn it on again, and we can speak against it as strongly as we want in 
an upgrade guide.

Change the default of magic_quotes_gpc to 0 as well.

>3. Add input filter extension which will include a mechanism for
>    application developers to very easily turn it off which would swap
>    the raw GPC arrays back in case the site had it turned on by default.

Sounds good.

>4. Include an opcode cache by default.  A lot of work has gone into
>    pecl/apc recently, but I am not hung up on which one goes in.

Need to think about that one.

>5. Remove safe_mode and focus on open_basedir

Sounds good.

>6. Remove some stuff that has been marked deprecated since PHP 3/4
>
>A couple of others that we could consider, but I don't actually think
>wins us much apart from academic purity (which I have never been all
>that keen on) are:
>
>7. Make identifiers case-sensitive
>
>8. Remove various function aliases

As I'm sure you'd agree, academic purity is not exactly why PHP won the 
hearts of the masses.  I would almost argue the opposite.  Features which 
only bother us due to academic purity are clearly ones we shouldn't 
touch.  Even more so than register_globals and magic_quotes - which are not 
only impure but also problematic - there's no point forcing people to 
modify their code just because we feel like making PHP more academically 
pure.  Other than creating a huge worldwide mess and slowing down 
migration, we're not going to gain anything (assuming we don't get any 
points for academic purity;  PHP scored 100 when handed in as an academic 
project, by the way :).

Even if we forget about the users, and only think about ourselves - unless 
something drastic happens, we're going to look at supporting 4 major 
different versions simultaneously - 4.3/4.4, 5.0, 5.1 and 6.0.  Is it 
really such a great idea to start breaking compatibility beyond what we 
absolutely have to?

I think you have some good ideas in that list, and some less good 
ideas.  I'm worried about the wholesale mode that internals@ switched into, 
the almost unanimous "YES!" response, and the overall feeling that suddenly 
with 6.0  breakage comes without a price.  That goes counter to our key 
design goals in the Unicode support, which were work-as-if-nothing-happened 
when unicode support is disabled.

Zeev

So as long as someone like Zeev helms takes an active role in PHP development, I feel I'm in safe hands.

PS: To me, magic quotes and register globals should be removed, but I can understand that others might disagree.