Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Ask HN: How to build software to last 20 years? 50 years? 100 years?
10 points by thesuperbigfrog on July 10, 2024 | hide | past | favorite | 27 comments
There are many old buildings that are still in use today:

https://www.grunge.com/327172/the-oldest-buildings-still-in-use-today/

While software longevity is not subject to weather and natural disasters, there are forces that impact software longevity:

http://laputan.org/mud/

If you needed to build software that does its job and stands the test of time, what choices would you make?

What programming language(s) would you use?

Why?



I've worked with a fair amount of software that's 50 or so years old and is still in daily use.

I don't think that the language its in matters a great deal as long as its one that has very wide and deep support. In today's languages, that would mean C/C++, Java, COBOL, and a few others that escape me at the moment.

The bigger issue is going to be hardware changes. A lot of the half-century software I've touched was written for mainframes from the '60s and '70s -- and it's still running today only because those mainframes are being emulated on modern hardware.

I think that, generally, the way you build software that will last is just to engage in excellent engineering practices. Document everything well, keep the code simple, don't get cute or clever, don't follow the fashion of the day, use good names for procedures and variables, don't use magic numbers, and so forth.


I’d add Javascript and maybe Erlang to that list. (I say maybe for Erlang because I don’t have firsthand experience of it, but I get the impression that they don’t make breaking changes and won’t go away.)

I’m tempted to add Go to that list, but it feels premature.


I'm curious why you think Javascript should be on the list, I see a lot of issues:

Javascript generally runs on a website in a browser: The browser must be continually updated on the client side every few weeks at the very least.

Your software must work on all future browsers in 50 years time.

Security patches/privacy/laws/etc deprecate/change API calls regularly.

The website must continually update certificates, maintain payments to providers / keep valid credentials / not get hacked for 50 years.

Most javascript applications have a billion dependencies, and people rewrite using a new framework over updating if it's been a few years, never mind decades.

Keeping dependencies up to date for 50 years is a lot of work.

I don't know of any instances of anything javascript that has run continually for 20 years to date?


I disagree based on the existence of a standartized but diverse ecosystem.

The languages listed above all have:

- a language specification; - more than one competing implementation.

Erlang doesn't have a specification, so you're actually writing code that runs on the maintained implementation of the VM. This effectivelly ties yours software to the lifecycle of the VM implementation, unlike a situation where diverse implementations and platforms that can execute some code.

JavaScript does have a spec, and it does have competing implementations. So if you're to restrict yourself to no dependencies, a standalone webapp could be added.

But not for JavaScript outside the browser: there have been efforts to make a coherent interface to the OS, but none stuck. So now you need to pick a platform to restrict yourself to.

---

I've explicitly highlighted the lack of dependencies with JavaScript just because how pathological this ecosystem is in this aspect. It doesn't have to be zero, and it does apply to other languages and ecosystems, but "a simple react app" absolutely fails this rule.


I built software 30 years ago that is still in use today, pretty much unmodified.

It targeted a specific niche that some government agencies have, and will likely continue to have, and which it is unlikely to have a commercial replacement. So no competition to knock it out.

It ran on UNIX, but was made to be very portable, as there were many UNIXen back then. It now is on Linux. It can still be built today, as dependencies are minimal. Even the Motif UI. People complain about auto tools, but that stuff is bomb proof and just works. Will your build system just work in 30 years? What about your operating system?

I paid a lot of attention to fundamentals, and especially smooth operation. This has enabled generations of IT support people to continue supporting the product.

I recently was re-engaged to do a new version of this software, updating it to use modern things that didn't really exist back then. Like a web UI instead of Motif. The main challenge with that so far is the short lived nature of anything in the javascript domain. Could someone build this software 10 years from now?

Modern practices assume easy connectivity to get resources from places not under your control. To achieve longevity, you need to bring all of those resources under your control and have a good plan to manage that.


Any complaints or criticism on the lack of some widget on Motif?

Also, I'm curious: is the app accessible? AFAICT, Motif doesn't even mention accessibility, and is where Sun made real progress in the past.


Imo the best solution is a js web app or a C/C++ app.

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).


20 years is easy: Just make a thowaway project. I made a demo for my work in the university like 10 years ago and it's still in production. Fingers crossed that it survives 10 more years and someone else has to fix the horrible code or rewrite it.

50 years: Make a library in Fortran. We are still reusing parts of old code and I'm not sure if it's Fortran 77 or older.

100 years: It may be hard.


* Use a low level language already proven durable over decades: COBOL, Fortran

* 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.


Different parts of the system "age" at different rates. It also depends on what your software itself depends on.

If you want something to last a long time make it a library and ensure it has few, ideally no, dependencies outside your language's standard library. Keep it as hardware agnostic as possible or make it clear where the hardware specific portions need to be included and how they can be separated back out and replaced with minimal disruption to the rest of the system.

If you make an application, divide it into at least two parts: presentation and business logic. Presentation portions tend to age the worst so you want your business logic portion to be as library-like as possible.


I've worked with a few programmes in Fortran 77 and Basic which I think were from the early 80s and the same algorithms are still in use. I'm sure some people are still running these models in the original language which were to do with gas metering calculations. Some of the software came from printouts which I had to type in again, it was like going back to programming 8 bit games out of the computer mags...


A few things:

First, the technology choices are secondary to the organization that is charged with maintaining it. If the organization goes out of business and the software doesn't get picked up then it's lost. The exception to this would be widely used open source software.

Second, use boring technology that's easily extensible. If it's easier to build a new thing to replace the old rather than extending it, then it probably won't last.

Finally, the purpose of the software must stand the test of time. Think about the patterns/things in life that will still be here decades from now. For example, death and taxes :)


Make a game for a platform that will get emulated. People collect and pass them around for a long time, especially if it's for a retro console (there are brand new Genesis, Game Boy, Super Nintendo, etc. games making $100k+ on Kickstarter this year even).

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.


I'd probably use lisp.

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.


Work on a system with long range utility and complex business rules, and do a not so good job at implementing business rules in an easy to modify way!

As an intern, I wrote some perl4 scripts to grab the output from a mainframe, modify and merge some stuff from another report. It was a quick demo intended to be used to test the “enterprise software” being developed by a big consulting company.

Their software failed the test, so they used my code temporarily… this was back in 1997. Lol

Still there as far as I know! I’d guess there’s another 5-7 years before someone does away with it!


This is a silly idea that brings nothing but misery and maintenance overhead (go check how good government and old banks apps work).

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.


Write it in pseudo-code, write (or find) an interpreter for the pseudo-code and use it to run your software until AI is good enough to replace the interpreter.


It highly depends on what you are building. If it is a simple system then it is easy to keep it running.

If you use minimal amount of dependencies and try very hard to keep the system simple then the language shouldn’t matter that much


Read. You will find extremely interest insights.

https://en.wikipedia.org/wiki/100_Year_Starship


Put it into the control system of a machine tool used in production. It will run unchanged for decades, if not longer.

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 think you should use as least dependencies as possible.


software in large industrial machines. Nothing will be changed for decades because the machines have to pay for themselves


Write stuff in C. The language will never die. We could have a zombie apocalypse and people will still be writing C.


20 or 30 years sounds possible using boring tech and targeting public sector


software change because the job that is does, also change. example: moving money around today is not like it use to be 20 years ago.

an analogy with constructions makes no sense, IMO.


> moving money around today is not like it use to be 20 years ago.

How true that is depends on where you look. Behind the scenes, a large amount of banking is little different now than it was decades ago.


Join a bank or whatever a dinosaur company.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: