41–50 of 252 posts
Maybe software written in the age of DOS was relatively trivial compared to modern tools. Maybe there's a benefit to writing code in Rust rather than C89.
those written for e.g. Linux will likely cease working in a decade or two Have we already passed the era of DON'T BREAK USERSPACE when Linus would famously loudly berate anyone who did? I suspect Win32 is still a good target for stability; I have various tiny utilities written decades ago that still work on Win11. With the continued degradation of Microsoft, at least there is WINE.
JS is hated but if you compile to browser JS that code will run in 2100. If you mainly deal with files / blobs not databases you will have these things in 2100 too. I think a lot of apps can be JS plus Dropbox integration to sync files. Dropbox may rot but make that a plugin (seperate .js file) and offer local read/write too and I think you'd be pretty future proof.
postgres will be around in 2500 lol
In 20-30 years there’s a good chance that what you’ve written will be obsolete regardless - even if programs from 1995 ran perfectly on modern systems they’d have very few users because of changing tastes. A word processor wouldn’t have networked collaborative editing (fine for GRRM though), an image editor wouldn’t have PNG support, and they wouldn’t be optimised for modern hardware (who would foresee 4K screens and GPUs back then - who knows how we’ll use computers in 2055).
There are also always containers if the system needs those old versions.
Earlier quoted context omitted.
Very helpfully, python has stuck around for just as long and is almost always a better choice against these two specific tools for anything complicated. It's not perfect, but I'm much more likely to open a random python script I wrote 6 years ago and at least recognize what the basic syntax is supposed to be doing. Bash beyond a certain complexity threshold is... hard to parse. Python's standard library is just fine…
My main problem with python is that a script I wrote 6 years ago (or even 1 year ago) is not likely to run without requiring modifications. If it's me running it, that's fine. But if it's someone else that's trying to use installed software, that's not OK.
those written for e.g. Linux will likely cease working in a decade or two Have we already passed the era of DON'T BREAK USERSPACE when Linus would famously loudly berate anyone who did? I suspect Win32 is still a good target for stability; I have various tiny utilities written decades ago that still work on Win11. With the continued degradation of Microsoft, at least there is WINE.
The kernel doesn't break userspace, but userspace breaks itself quite often.
I think don’t worry too much about trying to avoid it. Think 5-10 years ahead max, rather than 20. In 20-30 years there’s a good chance that what you’ve written will be obsolete regardless - even if programs from 1995 ran perfectly on modern systems they’d have very few users because of changing tastes. A word processor wouldn’t have networked collaborative editing (fine for GRRM though), an image editor wouldn’t hav…
1980s NES software is "easy" as in emulating a CPU and the associated hardware (naturally there are corner cases in emulation timing that makes it a lot harder, but it's still a limited system).
I used to make demos as mentioned in the article, the ones I did for DOS probably all work under DosBox. My early Windows demos on the other hand relied on a "bad" way of doing things with early DirectDraw versions that mimicked how we did things under DOS (ie, write to the framebuffer ourselves). For whatever reason the changes in Vista to the display driver model has made all of them impossible to run in fullscreen (luckily I wrote a GDI variant for windowed mode that still makes it possible to run).
Even worse is some stuff we handle at an enterprise customer, Crystal Reports was even endorsed by Microsoft and AFAIK included in Visual Studio installs. Nowadays abandoned by MS and almost by it's owner (SAP), we've tried to maintain an customized printing applications for a customer, relying on obscure DLL's (and even worse the SAP installer builder for some early 2000s install technology that hardly works with modern Visual Studio).
Both these examples depend on libraries being installed in a full system, sure one could containerize needed ones but looking at the problem with an archivist eyes, building custom Windows containers for thousands of pieces of software isn't going to be pretty (or even feasible in a legal sense both with copyright and activation systems).
Now you could complain about closed source software, but much of a tad more obscure *nix software has a tendency to exhibit a huge part of "works on my machine" mentality, configure scripts and Docker weren't invented in a vacuum.
Earlier quoted context omitted.
My main problem with python is that a script I wrote 6 years ago (or even 1 year ago) is not likely to run without requiring modifications. If it's me running it, that's fine. But if it's someone else that's trying to use installed software, that's not OK.
This is one of the problems that containers help solve - no OS, just the dependencies required to run your code.
Earlier quoted context omitted.
My main problem with python is that a script I wrote 6 years ago (or even 1 year ago) is not likely to run without requiring modifications. If it's me running it, that's fine. But if it's someone else that's trying to use installed software, that's not OK.
This is one of the problems that containers help solve - no OS, just the dependencies required to run your code.
Mostly I recoiled in horror at bash specifically, which in addition to bash version, also ends up invisibly depending on a whole bunch of external environment stuff that is also updating constantly. That's sortof bash's job, so it's still arguably the right tool to write that sort of interface, but it ends up incredibly fragile as a result. Porting a complex bash script to a different distro is a giant pain.