Live data from Hacker News

Ask HN: How to build software to last 20 years? 50 years? 100 years?

news.ycombinator.com

21–28 of 28 posts

Re: Ask HN: How to build software to last 20 years? 50 years? 100 years?

#21
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!

Re: Ask HN: How to build software to last 20 years? 50 years? 100 years?

#23
post #7
post #4

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’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?

Re: Ask HN: How to build software to last 20 years? 50 years? 100 years?

#24
post #9

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 depend…

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.

Re: Ask HN: How to build software to last 20 years? 50 years? 100 years?

#26
post #7
post #4

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

Re: Ask HN: How to build software to last 20 years? 50 years? 100 years?

#27
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 :)

Post reply on HN