Live data from Hacker News

Software Rot and Classes of Rot Resistance

github.com

11–20 of 27 posts

Re: Software Rot and Classes of Rot Resistance

#11

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.

It looks like progsbase is essentially a non-free version of Haxe (progsbase requires $65 per month per developer). There is no source available and the code library is full of trivial examples.

Re: Software Rot and Classes of Rot Resistance

#12
post #9

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.

Given that the same text is available here https://www.progsbase.com/featuredpost/software-rot-and-clas... I'd say it's pretty likely to be a commercial.

Re: Software Rot and Classes of Rot Resistance

#13
post #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.

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.

Re: Software Rot and Classes of Rot Resistance

#14
post #9

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.

The argument was that a program written with proven, solid programming constructs, then it will last a long time. The example language is very simple: It contains things like: +, -, *, /, log, sin, cos, exp, functions, ifs and for loops. These things will not be unexecutable any time soon. These were basically in Charles Babbage's programming language for the Analytical Engine designed in the 1830s, two centuries old already.

Re: Software Rot and Classes of Rot Resistance

#15
post #5

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?

The reason the name "infrastructure instruction" was coined for this article is that it includes instructions such as "int", "rdtsc", which do not deal with only input and output, but deal with more complex things inside a CPU, such as timers and CPU privilege levels.

Re: Software Rot and Classes of Rot Resistance

#16
post #6

Earlier quoted context omitted.

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.

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.

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.

Re: Software Rot and Classes of Rot Resistance

#17

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.

See the answer I gave maxxxxx above.

Further, progsbase is not a brand new language, it is (mostly) a subset of most existing languages. The selection of the subset is new, but not the contents. This is why the progsbase repository contains examples that can be translated into Java, C, C++, JavaScript, C#, PHP, Python and Visual Basic.

Re: Software Rot and Classes of Rot Resistance

#18
post #8

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.

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…

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

Re: Software Rot and Classes of Rot Resistance

#19

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.

It looks like progsbase is essentially a non-free version of Haxe (progsbase requires $65 per month per developer). There is no source available and the code library is full of trivial examples.

Haxe is an independent programming language that can be compiled to other languages. Progsbase is very different: It is a language in other languages.

Re: Software Rot and Classes of Rot Resistance

#20
post #9

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.

There is already Haxe which is free and compiles to a lot of things.
Post reply on HN