Recent events have brought about PHP’s biggest PR disaster to date, with yet more backward-compatibility bugs being marked bogus and such helpful advice from PHP’s inner circle as “…just stfu, okay?”.
This is the latest in a trend that is raising the ire of many of PHP’s brightest developers and casts a worrying shadow over the future of PHP as a serious web application platform. Many have pointed out how difficult it is to maintain claims of PHP’s enterprise readiness when said enterprise projects stop functioning after a PHP point “upgrade”.
There appears to be a noticeable exodus from the skilled top ranks of PHP developers to other community driven languages (Python, Ruby et al) in recent months. What will the future PHP landscape be like if/when the Marcus’s say enough is enough?
Will a shrinking pool of talented PHP open source developers create new opportunities for commercial PHP software production? Is this perhaps exactly what Zend is looking for?
Related posts:
- Is Ruby’s Popularity Fading? Ruby has enjoyed a ton of hype over the last...
- It’s All Go for Google Google is concerned that developers do not have enough choice...
- Top Ruby Frameworks Rails and Merb Join Forces It's not every day that two essentially competing web development...
- Are PHP Namespaces Really So Bad? Namespaces have caused a divide amongst developers who either love...
- Joyent Acquires Reasonably Smart to Take On Google App Engine Cloud-based web hosting provider Joyent announced the acquisition of Reasonably...
The BC issue is a very serious one and PHP core developer don’t seems to get it. I’m really sad about what’s going on since all our efforts to make big enterprise accept PHP as a good choise for their web needs are vanished by all this BC break.
We’ve worked in PHP for 6 years and we love this language but with all this mess we’ve finally taken the decision to seriously start looking at JSP and .NET for an alternative with better acceptance from enterprise.
This is all really sad, I think that Zend should spend more effort in these issues instead of doing deals with IBM for DB2 support which is great but I don’t think will affect the userbase too much :)
September 15th, 2005 at 7:55 pm
@ x/0 – thanks for not getting the difference between PHP and Zend.
@ the bogus bug
Using current() on a returned array seems very strange to me. list() is an alternative that works without any errors, is clearer and maybe faster.
The only real problem is in PHP 4 with objects. Something like “return new Foobar()” is used very often and in PHP4 you need to reference objects everywhere as much as possible.
But if you read the internals list you’d have seen Rasmus posts. He is already thinking about fixing some PHP functions and maybe the temp variable on return could be made implicit. Of course this stuff is not as sensational as Derick writing an acronym with fuck in it. But at least would it help to stop the current bashing – it already lasts long enough and gets more boring with every new posting about it.
September 15th, 2005 at 8:38 pm
Certainly BC issues annoy everyone who has to maintain software. Particularly if it is not easy to understanding the underlying reasons for a given change.
This has to be some of the most convoluted line of thinking I have seen posted. I followed your gist that you can annoy people into jumping ship, but I completely fail to see how this could lead to any possible benefit for Zend. Could you clarify this line of thinking?
September 15th, 2005 at 9:55 pm
I’ve been working with PHP for a long time, and I’m sticking with it. It is the best language and the most widely used. I don’t think that PHP is going anywhere anytime soon. Too many people use it for a living for it too leave too quick.
I personally don’t see the issue. Web host and such don’t use PHP5 at all, so why would this matter? By the time the host pick it up all the bugs will be fixed, and it will be ready to roll. There was some hype about bugs and bogus when PHP4 came out. It was awhile until every host adopted it. Same thing here.
September 15th, 2005 at 10:17 pm
Spreading FUD is never a good idea. Let’s examine the facts:
1) there is a serious problem in PHP versions 4.3.x and earlier, and 5.0.0-5.0.4, causing occasional random crashes
2) PHP 4.4.0 gives a notice upon actions that are known to cause the memory corruption that occasionally causes a crash
3) PHP 5.0.5 has a fatal error for the same corruption
4) the problem is at the Zend Engine level, and is extremely difficult to resolve, so a stopgap measure is in place to warn users and prevent the corruption.
Now let’s look at what has been going on with php-internals:
1) a lot of people who have never lifted a finger to help the core developers are very angry because php code they wrote or used that “just worked” is no longer working
2) core developers feel that the angriness is not helpful unless accompanied by solutions to the problem, and some have been rude in expressing this opinion.
3) work is being done to find a better solution, but it requires serious software design in order to avoid breaking other basic features in PHP.
Jules: the disinformation you post here does not serve PHP, Sitepoint, or PHP’s users. A casual read of php-internals would show you that there is no Zend agenda here. The people who are being rude do not work for or represent Zend, and you may not be aware of this, but most have been rude for a long time to people who come on php-internals and post unhelpful or stupid comments. I’ve had a few scathing critiques of my own comments on php-internals when they’re poorly thought-out, it is par for the course. The only difference is that now people like you are blogging about it as if this is some kind of world crisis rather than the way that an open source meritocracy works.
Let me put it another way: the way PHP development has worked is that complaining to php-general about problems is perfectly fine. You only post to php-internals with problems if you have a patch that might fix it, otherwise you are asking for a scalding response. I’m not saying I would run things this way, but this is how it has worked for years and PHP’s growth is a testament to the success of this approach. People who actually work on PHP don’t post stupid crap to php-internals very often. You would be wise to study this history before drawing ridiculous conclusions like a massive Zend conspiracy.
I am a big fan of backwards compatibility, and I think that there are other ways to solve this problem that should have been investigated more fully, but there is no crisis – the internals people understand there is a problem. Rasmus Lerdorf (remember him? PHP’s inventor?) has been posting quite a few messages with potential solutions to the problem that don’t break backwards compatibility.
Where do you hear of talented PHP developers jumping ship because of PHP 4.4.0? If this post were a piece of journalism, without some evidence to back this up, either your editor would cut that part or you’d be fired for making junk up and passing it off as fact.
So, in short, to anyone reading this post: in a few months, we will all be laughing at the lack of intelligence expressed with these opinions. Don’t pay any attention to it.
September 15th, 2005 at 10:41 pm
While I admit a good flame war can actually be quite fun it’s also a good indicator of exactly where we feel vulnerable. I hate admiting weakness in my code – better to point the blame to another link in the chain. Flaming is also an indicator that someone is a developer and not a marketer. A good marketer could be planning your murder while hugging and kissing you for the camera. Developers just say what they think. Alas, we should acknowlege that there is still a place for tact and general manners even for us developers.
Backward compatibility is pretty important and had better start getting the recognition it deserves pronto or there will be consequences. Good coding is important too. Some explanations are in order.
September 15th, 2005 at 11:25 pm
Given a choice between fixing a bug at the cost of a BC break and leaving the bug around at the frustration of those being bitten by it, there is no right choice. Someone will feel maligned and slighted. All that’s left is to accept that someone will get the short end of the stick and look at it from a disempassioned stance: Is it better to fix a bug, or not?
Do you really need help answering that question?
September 15th, 2005 at 11:43 pm
charmedlover I would suggest that some of the larger enterprise businesses that the people above are talking about would be running their own webservers meaning that backwards compatibility is a very big issue.
The last thing I want as a developer for this industry is to receive a call from the IT manager saying that the e-commerce system that I implemented is not working only to find out it is because their IT staff was conscientious enough to ensure that their software is up to date.
Why should that company have to pay me to come in a fix something and at the same time why should I have to suck up the costs because a point release of PHP wasn’t completely backwards compatible?
No one is suggesting the PHP is no good, simply that backwards compatibility needs to be of paramount importance for PHP to keep chipping away at this market.
I hope I have understood the issues correctly.
Colin
September 16th, 2005 at 1:36 am
this is a good point, and have noticed hints of this. I have made the choice to learn java as my primary and learn php along the way. at least thats the way I’m thinking about it now.
I had a dicussion about this w/ my DB admin, and server admins the other day, and they stressed this.
September 16th, 2005 at 2:21 am
Personally I think PHP is on the way out.
I’m still developing in 4.3, unsure of the requirements and syntax changes of 5, but this is where I call it a day.
I enjoy coding and learning new things about PHP, it’s a dead easy language to learn and fun to develop in.
An excellent introduction into programming as my first language and I would recommend it to anyone wanting to step into the development arena.
For the last 3 years, i’ve been using c#.NET. It’s been easy to get into because of my prior programming experience with PHP, and the Object-Orientated Programming model in c# has accelerated me into using classes in PHP.
But at the pace that PHP releases at, it won’t be able to catch up with the microsoft .NET machine… i’ll continue to use both, but I don’t think i’ll moving forward with PHP.
From what i’ve been reading it looks like Ruby on Rails is the preferred platform now for wannabe-developers, so maybe the childish elements of the community will move away from PHP onto the Ruby community, or maybe they’ll just mature into men one day.
I’d like to say im a seasoned programmer in both PHP and c#.NET now, and my personal advice is to get ready to switch over, the ship is sinking and you need to jump boat.
September 16th, 2005 at 4:43 am
Backward compatibillity is a complete show stopper of any progress!
Take a good look at PC world:
think about what could have happened if Windows were not forced to be compatible with DOS software?
what would happen with Intel processors if Pentium was not forced to be compatible with 8088?
Who made a biggest breakthrough in last 10 years? Apple! Why?
Because they were not afraid to f… off backward compatibillity!!!
If !(ready to learn and change code to better version) then (get out of this bussines)
September 16th, 2005 at 7:19 am
BC is a show stopper is you don’t provide a way to maintain it. Other companies like Microsoft and Oracle provide in their database engine a version key that you can change to force the database to be compatible with a specific version. While most people ignore and never play with that setting it becomes very usefull when you need to “re-enable” features that were dropped because your application.
The big dilemna (if there is such a dilemna) could be resolved by adding such a setting withing the PHP engine. This way, developpers who’d rather live with bugs at the cost of compatibility could, those wou’d rather fix their own code to benifit from the latest and greats could too.
Maybe Zend should look into that.
But then again… BC is a problem when upgrading the engine. Any upgrade is a risk that comes with a price. That should be no surprise to any serious developer. The answer is short: if the cost of upgrading (i.e. gaining new features and bug fixes) does not outweight the cost of ensuring that your software works with the new version then don’t.
Microsoft breaks BC in their office suite with every major version, they even had problems with BC between the release 1 and 1.1 or .NET, did anybody complain about it and made a fuss… not that I know of.
September 16th, 2005 at 9:22 am
The last thing I want as a developer for this industry is to receive a call from the IT manager saying that the e-commerce system that I implemented is not working only to find out it is because their IT staff was conscientious enough to ensure that their software is up to date.
Why should that company have to pay me to come in a fix something and at the same time why should I have to suck up the costs because a point release of PHP wasn’t completely backwards compatible?
If the code that you’d delivered was flawed in that it attempted to return references to objects that didn’t exist as vars and was known to cause memory corruption, as a professional one would hope that you’d fix that without charging your customer anyway. To neglict to fix the problem and then feign outrage that the language developers made it impossible for that type of bogus allocation to occur in the first place is really the height of intellectual dishonesty – they didn’t know how the reference operator worked in the first place and inadvertently took advantage of a bug within PHP. When it was noticed what the cause of the memory corruption was, they then should’ve patched their software and redeployed it. This, “but it was a bug that we thought was a feature,” simply isn’t cutting it. You don’t get to blame other for incompetence or disinterest when you’re exhibiting the slipshot attitude that you’re accusing other of having.
September 16th, 2005 at 9:35 am
Time to amend my comment above! (and apologize for the double post at the same time).
Breaking BC compatibility is something developpers have to deal with in any case. Dealing with comments from the people who manage the code base like I’ve read on is not.
September 16th, 2005 at 12:43 pm
It seems that the problem people have is that PHP heavyweights are complaining or being “unprofessional” about BC issues.
The people who manage Microsoft’s code base probably are just as bad, but they’re not Open-Source so their comments and discussions are rarely posted for the whole world to see.
I actually have a lot of old DOS games that require significant coaxing to run. For each one I’ve had to manually set memory settings and have to run plug-ins to mimic older video and sound cars.
Also, BC issues are far from uncommon. I’ve personally had many more issues with MySQL upgrades than PHP upgrades and I actually spent almost 2 weeks fixing CF sites when the hosting company upgraded to CFMX.
September 16th, 2005 at 2:32 pm
I would like to know what *exactly* is going to break my code.
Is there a place that discusses in more details what will and what won’t break (with examples)?
Cheers,
Ben
September 16th, 2005 at 9:39 pm
[quote]Web host and such don’t use PHP5 at all, so why would this matter?[/quote]
Most web hosts are running php5 now. In fact, up until this recent fatal error, PHP 4 code ran on the PHP5 installations without issue.
I fully expect that very few people will upgrade to 5.0.5 from 5.0.4, but will upgrade instead directly to 5.1 when it ships and a better solution is in place for the problem (along with all the php4-only stragglers).
[quote]I would like to know what *exactly* is going to break my code.
Is there a place that discusses in more details what will and what won’t break (with examples)?[/quote]
The ONLY thing that will break will be in cases where you’re attempting to return something that IS NOT A VARIABLE by reference. Check the php-internals mailing list (it’s on the php.net site) for more details.
September 17th, 2005 at 4:58 pm
@ccburns / Colin:
I’d also like to point out that you complained that you don’t feel you should have to come in to work because the IT staff decided to keep their software up to date…that’s all well and good, except for the fact that there was no testing done first. Who would roll out a completely new package on ANYTHING that is a business necessity without first testing something, especially if the old addage of “if it ain’t broke, don’t fix it” also applied in this instance?
Honestly, in this instance, I’d say it was the decision on the person to upgrade the entire live system’s fault. Granted, I think we’re talking theoretically, but even so. This event *should* never happen, although I’m sure it does.
September 18th, 2005 at 6:23 pm
I found this on the internal mailing list and am copying it her for reference purposes.
Written by Rasmus Lerdorf (14 Sep 02:25 comp.php.devel):
We have been looking to see if there is a way to fix the memory
corruption issue in a way that has less of an impact on existing code.
This doesn’t change the fact that every error you get is actually an
error in the code you are running. The broken code is effectively doing
something similar to:
function foo(&$arg) {
$arg = 4;
}
foo(strlen(”abc”));
which makes very little sense. There are many variations of this, but
in every instance it is something that should be fixed, and in some of
the cases it actually leads to memory corruption.
There are many examples of this sort of thing working just fine in PHP
4.3.x because people are passing things in by reference and never
modifying the passed in value. They’ll do something along the lines of:
function foo(&$arg) {
return $arg[0] + 1;
}
echo foo(array(1,2,3,4,5,6,7,8,9,10));
possibly because they believe that they are saving memory by not making
a copy of the array with that reference. Of course that is quite
misguided as no copy is done until the arg is modified so if you don’t
modify it, you are better off passing it by value.
Right now the change in 4.4 and 5.x is to complain loudly when you pass
a reference to something without any associated storage. In both of the
above examples there is no permanent storage associated with either of
the passed arguments, so trying to get a reference to this storage makes
very little sense. The only feasible way we might be able to work
around this is to make a copy of such bogus reference attempts and
effectively just pretend they were passed by value. I think it is a bit
of a hack, but at the same time the breakage of existing apps has been
more widespread than I think anybody anticipated. I’d still want to
throw a notice to let people know they are doing something odd though.
-Rasmus
September 18th, 2005 at 8:23 pm
If the issue is with the code “return new SomeClass()” not working, then yes this is a bug in PHP that needs to be fixed. That code was previously considered 100% valid, and should continue to be 100% valid.
http://bugs.php.net/bug.php?id=1991
That bug report is from 1999 acknowledging that they consider the above PHP statement to be valid back then. If so, then why is it suddenly sloppy coding, as some people on here are saying? I’ve been coding in PHP since about that time, and I expect code I wrote then for the 4.x series to continue to work now.
Grepping my project tree, I found 157 instances of the string “return new” both in my own code as well as in 3rd party packages we use. Perhaps that’s what caused on outcry of new users having strange problems recently that never happened before. BC is not just another nice-to-have, but the absolute most important thing to have. Several recent BC breaks in the PHP 4.3.x series have caused needless trouble for our customers, and I fear this may just be the cause of yet one more.
The people who say BC breaks need to stop are right. The only question that should be under discussion here is “how?” BC breaks should only ever be acceptable between *major* releases and with proper notice to developers. I have trouble enough with insidious BC breaks like the copy -> clone change from 4.x to 5.x, which means serious code review before we can declare PHP5 support, which is work which has zero value for us or our customers — ie. it’s a waste of time.
So I made a decision that our company won’t support PHP5 until we absolutely have to. Even compatibility mode — which can’t be turned on on a per-application basis, making it roughly useless for most of our would-be PHP5 users — isn’t 100% BC. This is a real issue with PHP, and it’s not flaming to say so. I’m glad somebody had the balls to say it. Cheers to them.
September 18th, 2005 at 9:06 pm
Here’s a suggestion. I don’t know if it’s a good one, but try it on:
How about having a process and a forum dedicated to the public review of major changes to PHP? “Major changes” would be new features, BC breaks, anything which would be of interest to more than a small minority of users.
September 21st, 2005 at 6:10 am
No, Lux.
return new Object();
is still perfectly valid. The problem is:
return substr($foo,0,4);
You can return objects by reference. ONLY objects.
Nico was wrong to suggest that
return new Foobar();
was invalid.
I bought into the FUD about backward compatibility. Guess what? When I finally upgraded, not a single line of my code had a problem. And of all the third party apps, only squirrelmail had any problems and that was 1 line in each of 4 files.
September 22nd, 2005 at 9:10 pm
Hi Rod,
Thanks for the clarification, that’s very encouraging to know. I’ve also run 4.4 without trouble myself with our software, so this one appears to not be an issue. We did have some BC issues with one of the 4.3.x series updates though, although we were able to resolve it fairly easily.
Cheers,
Lux
September 23rd, 2005 at 4:48 pm
Is this whole mess all about badly written code no longer working? Hasn’t that happened before with new PHP releases?
September 26th, 2005 at 2:36 pm
Rod says:
That’s incorrect. Since 4.4.0,
function &byRef() { return new Foo(); }
triggers one of the new kind of “Only variables can be returned…” notices – unless inside Foo()’s constructor $this is assigned by reference to something else. This is bogus, and the workaround “return $tmp =& new Foo()” is ridiculous. (bugs.php.net/33679)
October 11th, 2005 at 5:54 am
I’m sometimes wondering if some people arguing here are doing real work for real clients in a real world or just some cool little thingies for their scool classes or college courses.
My story:
Doing php since 1999 – running an IT company with several devs. Having about 200 sites (projects) out there. Having a web server farm with own projects as well as classical hosted sites not done by us on it.
I was able to switch from php 3 to php 4 and 5.
Now switching to 5.0.5 (A MINOR VERSION JUMP!!!) isn’t possible to me. It’s like committing suicide.
O.K. I can hear you saying: “I don’t understand why you use current() on a method – that’s ugly.” Well – nobody told me the last ~6 years!
I didn’t follow the internals list that much and I really didn’t look under php’s hood to see how this case is handled internally.
It seems that I started this ugly thing somewhere between 2003 and 2004 – well. I really thought that a thing that works without notice (all projects have E_ALL switched on) will work in the future (at least within a major version).
I can understand what Greg pointed out (as always).
But I’m really fed up when I read this theoretical “why did you ever do this ugly thing” blabla.
I will certainly not roll up 6 years of work to find every single case which leads to this problem. Why? Because I have to pay my monthly bills. Nobody will pay me for that AND – doing a current(Method) isn’t a BUG in my code which I HAVE to fix for my customers for free. Saying this is really ridiculous.
I think that we really need some kind of solution here.
And we need some kind of dialogue. The “this isn’t a bug – this is bogus – look into the changelog” thing isn’t the way to go.
October 20th, 2005 at 7:47 pm