> If you cannot update your code to stop relying on deprecated functionality, your code is not actually economically important — people spend time and money maintaining things that are economically important.
I think this view is mistaken. Tools that only need small changes rarely are some of the most valuable, because they produce value at minimal cost.
> ...existing code that has been maintained to not use features marked deprecated, obsolescent, or removed in the past ten years is important; unmaintained code and existing implementations are not.
I understand that you can't support legacy code forever, but we need to get away from this idea that ten years is a long time for software to run, or that only software undergoing constant churn is worth anything.
Aaron is speaking from experience in trying to get support for prototype-less functions in C removed, something which imposes a surprisingly high burden in the compiler and has been deprecated for over 30 years... and still received a lot of pushback because of the potential of breaking code that hadn't been touched in that time.
> I understand that you can't support legacy code forever, but we need to get away from this idea that ten years is a long time for software to run, or that only software undergoing constant churn is worth anything.
The specific issue here is the code which lies at the intersection of the three categories:
1. Code that is N decades old and still in active use.
2. Code that needs to be compiled by the latest and greatest compiler versions.
3. Code that no one is willing to invest the resources in to make any changes to keep compiling.
That intersection is quite small, if not empty entirely. Consider the programming language with the longest pedigree, Fortran, nearing its 70th birthday, with a large amount of code very firmly meeting the first criterion... and yet I don't think any modern compiler supports anything pre-Fortran 77.
This though highlights a grave problem. Rather than code which everybody understands (which could easily be re-written for a newer language) this is code which nobody understands. Replacing this code is in fact urgent.
Replacing the code may be in fact impossible exactly because nobody understands it, while it still fulfills a vital business function (or sometimes a vital hobbyist function). There is a lot of code like that out in the world.
In this particular case the change required (K&R to ANSI C) is such a mechanical exercise anyone with a modicum of C experience can perform successfully. We’re not talking about decades of taxation rules encoded with COBOL here.
I think this view is mistaken. Tools that only need small changes rarely are some of the most valuable, because they produce value at minimal cost.
> ...existing code that has been maintained to not use features marked deprecated, obsolescent, or removed in the past ten years is important; unmaintained code and existing implementations are not.
I understand that you can't support legacy code forever, but we need to get away from this idea that ten years is a long time for software to run, or that only software undergoing constant churn is worth anything.