1–10 of 28 posts
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?
an analogy with constructions makes no sense, IMO.
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.
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.
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.
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.
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 w…
I’m tempted to add Go to that list, but it feels premature.
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.
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.