On 03/05/2016 12:26 PM, Walter Parker wrote:
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
That is correct; there are many, many old codebases of many different
languages out there. However, you need to consider in what way such
software is maintained. Let's start with Linux and Apache. Both of those
pieces of software are _not_ in "maintenance" mode. They are both in
active development, and as such are living, changing codebases that are
being continually updated to have new features, bugfixes, and
compatibility with newer compilers, systems, and libraries.
Now consider some in-house software that is in maintenance only, as
there are also many of those. Assume one such software is written in C.
Let me ask you: are you going to compile such software with the latest
version of libc and using the C11 standard with the compiler? Of course
not! The likelihood of it compiling bug- and error-free is too common,
with functions removed in C11 and memory layouts changing in the last 30
years of libc. You would compile such a program with the appropriate
versions of its dependencies.
Now I'm not saying any of this is good or bad, I'm just saying it the
way it is. If you have 40+ year old software that you can't afford to
continually update, you should continue to use the best versions of
stuff that are still compatible. If you can afford to update small parts
to be compatible with newer systems, then do so. (I'm talking like
changing a few lines of code or maybe more to use a new function instead
of an old, deprecated one.)
In the PHP world (which is a tad bit different, since you can't ship
"binaries" compiled 10 years ago), the equivalent would be to run
10-year-old software on the best version of PHP that it is compatible
with; 5.6 (hopefully; maybe older, maybe newer -- depends on the
program). Now how long we backport security and bug fixes to old
versions is a completely different discussion, but I hope you get my
meaning.
--
Stephen
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
