4 ms·

That looks a lot like a claim that software only deserves to exist if it is made by, or attracts the fanatical devotion of, people who have a deep love of maint

That looks a lot like a claim that software only deserves to exist if it is made by, or attracts the fanatical devotion of, people who have a deep love of maintaining software against a moving target. Ugh. The expectation that once you've made something you can't expect it to keep working without endless catchup, attitudes like this one, are why I have completely given up making software for fun or to solve noncommercial problems for myself and others. I'm not the only one.

WJW 4y ago
> 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 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?
- themaninthedark 4y ago
  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.
  - yetanotherloser 4y ago
    Thank you. You put it better than I did.
  - fnordpiglet 4y ago
    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.
- yetanotherloser 4y ago
  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.
fnordpiglet 4y ago
I feel you. But the challenge is supporting ancient apis and abis over time greatly complicates the underling runtime. There’s a natural tension between flexibility for the evolving system that adapts to modern needs and techniques and hardware and one that runs ancient runtimes in perpetuity. Things have gone back and forth over time and the winner tends to be the simplest one, which is apis stay stable over some lifetime until some well advertised horizon then things stop working if they don’t make the effort to evolve. Just like I don’t expect to be able to plug in a old mainframe RLO drive into my MacBook M2Max and have it work, you can’t plausibly expect ancient runtimes to work forever. That said, a lot of effort goes into writing emulators, and I’d expect this specific software will see a second life at some point

WJW 4y ago

> 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 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?

themaninthedark 4y ago
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.
- yetanotherloser 4y ago
  Thank you. You put it better than I did.
- fnordpiglet 4y ago
  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.
yetanotherloser 4y ago
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.

fnordpiglet 4y ago

I feel you. But the challenge is supporting ancient apis and abis over time greatly complicates the underling runtime. There’s a natural tension between flexibility for the evolving system that adapts to modern needs and techniques and hardware and one that runs ancient runtimes in perpetuity. Things have gone back and forth over time and the winner tends to be the simplest one, which is apis stay stable over some lifetime until some well advertised horizon then things stop working if they don’t make the effort to evolve. Just like I don’t expect to be able to plug in a old mainframe RLO drive into my MacBook M2Max and have it work, you can’t plausibly expect ancient runtimes to work forever. That said, a lot of effort goes into writing emulators, and I’d expect this specific software will see a second life at some point