alt Hacker NewsIt's ridiculous that everything is expected to be maintained on a weekly basis.
In the past we had software stacks where once code is written it's just done, it will keep working years and even decades later.
E.g. https://sapaclisp.common-lisp.dev/ you can download code written in 1993 and just load it in latest SBCL.
Replies
Different languages definitely have differently expectations and cultures around this stuff. If an npm package hasn’t been updated in 2 years, I’m suspicious. I’m gonna check the downloads, check GitHub issues and stuff to see kind of problems people are having, Google around to see if people are using something else.
If a clojars package hasn’t been updated in 6 years, I don’t even think about it!!
Anything connected to the internet or integrated with 3rd party systems will have to be maintained regularly forever. Anything that is self contained will last forever.
Main reason I avoid buying anything that requires an app. Because one day that app won't be maintained anymore and it just wont work, bricking the hardware in the process.
This. The core problem is that people assume that all software is necessarily unreliable.
The fact is because they themselves are not capable of producing perfectly reliable software, they assume that everyone else is the same. With this narrow-minded worldview, you would expect software to require constant updates as the maintainer is essentially playing a never-ending game of whac-a-mole.
Not all technologies change. Often, low-level engine APIs are very stable and essentially never change... So why should the software built on top change?
According to OP, the kind of reliable software that we need in the AI slop era would fall in the category of 'dead project'. So they are doomed to create AI slop on top of other AI slop. Good luck to them.
This again! Software can be both _mature_ and _useful_. If you trip across a piece of software that's both of mature and useful, your first action should be clone it's git repo into your own storage and save project state. Then you should work against your repo posting pull requests for the greater community. But if no one consumes the pull requests, move on.
Different times. The need to patch for security updates alone is increasing rapidly.
The reality I keep running into: software that "just works for years" requires dependency hygiene at the ecosystem level, not just the application level. You can write Common Lisp or C or even most of Go that way and your code will still run in 20 years. The moment you depend on a modern frontend framework or even a modern backend one, you've committed to following its release cadence — which is often "we deprecate things twice a year."
Framework authors have their own incentives (relevance, employment, hiring funnel) and aren't optimizing for your project's longevity. The only way to write 20-year code today is either (a) work in an ecosystem that genuinely values stability (Lisp, C, parts of Erlang/OTP, Postgres) or (b) accept the tax of a modern stack and budget for it explicitly.
Most teams do neither, which is when projects rot fastest.