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.
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.
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.
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.
> 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.
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 3 which is now stable and doesn't seem to have any plans for future compatibility breaking changes.
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.
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.
"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.
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.
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.
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.
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?
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?
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.
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.