An example worth considering is TeX, which is now 43 years old (considering only TeX82; the earlier TeX78 was a substantially different piece of software). There has been some maintenance over the years, it's true, including a few feature additions in 1990 (TeX 3.0), but I would suggest it has shown itself to be extremely durable.
Can Software Be Durable?
21–30 of 48 posts
Re: Can Software Be Durable?
#22We’re coming up on 50 years for Space Invaders. We can say that it’s endured because: - it’s self-contained: it works without dependencies, and with the hardware it was designed for - there’s an ongoing need: peope want to continue playing Space Invaders - it’s transposable: the environment it runs in can be recreated through additional layers (emulators here) - it’s recreatable: the core concepts behind Space Invade…
Modern software development started for me in 1985 when we disassembled the Choplifter arcade game they mistakenly put in the college dorm with several student engineers. Within 15 minutes of them dropping it off, we had the back door open and the eproms lifted from the motherboard. Within a couple of hours we had reverse engineered the code, modified it for a free game hack, burned new eproms and put back in service…
Talented people with access to resources! And no fear of punishment ( fines, expulsion, etc. )
Re: Can Software Be Durable?
#23Simplify as much as possible and reduce the surface area: the least amount of code, the least amount of dependencies, the least amount of infrastructure.
Re: Can Software Be Durable?
#24An example worth considering is TeX, which is now 43 years old (considering only TeX82; the earlier TeX78 was a substantially different piece of software). There has been some maintenance over the years, it's true, including a few feature additions in 1990 (TeX 3.0), but I would suggest it has shown itself to be extremely durable.
At the heart of this are two wildly different technologies:
- Literate Programming which was developed so as to work around limitations of the Pascal development stack as it existed when the project was begun: http://literateprogramming.com/
- web2c which allows converting .web source into a format which may be compiled by pretty much _any_ C compiler
LP was described by Knuth as more important than TeX, but it suffers a bit from folks not understanding that it's not so much documentation (if it were, then _The TeXbook_ would be the typeset source of plain.tex) as code commentary only useful to developers working to extend/make use of the application --- there really does need to be some sort of system for manual documentation, but I suspect that it will continue to be a talented technical writer for the foreseeable future.
Re: Can Software Be Durable?
#25Use the least amount of dependencies, only old mature stable APIs, obviously offline only. This way you can be pretty sure the environment can be easily emulated.
Re: Can Software Be Durable?
#26This is based on fundamentalky wrong assumption that software is something like a hammer or a bulldozer. Software is more like a plumbing. It a) wears out b) requires maintenance c) people maintaining it is integrated part of the whole system.
Software is and ideally must always be a hammer. It is only since the last 15 years that monopolist platforms try to trick us believing they are not.
Re: Can Software Be Durable?
#27This is based on fundamentalky wrong assumption that software is something like a hammer or a bulldozer. Software is more like a plumbing. It a) wears out b) requires maintenance c) people maintaining it is integrated part of the whole system.
Software is and ideally must always be a hammer. It is only since the last 15 years that monopolist platforms try to trick us believing they are not.
The last 15 years was 2010. I’ve been in the industry since 1996 and programming as a hobbyist since 1986. Computers change, operating systems change. It’s not like I was using the original AppleWorks 3.0 on my Apple //e in 2010, or ClarisWorks from 1996 on my LCII.
While you can still buy Microsoft Office once and use it “forever”, I much prefer the $129 a year, 5 users deal with 1GB of online storage per user and each user can use office between their computers, online and on mobile regardless of operating system.
A desktop only office suite would do me no good as I go back and forth between platforms.
Re: Can Software Be Durable?
#28This is based on fundamentalky wrong assumption that software is something like a hammer or a bulldozer. Software is more like a plumbing. It a) wears out b) requires maintenance c) people maintaining it is integrated part of the whole system.
Software is and ideally must always be a hammer. It is only since the last 15 years that monopolist platforms try to trick us believing they are not.
To be fair, the surface of software has gone through the roof. Unix utils like `grep` or `find` can be hammers while a retailer's website with varying promotions, inventory and overall content needs to be maintained, moreso like a car.
Re: Can Software Be Durable?
#29There's fifty year old simulation software in use today. I ported some to semi-modern x64 and learned things I've gratefully forgotten about floating point in the process. Also that "VAX" and "SUN" Unix behaved differently, for whatever that's worth.
I would say that was viable because it had zero dependencies and could be built with the equivalent of gfortran *.f77, provided one changed the source in plausible looking ways first.
If your software relies on fetching things from the Internet it is probably doomed within a year or so and surely within a decade.
Wouldn't bet on today's up and coming language still existing either. C89? Will probably still build fine with some compiler passing appropriate flags.
Hardcoding x64 or aarch64 assumptions likely bad for longevity too, as both are surely gone before 2075 ticks around, though equally I couldn't find a VAX and still got that code running. So that's more about minimising the cost of porting rather than anything fundamental.
Re: Can Software Be Durable?
#30There's fifty year old simulation software in use today. I ported some to semi-modern x64 and learned things I've gratefully forgotten about floating point in the process. Also that "VAX" and "SUN" Unix behaved differently, for whatever that's worth. I would say that was viable because it had zero dependencies and could be built with the equivalent of gfortran *.f77, provided one changed the source in plausible looki…
>> I would say that was viable because it had zero dependencies and could be built with the equivalent of gfortran *.f77, provided one changed the source in plausible looking ways first.
Came to say this. Minimize your dependencies. Software can last forever, but everything around it changes and can break or otherwise cause incompatibilities.