Make and maintain the virtual machine that runs your program, which executes custom instructions.

See uxn and justification: https://wiki.xxiivv.com/site/now_lie_in_it.html

And https://100r.co/site/story.html

> The way you make code last a long time is you minimize dependencies that are likely to change and, to the extent you must take such dependencies, you minimize the contact surface between your program and those dependencies.

A lot of value is driven from those dependencies though. Zapier as a pointed example: Zapier sans dependencies is ... well I don't even know. So sure, you could avoid dependencies at all cost, but at some point you might end up deleting the reason someone else wants to use your code in the first place.

Of course, if you're writing code only for yourself that will totally work, but most professional software engineers are not -- it's a balance and it's not fair to say all they have to do is stop writing glue code.

I was about to comment how easy Zig makes it to make platform layers where the right code for an OS is compiled at compile-time and AFAIK there is no runtime cost, it's basically conditional compilation. But the Zig language itself is incredibly unstable and code you write now probably won't compile a year from now.

This seems like another case where jblow's opinions are guided by his experience as a game dev. Games can be "finished" and never touched again. I think I mostly agree with him that software could be made to be timeless to some degree. But, in the world of web apps and saas, the culture is to offload much of the work to third party libraries/APIs which locks you into a never-ending cycle of dependency management. I don't know if this culture is totally necessary (maybe to ship fast and keep up with security updates?), but in a world where users expect software to be constantly improving you can't expect anything to be "done". Maybe you could get close if you built everything in-house, but even still you have to keep up with security flaws.

Software in a closed ecosystem should run for the life of that ecosystem, an example would be Firmware on a non-connected device. eg the ECU in my car from 1991.

I kind of agree. There's another world, where software lasts a really long time, it's a much better world, but just a few of us get to live in it.

Building tools for other engineers is where it's at, the library maintainers for long lived libraries, like libc or any collections library.

If you get a sorting algorithm in a mainstream language library, it will likely live forever (or forever-ish in software terms).

The harder the problem you solve (in the math sense) the more likely that if you craft that code properly and carefully, it will outlive you.

Well, when I was in school, the goals were wide compatibility and portability. I was writing network C code in the 00's that could run without any changes on Windows, Linux, FreeBSD, HP-UX, AIX, SGI, SCO, and Solaris.

Code only "rots" when its dependencies rot from assholes who churn the language or break API promises. These low expectations lead to normalization of deviancy that churn without clear and present value is "okay", when it's merely job security or coding theater to appease others that everything must be touched and changed constantly or otherwise it's "broken".