On Sat, Mar 5, 2016 at 7:00 AM, Fleshgrinder <p...@fleshgrinder.com> wrote:
> On 3/5/2016 2:33 PM, Lester Caine wrote: > > On 05/03/16 11:26, Fleshgrinder wrote: > >> PHP being a mess is still one of the most quoted arguments against PHP! > >> > >>>> Only if it results in an actual and measurable improvement. Changes > for > >>>> "purity" or "consistency" do NOT fall into this category. > > > >> This is your believe and you know that many people disagrees with you on > >> this; you just commented on the "[RFC] Deprecations for PHP 7.1" thread > >> and we have much more of those RFCs and threads. > > > > There are a number of schools of thought, one will say 'You don't have > > to update your perfectly functional code', just use a version of PHP > > that it will run on, so over 40% of users are 'stuck' with Php5.2/3 > > either because they don't have the support to change or the need to > > change. Much of that code was written by people who are no longer > > involved or interested and so unless others pick up the baton, there > > will be little progress. I still run 5.2 on sites simply because it's > > simply uneconomic to change them. > > > > Now moving code forward, handling every warning and simply keeping code > > running from version to version, one hits the problem that sites that > > are reliant on older versions of PHP can't easily be run with newer > > versions. I've managed to build a way around that problem by now running > > php-fpm/nginx which allows me to actually run the same code across > > multiple versions of PHP. But one has to be very careful about just what > > is changed at each step, so in my book, unless there is some good > > security reason to stop something working then it should remain for BC > > reasons. > > > > Others are of the opinion that all current PHP code is a mess and my > > reaction to that is ... well use a different language then! ... > > expecting the vast majority of users to rename every function ( on of > > the proposals for PHP7 ) or switch to a strictly typed method of working > > is simply not going to happen, so I have no problem with people adding > > new extensions which allow these different sytles of working as long as > > the underlying procedural style of working is maintained in as BC a way > > as possible, so things like 'var' and a number of the 7.1 deprecation > > proposals simply destroy BC with little gain to a pure OO based version > > of PHP anyway. > > > > I actually wonder what would have happened if there had been a stable > > fork of PHP5.2 maintained, with security fixes, rather than the > > piecemeal security fixes that are currently being applied on those > > services that maintain PHP5.2/3 currently. > > But then again, we are talking about removal and real BC in 6 to 9 years > and support for code that is already roughly 11 years old; so up to 20 > years old then. I guess nobody would ever consider rewriting that code > and instead simply write it anew. > > -- > Richard "Fleshgrinder" Fussenegger > > For software written for other people and for projects that don't have ongoing tech staffs that do tech debt maintenance, they would like to keep old, working code running. Telling them that they must spend money to update the software so that the language can look cleaning is often a hard sell. Outside of the PHP world, there are code bases that are 20-30 years old. See Linux, Apache HTTPD, in-house software at many corporations. One of the lessons of the Y2K rollover was that software choices made in the 50-60's (and in some cases the actual software itself) was felt 40-50 years later because the software wasn't rewritten anew every 10-20 years. Some companies treat software like capital assets and not as expendables. They want it to last like a house and not be be replaced every 5-10 years (like many cars). Walter -- The greatest dangers to liberty lurk in insidious encroachment by men of zeal, well-meaning but without understanding. -- Justice Louis D. Brandeis
