Just because your drop saw burns out in 10 years that doesn't automatically make my code obsolete in 10 years.

I can make a same counter argument using the same logic. I have a car that runs fine well past 10 year mark. Why can't I expect a software do the same?

Your car didn’t run for 10 years without any maintenance. It’s not unreasonable to expect someone to click build once a decade either.

You did not depend on the manufacturer to do that maintenance. The manufacturer could have even gone out of business and you could still fix or find someone to fix your car.

You however depend on the original developer to click that build button because proprietary software. If it was FLOSS, you could.

But don't worry, thanks to DRMed parts you won't be able to fix anything on your car either (or phone, or any other smart device) without the involvement of the original manufacturer. Ain't property wonderful when the manufacturers intelectual property has precedence over your physical property?

/s

I think you misunderstood the analogy - the app is the car, not the parts. Once you correct that it’s easy to understand why the rest of your message doesn’t make sense.

Not running on modern architecture does make it obsolete in the same way that stuff that’s only available on punch card is obsolete.

Why is it up to others to spend resources supporting backwards compatibility instead of you to keep your code compiled for modern arch?

They’re different tools though. I’m sure Elsevier makes that same argument about text books

In life sciences, knowledge stagnates and rots. An undergrad-level Pathophysiology textbook published 10 years ago would probably mention that Alzheimer’s dementia is caused by the formation of plaques in the brain.

This might not be apparent to engineers who see everything as a formula waiting to be solved from first principles.

I am in life sciences! While you can find some examples of things becoming outdated you don’t need entire new textbooks. Addenda/errata can be appended to the document. Or the instructor can point out the error and teach the new “truth”

You’re right; smaller-scale changes can be captured in errata.

However, some things move pretty quick and warrant updates to the whole document especially when the document is used a handbook in critical situations. The ACLS protocol manual, updated quinquennially, comes to mind.

Than you agree and are missing the point.

Some textbook publishers are intentionally making small changes from year to year to intentionally make the life of those using second hand text books miserable.

Corporations have long since realised that often their biggest competition comes from their own products therefore we now have planned obsolescence (someone who already has your product and doesn't want to buy another) and the war on secondary markets (someone other than you selling your, old, product).

Because software is more like the song on a record than a record player: I have songs that were bought on vinyl, transferred to cassette, then transferred again from vinyl to CD, then from CD onto my computer as digital files, then copied from device to device for the last 2 decades. The record player, in contrast, died years ago.

Software's even better! Since it was inherently digital to begin with, I'm able to make leaps like that with ZERO data loss! The only thing that kills software permanently is planned obsolesce. It doesn't matter what the lifetime of your saw is, that's like arguing that you should be free to shoot nonagenarians because most people don't live that long anyway. It's not about how long other stuff lasts, it's about the fact that it was perfectly capable of going on living until it was killed.

Tools often have serviceable parts. A burnt out motor is just worn out carbon brushes, which are easily replaceable.