It puts a beautiful spotlight on OSS communities and what they do to keep software alive through refactoring, iteration, patching. Also, on well-written documentation— perhaps that's even more important than the code for longterm maintenence and value. A good thesis that encourages someone to write it again, and better?
I was reading about terminal text editors (em, en, vi, vim, neovim, etc.), and it's interesting how some of the software that "lasts" is more like Theseus' Ship. All the original components replaced over time, but the core concepts last.
There's probably a lesson about interfaces here. The thing itself is able to last and adapt if you're able to replace the components, and the components can be replaced if the interfaces between them are stable (or at least knowable, so you can change them and know what you're changing). A couple of the examples I can think of that try to do this are Linux and Clojure. Both have improved and added a ton over the years, but they've always focused on maintaining stable interfaces.
I feel like releasing it as a win32 app covers you best there
[0] https://www.thereformedprogrammer.net/how-to-update-a-nuget-...
You'd write (or buy) software for a purpose, and once it was debugged and installed, it was done. You just ran it after that. It was not exposed to external attackers, it didn't need to ever be updated unless new features were needed. In some cases (i.e. games on ROM cartridges) it couldn't be updated.
This is part of why Y2K was such an issue. So much old software was never intended to be updated. Preservation of original sources and build tools wasn't well managed. In many cases, software that had been in use for years or decades just had to be completely replaced because there was no practical way to update it.
Right now it's this:
- HTML/CSS/vanilla JS for the UI. If it renders on a browser now I expect it to render almost the same in 20 years.
- SQLite: It's a library that sure will be alive, maintained and API compatible in the future.
- Go: The Go 1 compatibility promise applies here. Also, trying to reduce external dependencies as much as possible (SQLite lib should use standard DB api)
Sure you can use C or Java, but Go strikes the right balance for me (also personal preference for its philosophy and ecosystem)
It's a nice thought experiment in a time when you leave a NextJS project for a year and it ages like milk.
The trend towards unstandardized languages that only exist as a single blessed implementation, as opposed to languages defined by an official standards document with multiple implementations that are all on the same footing, is definitely an artifact of the Internet era: You don't "need" a standard if everyone can get an implementation from the same development team, for some definition of "need" I suppose.
If your horizon is only 20 years, Go is likely reasonable. Google will probably still exist and not be an Oracle subsidiary or anything similarly nasty in that period. OTOH, you might have said the same thing about staid, stable old AT&T in 1981...
underdeserver•1mo ago
dgroshev•1mo ago