Hacker News Reader

Comment by WJW | Hacker News Reader

> The expectation that once you've made something you can't expect it to keep working

I don't think there is a single type of item in the world for which you could expect it to keep existing indefinitely without maintenance. Machines rust, wood degrades, paintings need restoring every few centuries. And even when properly stored in controlled atmosphere etc, books from a few centuries ago are almost unreadable because the language has changed so much since then (see https://web.cn.edu/kwheeler/diagram_4english.html for example).

Everything in this world needs constant maintenance or it breaks down. Why would you expect software to be any different?

View on HN

I expect it to be different because it is different.

Machines rusting and painting needing restoration is because they oxidize. Wood does not magically degrade, it decomposes. These are physical phenomena confined to the physical world.

Your example of the book being unreadable because people's language changed, that is a closer example but even that falls short because language is a human to human communication pathway. We have to spend literal years training people to understand it, it is inherently chaotic and messy.

Software is math, it is engineered. We don't wake up to find that suddenly the coefficient of friction is different and now our tires fail to grip the road. Or more to the point, that our speed and feed calculators are now trash and will crash the endmill into material ruining the machine and part.

Computers and their ability to run or not run software after and update is completely in the control of the people programing the updates. The reason so much software fails is because either A. It was not well designed to begin with or B. the people creating the update did not design it well.

Thank you. You put it better than I did.

Except software isn’t math. Math is entirely self contained and self defining. Software has dependencies in hardware and other software that are not contained in the software. A better analogy is the symbolism of an algebra and way of expressing math. While calculus hasn’t changed for techniques known at the time, fluxions aren’t supported as a method and symbology while a derivation of liebnitz’ notation is. The math is invariant but the symbology and evaluation methods change with time.

Likewise hardware architectures change, and it’s absurd to assert machine code from the Eniac must run on every architecture, as well as every variation of every machine ever made on every future hardware in perpetuity. There are to this point many preservation efforts that create emulators that run on modern hardware or reference virtual machines that can be carried forward. But to expect this to be done in situ everywhere all the time for everything is on the surface absurd and unreasonable to an extreme.

Edit: the Eniac didn’t have machine code, but switches and wiring - even more to my point. While it’s still just math and logic, it’s not reasonable to carry forward all software configurations of the machine.

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.

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.

Reply on news.ycombinator.com