On 3/6/2016 7:07 AM, Stephen Coakley wrote: > 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.
This explanation matches my experience at companies as well. They either use old systems (e.g. Windows XP is still in use at many companies in Germany because there software was programmed against it) or old software (Java 8 broke with Java 7, so did Java 7 with Java 6, so did ...) and they simply do not bother to update at all. Not the code, not the system, nor the software. @Tony Marston: you are always saying that "this is "longevity" [...] they will move on to another language" but I do not see such a language, not a single one. There are those who break with every release (node.js), those who break hard with a major release (Python), and those who are carefully crafted to contain proper CHANGELOGs, upgrade paths, deprecations, ... (Java, C derivatives) and then there is PHP where it is completely random based on the people who saw the actual thread on the mailing list and shouted the loudest. Removing old or bad features is absolutely normal and it is what is being done in good languages. You want to keep your interfaces clean and easy to understand. You do not want them to be cluttered with unnecessary features, aliases, argument swapping, ... Expecting to write some code without any kind of maintenance while expecting the systems and software to ensure it runs for the next decades without any kind of issues is naive. -- Richard "Fleshgrinder" Fussenegger
signature.asc
Description: OpenPGP digital signature
