3 ms·

This is a wholly false analogy. If I store most things properly they decay only very slowly and most maintenance tasks are easy. The software equivalent of that

This is a wholly false analogy. If I store most things properly they decay only very slowly and most maintenance tasks are easy. The software equivalent of that is only making sure I don't lose something to bit rot. No software lasts long enough for that, I look away for a year or so and someone broke something it stands on. It's not analogous to keeping an old book in a safe, it's analogous to keeping an old book in the street while random strangers queue up to piss on it. I have books up to 500 years old that are perfectly readable. I have programs I wrote single digit years ago that I'd need to give up a couple of days just to find out if I can get their build chain back and dig them out of dependency hell. Not worth it to buy, at best, a few years before I get to repeat the experience. Restoring and rebuilding old physical things is also far more rewarding because when I do it properly I never have to do it again.

WJW 4y ago
You seem to be cherrypicking the heirloom quality physical items and comparing them to programs that were constructed with not nearly as much care. I've owned physical objects that were worthless a few months (cheap throwaway), and have also worked on code that was over 5 decades old and still compiled just fine. If you construct the software with care it is entirely feasible to have something that you can run several decades from now, but that does mean that you shouldn't use dependencies which might disappear in that time. Curl or sqlite are probably fine, a dependency with a single maintainer is probably not fine. Network dependencies on DNS or NTP are probably fine, depending on the API of some 1-year old startup is almost certainly not fine.