Software Rot and Classes of Rot Resistance
1–10 of 27 posts
Re: Software Rot and Classes of Rot Resistance
#2I 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.
Re: Software Rot and Classes of Rot Resistance
#3"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.
Re: Software Rot and Classes of Rot Resistance
#4Software 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!
Re: Software Rot and Classes of Rot Resistance
#5Interesting, 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?
Re: Software Rot and Classes of Rot Resistance
#6"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.
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.
Re: Software Rot and Classes of Rot Resistance
#7Interesting, 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?
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?
Re: Software Rot and Classes of Rot Resistance
#8I 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.
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.
Re: Software Rot and Classes of Rot Resistance
#9Is 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.
Re: Software Rot and Classes of Rot Resistance
#10If 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.