Is it safe to abandon PHP4 yet?

[Carl]

To those that "don't need" php 5. I remember that I did not need ASP 3.0 for about 6 months after it's release. Then one fine day I wanted to transfer the processing of an application to another script. You could not do this in ASP 2.0 without doing some serious coding in the global.asx file. But lo' in ASP 3.0 there was sever.execute and server.transfer. I spent two months scrambling to learn ASP 3.0 after that. Suddenly all my scripts even the ones that I had gotten from FourGuysFromRolla became simpler and easier to work with.

Sooner or later there will be something in php5 that you need. Something simple. It probably is already there but since the new functions are not documented very well and have no examples they are hard to see as being better or helpful right now.

[KLB]

You already claimed that you don't program in PHP anymore.

No I said I don't program much extensive PHP programming. All of my websites are in PHP, its just that I have gotten their core code stabilized and don't have to do much in the way of updates. I do, however, touch PHP code on a daily basis. I just don't do much new coding because I have no need to.

The original poster asked if it is time to start developing in PHP5 or not. From what I can tell, you are only saying "there is no point for me to recode my current site to PHP5 because I no longer use PHP" -- which is fine, except that I don't see how that relates to the thread.

I have replied to the original request that there were several factors to consider whether to do PHP4 or PHP5, with a leaning towards them using PHP5 for an entirely new project. This thread, however, has evolved well beyond the original questions and in light of how this thread evolved, my posts are perfectly within the realm of this discussion and point out the flaws in the attitude that everyone should be doing PHP5 or even that web hosts should be supporting PHP5 at all.

Yes, major versions typically entail work because of breakage. That's not surprising, is it?

It's unacceptable. Only an arrogant developer would change a fundamental way a scripting language works (in this case the way variables work) and then expect everyone to update their code to accommodate the change. In my case this could decimate the way my scripts work and would require major redesigns. When I say $strA=$strB, I don't simply want a pointer to $strB. I want the value copied to $strA so that I can then change the value of $strB without affecting $strA. From what I gather from this thread, this is not how PHP5 works.

Jayboots, in the future I'd recommend not trying to attack the poster of points of view you don't like. Rather, I recommend you stick to the discussion and try to defend your position. Attacking the messenger might make for good entertainment on Fox News, but it isn't how to conduct a constructive dialog in these forums.

Some very good arguments have been brought forth against PHP5, and had the PHP developers properly addressed the issues people raised with PHP5, then there wouldn't be so much resistance towards embracing it. New is not always better, and I think given the cold reception PHP5 is being given by web developers and web hosts, it has seriously missed the mark and has some fundamental failings that will continue to hamper its adoption.

[dagfinn]

Suppose they did this...
1) PHP 4.9 allows proper cloning and deprecates the copy symantics of $a = $b for objects in fvour of $a = $b->clone(). That would have been the only change, the $a = &$b would stay, even encouraged.
2) PHP5 changes the symantics to $a = $b is a reference copy making the '&' redundant. It's declared deprecated. PHP5 would run a little slower, because it would have to perform object type checks whilst both systems were supported. Alternately an ini setting at teh start of teh script declares one behaviour or another to maintain performance.
3) PHP5.1 declares the & for object copying a notice.

They could have recognized these issues during PHP 5 beta if they had really wanted to. That would have given them time to dream up better solutions -- such as the ones you're proposing -- earlier.

Also, I suppose 90+ per cent of the occurences of '&' were (are) premature optimization in the first place. Yet another cautionary tale.

[lastcraft]

Hi...

It's unacceptable. Only an arrogant developer would change a fundamental way a scripting language works (in this case the way variables work) and then expect everyone to update their code to accommodate the change.

The PHP developers did get rather out of touch. Hopefully the recent uproar over PHP4.4 minor breakages (knackering notices in effect or polluting the code with dummy variables) will have sent a message. And managing PHP4 and PHP5 together will hopefully persuade them to get this right next time.

I think their level of arrogance is about average though.

When I say $strA=$strB, I don't simply want a pointer to $strB. I want the value copied to $strA so that I can then change the value of $strB without affecting $strA.

Strings stay the same (a very sensible decision). It's only object copying that has changed semantics. The change is a good thing, it just wasn't handled at all well.

yours, Marcus

[KLB]

I think their level of arrogance is about average though.

Your probably right there. I always hate the trepidation I have when I need to upgrade an MS-Access database to a new version of Access. Something always breaks. While par for the course, I find it unacceptable.

Strings stay the same (a very sensible decision). It's only object copying that has changed semantics. The change is a good thing, it just wasn't handled at all well.

Its been a long time since I had my computer science classes so some of the technical semantics of things like copying the value vs. addressing the memory location has slipped my mind. To date myself when I was taking CS classes in college, they were still teaching Fortran and C+. Things like PHP and .NET hadn't even been thought of. I can't say I have ever had much use for Fortran.

In regards to the PHP upgrade issue, there must be billions of lines of PHP4 scripts in use today, it seems unconscionable to not make sure that PHP5 was 100% backwards compatible with PHP4. At the very least, they could have thrown a flag in that could be used to say hey this code should use PHP5 "strict" and only then enforce the changes that break older code. This would have given web hosts the ability to upgrade to PHP5 without having to worry about also supporting PHP4 for all of the legacy code their clients were using.

[Dr Livingston]

Something always breaks. While par for the course, I find it unacceptable.

If you find something like this as being unacceptable, then maybe you need to look for another profession huh?

When you make steps to move forwards, you have to expect that everything isn't going to go smoothly; That is part and parcel of software development. There are just way too many factors to consider, and to account for when a new release is made available, that not everything can be caught - due to time constraints for example, to mean a deadline.

There is just so much that you, Marcus, et al are not looking at, but rather you are quick - way too quick for my liking actually - to shoot down someone or something.

[MstrBob]

Everybody always gets upset when languages (or any software) gets upgraded and what used to work now doesn't. I'm sorry, but to expect that the Software is going to make major improvements and remain completely backwards compatible is just plain silly. If you're going to implement major changes then API changes can be unavoidable. With a language, like PHP, the whole point is to improve the language. To think you can do that without making any semantic changes between versions is inane. PHP 5 is NOT compatible completely with PHP 4 - and that's a good thing. It's not being held back by backwards compatibility. If you don't want to recode to work with PHP 5 you are free to not use it. If the developers were held back my concerns of backwards compatibility, let's face it, PHP would get big and bloaty trying to add on a new layer of functionality while still dragging the weight of older compatibility. PHP 4 code won't neccessarily work in PHP 5, and that's a good thing. Because PHP 5 is different in many ways, something I didn't realize until I sat down and started writing a PHP 5 app, and wouldn't have realized for much longer if I was intent on simply porting my PHP 4 apps and coding methodology over with little or no change to PHP 5. So, au contraire to what some people are saying, PHP 5's non backwards compatibility is a great feature!

[Carl]

I'm sorry, but to expect that the Software is going to make major improvements and remain completely backwards compatible is just plain silly. If you're going to implement major changes then API changes can be unavoidable. With a language, like PHP, the whole point is to improve the language. To think you can do that without making any semantic changes between versions is inane.

Especially since almost all of backwards compatibility problems are the fault of coder not the language programmer. A coders refusal to learn how to use the language in a manner that does not call for great changes in structure due to lack of polymorphism and planning is almost always the problem. Then the users of that code suffer and blame the language programmers for making changes that expose the bad coding of the software.

When I see how quickly Typo3, phpBB ezPublish and others made changes to their code bases inorder to make them compatible with the latest version of php4 it makes me shake my head in disgust. I look at the changes and how much better and simpler the code bacame and ask myself why did they not code it this way in the first place? Why are they trying the make the language programmer look bad by even alluding to changes in the language being the problem? Why don't they admit it was their own fult for having crappy coding style or taking shortcuts?

[Archbob]

You have to get the acceptance of the majority of the PHP using crowd and that isn't happening if you don' offer good backwards compatibiliy. But really the only things that are breaking is the psuedo-OO code used in 4. I'm still using 4 because support for 5 isn't all that great yet.

[Dr Livingston]

I look at the changes and how much better and simpler the code bacame and ask myself why did they not code it this way in the first place?

Human nature being what it is, it's lot easier just to get something out, shortest possible route, and damn proper software practices.

That's a short term view to take on software development and it will always sooner or later, jump up and bite you on the a*** Then refactoring to accommodate new changes in a language take more effort, costs spiral out of control, etc.

Even if langauge changes seam just or not; Be that they are good or bad, the developer should be well versed in the language to tackle those changes; They should have the maturity and the experience just to get on with the job and not bleat and moan and grumble about all the unjustices in the world.

As to why no one will admit to their own failings, there are any number of reasons I suppose.

[Archbob]

You see, as soon as I write code in 5, it won't work in four and the majority of clients still use four. So if I just decide to switch to 5, I lose alot of my client base. Thats a huge problem.

[arborint]

Let me get this straight.

What I understand MstrBob and Carl and Dr Livingston are saying is that smart programmers can deal with upgrade issues and it is programmers fault for the majority of problems and slowness in upgrading to PHP5 from PHP4.

What I understand dagfinn and lastcraft and KLB are saying is that the PHP language developers should deal with upgrade issues and it is the language developers fault for the majority of problems and slowness in upgrading to PHP5 from PHP4.

I certainly think there is responsablity on both sides. However, from a strictly project management the point of view it seems like it would be easier to manage the much smaller group of PHP language developers on upgrade issues than trying to manage the much larger and diverse group of all PHP programmers.

From a software architecture point of view it seems like the language and libraries are a lower layer on which programmers using that language have a dependency. Doing a poor job on a lower layer often means having to make changes to a lot of dependent code; whereas doing a poor job on upper layer code often only means having to make changes to that specific code itself.

[Viflux]

I think this issue really lends evidence to the difference between PHP and it's user base, when compared with a more traditional developer environment.

In my non-PHP related experience (admittedly rather thin), you simply don't upgrade just to wave a flag saying "We have the latest and greatest!". If we chose to use the upgrade, it was for future versions of the software.

Did .NET developers rush to upgrade their apps when .NET 2.0 was released? Not in our house. We are, however, using the new release for all future development. Going back and updating our already working code does nobody any good.

There is no point in going back and upgrading all of our working applications so that they can now be powered by a different engine.

Of course, this kind of progression (running the old, working PHP4 code alongside the new, working PHP5 code) is hampered by the apparent difficulty in running the 2 setups side-by-side. I say apparent because I haven't tried it, nor do I care to, but based on the comments in this post, it isn't a simple matter.

[LinhGB]

Of course, this kind of progression (running the old, working PHP4 code alongside the new, working PHP5 code) is hampered by the apparent difficulty in running the 2 setups side-by-side. I say apparent because I haven't tried it, nor do I care to, but based on the comments in this post, it isn't a simple matter.

Essentially that's the issue. If it were easy to run the two side by side, nobody would whinge about adopting PHP5. I've been playing with PHP5 for a while and love it, so I'll get a new server just for PHP5 development and coding future sites in PHP5. I wish I could move my old stuff over but it's just too much work (too many projects pouring in, not that it's a bad thing ), not to mention the open source webapps I use aren't PHP5 compatible. While this approach (having separated servers for both languages) works for me, most people either can't afford having separated servers just for PHP, or they want to make their apps run on as many setups as possible (which is then related to the former).

I read earlier in this thread that it's possible to have PHP4 and 5 running side by side without making one run as a CGI, some sort of reverse proxy tricks. Could the PHP5 advocates share those tricks with us? It'll help your arguments and this discussion a lot.

[Archbob]

I develop mainly GPL and free software for everyone that is free to use. I can't just start coding software that won't work for the majority of servers so thats one major reason for me to keep writing php4 code.

[MstrBob]

What I understand MstrBob and Carl and Dr Livingston are saying is that smart programmers can deal with upgrade issues and it is programmers fault for the majority of problems and slowness in upgrading to PHP5 from PHP4.

No, actually, I didn't. I don't like it when people put words in my mouth.

My point was that we shouldn't get upset about the fact that PHP 5 isn't backwards compatible - it'd be unneccesary bloat. I do agree on the point that this whole mess would be a lot easier if you could run the two Modules side-by-side, that I think the developers could have at least done to mitigate the problems. Developers should do what they can to mitigate the problems of transition (without, of course, negatively affecting the new product) but they shouldn't have to keep it backwards compatible.

In the end, as always, there are a number of contributing factors. The inability to run the two languages side by side. Not all major PHP apps are PHP 5 compatible. There's no economic incentive for hosts to support PHP 5 (yet). The sheer size of the PHP user base means there are a lot of people who aren't early adopters/are less tech savvy/are waiting for PHP 5 to mature/or for whatever reason don't upgrade quickly. I think it's a fact of life that the more users you have the slower it takes the userbase as a whole to upgrade.

Sure, blame can get passed around, but as we've seen you can pass the blame on anyone and at the end of the discussion we'll still be nowhere.

[wwb_99]

Did .NET developers rush to upgrade their apps when .NET 2.0 was released? Not in our house. We are, however, using the new release for all future development. Going back and updating our already working code does nobody any good.

Actually, .NET is a great example of how to handle a significant version upgrade correctly. Unlike php, one can run multiple versions of .NET in parallel without any complication. They each reside in separate folders, use separate configuration information and do not in any way conflict. Furthermore, applications can dictate which version of the framework they are compatible with.

Hopefully the PHP developers look at this example and make it so one can run multiple versions of PHP in parallel without too much trickery.

[dagfinn]

I think their level of arrogance is about average though.

At the risk of being thoroughly flamed, I would say it seems to be a particular kind of arrogance that's common among developers but far from universal. It's the attitude that "we're the foremost technical experts, therefore our perspective is more valid and valuable than the others". The idea that submitting a patch is a "contribution" -- and reporting a bug isn't -- is a symptom of this. As I've said before, it's a pecking order.

It's an idea that doesn't foster a community. It's hurts quality, it's bad for human relationships and bad for business. The PHP developers need to learn that, and I think they are learning.

I realize that what I'm saying may seem arrogant as well. That doesn't invalidate my point, though. I'm trying to understand the nature of the problem rather than blame someone for it. I'm trying to name the systemic -- not the personal -- reasons for some of the issues we've been through. It's a problem of culture, not individual character.

[AvengeX]

I think people should keep up to date with versions of PHP, a hosting client of mine asked for us to roll back the server back to PHP 4 last night to test a script and to be honest he was laughed at for his ignorance and selfishness. An hour of labour configuring and reconfiguring? I don't think so.

Since PHP.net are already talking about PHP6, I think it's about time people did make the move to PHP 4. There isn't much difference between the versions in my opinion, though the coding has become a lot more strict which isn't a bad thing.

[KLB]

I think people should keep up to date with versions of PHP,

Only if there is business sense to upgrading. From a business perspective why update to the latest version of PHP if there isn't going to be a pay off for the time and effort that must be spent testing and rewriting scripts? This is no different than companies not upgrading to the latest version of Microsoft Office when it comes out. Most of my clients who I do database development for are still running on Office 2000 even though Office XP came out almost three years ago. The current version of Windows Server is 2003 yet Windows Server 2000 is still the predominate server.

From what I have seen with PHP5, there is no compelling reason that justifies the expense of upgrading as it will force way too much testing and reworking of code. As they say, if it ain't broke, don't fix it. PHP4 and my scripts aren't broken so I'm not going to ask my web host to upgrade to PHP5.

People have stated that we need to basically suck it up and upgrade and that it is normal to have to rework code because it is just the way it is. This is a BS attitude that we see from Microsoft. There are probably billions of lines of PHP4 based scripts in this world and probably less than 100,000 lines of code for PHP5 itself. It would have been way more cost effective to make sure PHP5 either played nice with PHP4 by running beside really easily or making sure that PHP5 was fully backwards compatible.

If the developers of PHP really want to see people adopt the latest and greatest version of PHP, they need to take a few humility pills and a dose of reality. Then they need look at the impact of upgrading and make sure it is as smooth and painless as possible. As we have seen if they don't do this the masses aren't going to upgrade as it is better from a business perspective to stick with what works and is stable than to poor money into something new that breaks existing code.

[sweatje]

If the developers of PHP really want to see people adopt the latest and greatest version of PHP, they need to take a few humility pills and a dose of reality. Then they need look at the impact of upgrading and make sure it is as smooth and painless as possible. As we have seen if they don't do this the masses aren't going to upgrade as it is better from a business perspective to stick with what works and is stable than to poor money into something new that breaks existing code.

The PHP Group does not intentionally go out of their way to break backwards compatibility. They actually do their utmost to keep PHP backwards compatable. Each decision with regards to BC must be evaluated with respect to performance, stability and security.

So the business decision which hosts must make is to force clients to touch their code to clean it up, or to host the old scripts on increasingly less secure, slower version of PHP with potential intermittant failures. This situation will likely only continue to get worse as the gap between fixes to PHP5 and the frozen PHP4 widens. At some point the pain will become sufficient to merit the upgrade.

[KLB]

The PHP Group does not intentionally go out of their way to break backwards compatibility. They actually do their utmost to keep PHP backwards compatable. Each decision with regards to BC must be evaluated with respect to performance, stability and security.

None of this would have been affected by taking simple programming steps to make sure PHP5 ran beside PHP4 cleanly (e.g. using different INI files and allowing for different folder locations). Even if what you said was true and PHP5 couldn't be made backwards compatible at least if it played nice with PHP4 then web hosts would be more likely to run parallel installs of it, which would allow customers like me play with and migrate to PHP5 on our timetable. If my web host had arbitrarily set an upgrade date that forced me to fix my scripts on their time table, and my script broke because of PHP5, there would be hell to pay.

What PHP developers don't seem to understand is that if the new product doesn't meet our needs and address the issues end users are most concerned with, it is not going to be adopted it is that simple.

So the business decision which hosts must make is to force clients to touch their code to clean it up, or to host the old scripts on increasingly less secure, slower version of PHP with potential intermittant failures. This situation will likely only continue to get worse as the gap between fixes to PHP5 and the frozen PHP4 widens. At some point the pain will become sufficient to merit the upgrade.

FUD is a poor reason to upgrade. The only true concern from this statement is security. If this caused an issue, it could very well cause a fork in PHP4 where those who still use PHP4 decide to support it on their own. For many, the pain of upgrading could be a far more bitter pill than worrying about the issues you have mentioned in regards to not upgrading. Would my site run faster under PHP5 compared to PHP4, maybe but who cares improved performance isn't an issue I'm worried about. My site has never experienced intermittent failures under PHP4 so why would it start now?

May there come a point in time when there is sufficient merit to upgrade PHP? Yes maybe there will be, but that doesn't mean we need to do it today nor does that mean the upgrade will be to PHP5. I'm sure that if PHP6 provides a compelling reason to upgrade it will get adopted. The risk the PHP developers are facing with non-backward compatible upgrades is alienating their user base resulting in a rebellion where users and web hosts decide PHP4 is good enough and never upgrade. PHP5 may turn out to be a failed version that gets skipped over by the vast majority of those who use or support PHP.

[sweatje]

FUD is a poor reason to upgrade. The only true concern from this statement is security. If this caused an issue, it could very well cause a fork in PHP4 where those who still use PHP4 decide to support it on their own.

I believe security issues are now the only things being back ported to the PHP4 branch. Technically, you should be able to stay on PHP4 as long as it is tollerable.

I also have not expereinced the intermittant failures which were the cause of some of the recent reference handling changes, but this was sited as the reason for the BC change. I guess a stack corruption that does not happen to affect you now is still a potential lurking danger.

[Dr Livingston]

At some point the pain will become sufficient to merit the upgrade.

For those who are too farsighted to see this, I do hope it actually hurts... You need to get burnt to learn something I say...

[KLB]

I believe security issues are now the only things being back ported to the PHP4 branch. Technically, you should be able to stay on PHP4 as long as it is tollerable.

You know the sad irony is that a lot of people like myself who haven't yet played with PHP5 might have actually started playing with it and would have migrated our sites if we were able to gradually transition. If it requires an abrupt and massive migration every time a new version of PHP comes out, it won't be worth the hassle of implementing every version of PHP. In this case since I know that PHP6 will be fully released within a couple of years, it makes business sense to me to sit tight on PHP4 and simply jump to PHP6 when the time comes rather than migrating to PHP5 now and then migrating again to PHP6 later.

Maybe if I were writing thousands of lines of code every month, I would at PHP5 differently but I only write a couple hundred lines of code at most in any given month so it doesn't make sense to invest the time necessary to fully take advantage of the changes with PHP5 and then do this again for PHP6. I don't want to perpetually updating code and relearning programming techniques simply to accommodate changes to PHP. I have much better things to spend my time on like making money.