11–20 of 28 posts
The gear shop I worked in had a 1970 GE computer that used punched mylar tape controlling a 50 HP CNC lathe up to 2019 when they were acquired.
I have Flash games that are 20 years old that can still be played on Newgrounds or in the Flash archives. In fact I found out recently that a change was made in the Ruffle emulator specifically to allow one of my games to be played (it calls it out by name in the PR), which is pretty cool.
I worked on two Wiiware games and a Sony PSP game almost 15 years ago that you can still find in ROM collections.
For js this is what I have in mind. 1) You set and forget it, ie you work on it now or for a few years but eventually you’ll stop developing it and just let it live. 2) if the host provider dies (eg github pages goes away) you can easily deploy on the next provider. 3) you won’t ever rebuild it nor expect dependencies to be updated.
As a realistic example of this case, react is approaching 10y. I have small webapps I build with react in 2016, I certainly can’t rebuild them now, but the js produced in 2016 perfectly works. And if I want to improve them it’s faster to recreate them from scratch than going through the pain of upgrading (I actually did it for an app to learn svelte).
C/C++ for me it’s the case when you want to be able to recompile, that also means likely be able to compile on a platform that will be available in the future but is not available now. Cobol/Fortran are too old, go/rust are too new. Java I don’t know enough. But your main issue will be dependencies.
Rereading what I wrote, I think the main issue I see are external dependencies, if you really want to survive you should limit them to a minimum (or assume you won’t need access to them).
Choices... Have a goal and call it done one day. Refuse to do any legacy support upgrades, only bug fixes. No external dependencies.
I think what youre talking about is a huge problem, you can't build a technologically advanced civilization if your foundation is built on shifting sand. Unfortunately, we don't yet know how to do it because all this is so new, and because the incentives are the opposite of what you need to make it happen. You tell a guy that when he's done he's fired and he will find a way to never be done. Very few will be excited to move on to something new after bearing their creation.
Software is well… “soft” it must be flexible and ready to change 100% when requirements, context, environment, people change.
Im both sorry for and angry at those stubborn close minded developers who dream of creating a perfect system that will last forever — this is an ignorant utopian goal.
Please stop feeding your ego - you are not an architect of landmarks, you are just an engineer serving current business needs.
* Minimize your footprint and test space in your application by eliminating features and options.
* Eliminate use of external dependencies. That means abandoning certain utilities and writing your own as necessary.
* Couple your application tightly to a given piece of hardware, like a very primitive RaspPi or some small hardware controller.
* Provide documentation. Keep it precise yet small, like a wrist watch instruction manual.
* Carefully consider your approach to data storage, if necessary. This can be a database or a file system or something else. Keep it primitive. Speed and cleverness are not important when the primary goal is archival.
* Consider the physical and chemical nature of the hardware. Metals degrade over time and plastic becomes brittle. A purely glass, crystal, or other silicon based media could last many thousands of years in isolation.