Ask HN: Immortal software: how would you write it?
Given the task of designing a software system to be used for at least 100 years, what design choices would you make to help ensure its survival and usefulness? For example, to allow it to be ported to different hardware/software platforms, or to allow it to be integrated with other systems.
Inspired by https://news.ycombinator.com/item?id=19272428
67 comments
[ 3.4 ms ] story [ 124 ms ] threadYou have the right idea. I want to note that, in a sense, the program would partly be written in the specification language with which ths VM is defined. One could use English - probably OK, though English has shifted a bit in the last 100 years (is it shifting more slowly with the internet, or faster?). And you can use mathematical notation, which has also shifted, but more slowly.
That helps with porting, so it can run, but the question of maintaining the software remains (changing it to meet changing circumstances and needs)
- Is it better to totally nail it perfectly, so only known aspects need to change? (A bit like your VM approach, in some ways).
- Or make it minimal, simple and clear, so the core can be preserved, modified, even rewritten, without losing the basic idea of it?
If you didn't allow that, then you're asking for a complicated series of bets on future substrates your software will run on, many of decompose into "Ship an organization that will care enough about it to keep the underlying substrates running and available."
https://en.wikipedia.org/wiki/Historical_components_of_the_D...
Of those, zero are in the index today. The only ones I've even heard of are AT&T, GE, Studebaker, US Steel, Western Union, and Westinghouse, and half of those don't exist today.
(As a side note, it makes me wonder if the common wisdom of buying a stock market index and holding it is really just survivorship bias. If you bought the Dow in 1920 and held the individual companies, you'd be nearly bankrupt today; it's only because the index continually switches out declining companies for new large-caps that it's gone up continuously over long periods of time. That in itself might be a lesson that supports your point: the way to build a system that lives forever is to build a Ship of Theseus that can swap out and discard components that no longer serve its purposes without losing its overall identity.)
If you owned shares in the American Can Company, you would have then owned shares in Primerica and would now own shares in Citigroup which was only bumped out of the DJIA in 2009.
Several of the mining companies were bought out.
The Texas Company is Texaco.
United States Rubber Company became Uniroyal and was bought out by Michelin and Continental.
Sure, some like Studebaker and some of the locomotive companies collapsed and would have been a total loss, but it's entirely likely that holding all of those original companies would have made you a whole lot of money.
Problem solved if you work for Uncle Sam. His organization is very, very likely to survive the next 100 years.
So, using text files for storage could be really good, if possible. A desktop application could be written as a single process binding to a port and displaying a HTML-based GUI could work as a console, probably in all kinds of unforeseen ways.
As for the language, I would write it in Perl. There's gonna be an interpreter in an every UNIX based box for many years to come, and the community thinks backwards compatibility is a feature. I don't know if they'll keep it going for a hundred years, but we might also have bigger problems than keeping applications going.
I have no doubt SQLite deployments will be up and running in 2100.
I suspect most nuclear powers depend on the private sector for maintaining their nuclear arsenal, and having them really factor these future risks, storage costs and insurances in would make nuclear energy uncompetitive.
Gladly in most nations the public readily jumps in and pays the bill (and will have to do so for centuries). Imagine the outrage if any renewable energy would demand such things from the public.
I understand the fascination with nuclear energy, look at the Voyager, which powered by a nuclear battery flew for two decades through the void. But the points I raised above are only speaking of nuclear energy as it is now used – I can imagine future cleaner reactors with less waste. But right now nobody has any incentive to really put money into it.
The same money that would go into taking over costs for private nuclear companies could easily flow into new technologies and energetic cycles, some of which the US is actively working against on political and economic levels.
Climate change will have an incredible impact on migration, so the best way to reduce CO2 is to make it in a way that gives Africa and its people a future. You could e.g. Force CO2 neutrality for carbon plants by having them plant trees in Africa. Which not only would reduce their CO2 impact and create jobs where they are needed to stop future drama, but increase soil stability, help with the increasing temperatures and potentially even provide food.
Btw. Coal plants are heavily regulated over hear in Europe — the filters they have to have have the size of a little house.
The question is: is the future more important than beeing/staying the geopolitical and economical leader? It is only about priorities and not about the unavailability of solutions. Are tou willing to give up long term competitveness for short term gain?
Petrol could be replaced by closed Ethyl cycles produced by solar panels in the sahara (which would again create jobs there) and we wouldn’t have to use electric cars whose battery production costs more CO2 than the car would save. The infrastructure to use Ethyl is basically there (If I am not wrong the Chinese add over 10% of Ethyl to their petrol already).
I think the solution are closed cycles. If water wouldn’t have a cycle on it’s own or without us creating it we would all have died of thirst.
i like the idea of software as replacing a societal service so as long as that society survives in some form your software will survive as well(for eg our current banking systems are such software)
Most protocols will be phased out for security reasons. So I would go with direct TCP/UDP based on Linux kernel syscall (still the weakest point) in C or with fetch in JS.
Most operating systems will be trivially vulnerable to attacks, so I would go with the minimal possible attack surface (hardened kernel, firewalled, etc.)
It should survive and TCP/UDP communication makes it easy to integrate with any other software.
For the hardware I would go with a Raspberry pi if possible (and in C), otherwise just hosted on AWS.
About its usefulness, that would be hardest point. If it was useful and not updated for 5-10 years, it will be replaced however complex it is, 100 years later the problem might be generalized or not relevant anymore.
Looking at what's there:
- 61 years old, MOCAS, OS written in COBOL used US Department of Defense, on a mainframe
- Linux, Python, glibc, perl, emacs, ...: Most old software still relevant is a core foundation (programming languages, operating systems, text editors)
- NASA's software: C, C++, Ada, Python. Linux for applications, Windows for end users.
So I would probably make a minimal programming language, maybe some kind of minimal Crystal.
The Berkley sockets API is pretty well supported on all major operating systems via C libraries with only slight differences and even if it dies out will likely have shims available for a long time to come. Why use a direct syscall interface over this?
Talking about decreasing risk of failure by minimizing attack surface, but at the same time greatly increasing it by maximizing vendor lock-in, essentially betting Amazon will still be around in 100 years, it just does not feel like a very sound strategy.
> So I would probably make a minimal programming language, maybe some kind of minimal Crystal.
A new programming language made now (such as Crystal) has the least likelihood of lasting 100+ years, no matter how good it is.
- Separate the UI from the application and business logic and make the interface to the latter clean and well documented.
- Either use a currently very widely deployed ecosystem (aka Java) which will have a fair chance of evolving or being emulated etc over the course of 100 years, or use a self-bootstrapping environment with a simple core like forth or scheme/lisp etc, where everything you need is self-contained.
But really what makes a system still useful in 100 years or further is that it solves a problem so well, so reliably, etc, or just well enough if it's a huge and complex problem, that there's no incentive, or the investment would be prohibitive, to replace it with newer technology. Think CICS.
COBOL, for example.
1) Have standards that don't change appreciably. I first wrote the system in the early days of the Web and put it into full production at or about 1997. The fact that HTTP, CGI and SQL didn't change much and continued to be supported helped immeasurably.
2) Use a platform that you can manage effectively. We started with SGI IRIX, then moved it to Linux, where it spent most of its life. That let us move it from machine to machine and finally a datacenter. This would have been more difficult on an OS with a commercial pressure to upgrade.
3) Be lucky with your language choice. I used Perl 5, which had just come out at the time. I started on Perl 4, but the OOP features of 5 were very attractive (was heavily influenced by articles I read about SmallTalk at the time). Because Perl 6 never really happened (for me), I avoided the Python 2.x/3.x problem.
4) Make it documentable. Every code object in the system could be easily documented (the editor included a comment field for everything, which could be automatically extracted to provide developer help). Not everyone who worked on the system used it, but I did, which made it easier to figure out what was going on years after I had been doing other things.
5) Make it straightforward. Not sure that's the best way to put it, but after I left the company, the system suffered a good chunk of updates and rewrites by people who knew more or less what they were doing, but because they had to remain compatible with the original, fairly simple architecture, I was always able to pick up the thread when I did contract maintenance on it.
6) Security is a process. At the time I wrote it, it was... let's say "fairly" secure. Some of the updates/rewrites badly degraded the capability-based security it had (the maintainers didn't understand it and thought it was decreasing performance (which, to be fair, it was), so my original security thinking was rolled under the pressure of customer requests and deadlines.
Hope that helps!
Perl6 would replace Perl5 in the same way Go is a replacement for Python.
This was perhaps a little more muddy in the beginning of the Perl6 project. Larry has said that part of the reason for breaking compatibility was that the Perl5 codebase was stable enough. Meaning existing code could continue to run on it unaltered.
I wouldn't build it in software if I had the choice. I'd build a mechanical system. Software, and electronic computers in general, haven't proven themselves as good long term bets yet. There are mechanical systems around that have been going for many hundreds of years (eg https://en.wikipedia.org/wiki/Salisbury_cathedral_clock).
About the only thing that they have in common is that they started with the thought: "I'll just knock this up in 5 mins then come back and do it properly when I have the time".
I would build on the java vm or the JavaScript vm. Both those will maintain a lot of backwards compatibility and have a large population of developers for the foreseeable future.
I would buy your own domain and not depend on a third party solution for your software's web presence (GitHub pages, etc) because those businesses come and go over decades. In 100 years we'll still be doing DNS or something similar.
Every software system is about translating the work of some humans into the rules that some body of humans cares about. As an example, let's take something that we humans like to do a lot: buying things.
So let's design an in-person payment system. Select item to buy, pay for item. Totally simple, right?
So the first iteration uses a touchscreen kiosk? In twenty-to-ninety years, that will look soooo dated as everyone is paying with their hand gestures or their minds. ("Ma, I'm blinkin but it ain't buyin!")
The part of the system that lives for 100 years needs to have no concept of a user interface.
So you produce abstractions, you define a boundary to your system that is described as simply "user submit payee details". Now that bit can be swapped out - as long as it receives a valid user payment bundle, we're good.
What about currency? Not too long ago, some countries moved from a coinage-based pounds-shillings-ha'pennies system to one based on hundredths of a pound. Soon after, many european countries banded together and moved to a single currency, still based on hundredths though. Next step might be to pay via bitcoin, at which point each mundane transaction will probably cost trillionths of a satoshi, and we'll come up with some system for calculating what order of magnitude your payment is, just to save us typing out all those zeros. So we might be representing money as 1.8265e-972. Maybe we'll write it as 18\927. Maybe it'll all be emoji, and in discussion we just call it "18 breads". Maybe society will have collapsed and we're paying with bottle tops. Two Buds and a Pepsi.
Whatever we do, how we represent the cost will either need to be so vague that we can never do any calculation on it, or again, we farm the representation and manipulation to another system that doesn't need to last for a century.
In the end, our program looks like:
ask_user_what_they_want_to_buy => find_price_of_users_basket => take_payment => inform_user_of_success
And that's all assuming that users in the future leave their homes (could be radiation), exchange money for goods (could be post-scarcity) or that there is such a thing as a company, much less that the company that commissioned the system even exists.
So my answer is probably give up and do something easier. Aim for 20 years. You'll still fail, but at least the failure will cost less.
Pro: Forth is standardized. It runs everywhere. It's most likely the first language that will be ported to any new platform. If it isn't avaible on a new platform yet, you can write your own interpreter.
Contra: Today's software requirements most likely are too complex to be handled in forth. You might need 100 years to debug your program.
The availability of software designed to “compute math” is something I am prepared to bet on lasting the next 100 years.