
Software Rot and Classes of Rot Resistance - martinfjohansen
https://github.com/InductiveComputerScience/progsbase/wiki/Software-Rot-and-Classes-of-Rot-Resistance
======
olooney
If I wanted to write a program that could be run for generations to come I
would target a specific piece of hardware of significant historical importance
such as the 6502 (for example.) Not only are there already many emulators for
it, and not only is it fairly easy to write an new emulator for such a
straight-forward system (unlike, say a PS3, which is very difficult to
emulate), but because of its historical importance it is likely emulators will
continue to be written and maintained for a very long time. Even if my program
would not be of historical importance itself, but by targeting the same
hardware it would piggyback on other preservation efforts.

------
maxxxxx
Is that just a commercial for this progsbase thing? I certainly like the
assertion that that code won't rot for "centuries". Maybe a fizzbuzz
implementation will survive this but even there I have my doubts.

~~~
tluyben2
There is already Haxe which is free and compiles to a lot of things.

~~~
martinfjohansen
As I explained in another response, progsbase is very different from Haxe.
Haxe is an independent language. If you use Haxe, then you depend on the Haxe
compiler. Progsbase is completely in other languages, meaning the progsbase
tools are only support tools which gives you certain benefits such as being
able to translate. You code remains pure Java which you develop with Java
tools.

~~~
tluyben2
You would still need the compiler to be written in progsbase too: is it? As I
am not quite sure (and you cannot gamble on it) that Java and Java tooling is
still there in 100 years. Which then brings you back to Haxe ; kind of the
same gamble there but that is open source which makes it longer lived
generally anyway.

A language for the ages would be a Forth imho; you can write the language on
the back of a beermath and it takes mere hours to implement on whatever
system.

~~~
martinfjohansen
> You would still need the compiler to be written in progsbase too: is it?

Currently no, but the progsbase language is very simple and contains only
well-known constructs. So creating a compiler is very simple, it would take
only a few days. This is like the point you make about forth, except forth
contains less well known constucts.

> open source

The progsbase specification is also open:
[https://docs.progsbase.com/](https://docs.progsbase.com/)

------
ForHackernews
I find it pretty laughable to claim that software written in this (brand new?)
language, progsbase, will last a "ballpark" of "centuries". The transistor
isn't even a century old.

To my knowledge, nothing created by humans has lasted centuries with the
equivalent of one day/year of maintenance work.

~~~
slacka
Not only that, but their chart makes it look like adopting older languages now
will give you more bit rot resistance.

C2: C89 or Python 2 a few decades a developer week

C3: C or Python a decade a developer month

When it should read:

C2: C99 or Python 3 a few decades a developer week

C3: C89 or Python 2 a decade a developer month

If you start a project today with python 2, the bit rot will be far worse[1]
than python 3 which is now stable and doesn't seem to have any plans for
future compatibility breaking changes.

[1]: [https://lwn.net/Articles/750833/](https://lwn.net/Articles/750833/)

~~~
martinfjohansen
C89, C99, Python 2, 3 were only examples as the table header says.

------
petermcneeley
"For example, when 64-bit Intel CPUs were launched, they no longer supported a
list instructions. If these were used in a library, then the library no longer
works."

Is this true. The only thing I can find is that the old x87 fpu instructions
might not work on x64 arch.

~~~
slededit
This is both true and highly misleading. In X64 mode many instructions were
gone. However you couldn't execute a 32-bit program directly in that mode
anyway so it was the least of your problems.

Everything was still there in 32-bit mode. Nobody would have bought the
processors if they didn't work with existing software.

~~~
martinfjohansen
The removed instructions were binary-coded-decimal instructions, push / pop of
CS/DS/ES/SS. These are minor instructions, but if your program used them, that
alone means it no longer works, and that was the point.

~~~
slededit
BCD instructions are slower than emulating them with more traditional
operations and were rarely used in 32-bit software (16-bit is a different
story). Most people would recompile their software and never experience this
as an issue.

The removal of the segment registers was the only one that really reduced
capabilities - VMWare's original solution became impossible because of that.
However they were replaced by hypervisor instruction sets which are much more
capable. The proposed solution in this article would never have fixed this
though - which again is why its true but misleading.

~~~
martinfjohansen
The WMWare example is very interesting!

Let me just note that the article does not propose a solution to VMWare's
problem. It only notes that when instructions are removed, code using it stops
working.

~~~
slededit
Instructions were never removed from 32-bit mode though. You can run your
32-bit programs the same as before, even on today's most modern processor. You
just won't get any of that 64-bit goodness.

------
unwind
Interesting, if a bit long perhaps. Also, I've never heard I/O instructions
being referred to as "infrastructure instructions" before, can this be a
mistranslation?

~~~
beat
I/O is anything outside the program itself. All sorts of headaches happen this
way. The problem is actually more complex than the article suggests. For
example, say your app uses a database schema. What if the schema changes? Will
your app break?

------
quintiles
Software dependencies really are the worst part of programming. It's probably
the root cause og 75% of developer burnout, with the remaining 25% split
between path resolution errors(relative or absolute, training slash or not?)
off-by-one array index errors, nulls and simple typographical errors that
cause the loss of hours of compiler time.

    
    
      This is very common!
    

Common, but still total bullshit. It's THE barrier that repels most novice
programmer who just get fed up, and reject programming as a passtime or
livelihood.

~~~
tluyben2
> Software dependencies really are the worst part of programming

and yet we are making it worse instead of better and most people here tend to
find that a good plan.

