> I imagine COBOL is similarly stable but I have no experience there.
I haven't programmed in COBOL, but it is quite stable. One of the really nice things in COBOL is the "Environment Division", which has a Configuration Section, which provides information about the system on which the program is written and executed. It consists of two paragraphs −
– Source computer: System used to compile the program.
– Object computer: System used to execute the program.
Another remarkably stable language is Ada, I have used it to compile non-trivial programs from 30+ years ago, on a different architecture than it was originally written for (granted, without system dependency) using a modern compiler without anything more than (1) renaming identifiers which had been made keywords, (2) splitting files due to GNAT's implementation limitation regarding compilation-units.
Ya I was thinking java is closer to the mark as well, even coming from someone who has never programmed in java... But I have long thought that it would be nice if there was some sort of universal standard for pseudo code that could be compiled into other languages.
Meanwhile Python: "Yeah if you could rewrite your entire codebase every few years because of some changes nobody fuckin asked for, yeah that would be great. Oh and by the way, we're dropping support for non-latest versions of the language lmao."
Except they have, just not to the same extent as some other languages.
K&R C won't compile in modern compilers, not is allowed as per ISO C2X upcoming standard.
gets was removed.
And if you are using optional Annexes, they might not even exist in ISO C compliant compilers.
Similarly, that Java code will die if it uses internals made private in Java 9, inherits from JDBC and has methods with names that were later added to more recent versions, uses deprecated methods that were finally removed around Java 10 time,...
Sure and you can write code that is valid C and valid shell- but there have been major breaking changes to Java (iirc Minecraft barely started working with Java 16 this year).
You have to distinguish Java the language and the JVM: Class files generated by any (?) version of the Java compiler before the JVM version you’re using will usually work on the newer JVM. Java 9+ started removing classes, breaking API compatibility: but, generally, there are additional jars/command-line options that can be used to restore the older behavior.
Minecraft, in particular, has always worked fine with Java 9+, ime: if you know the flags to apply (and delete the jar that checks the Java version), it more or less just worked. I’ve been running it for a year+ on new JVMs so I could use the Shenandoah GC and take advantage of more of the 128GB RAM in my desktop.
This isn’t exactly true: javax.xml.bind-related ClassNotFound errors are a fairly common problem when running old Java applications on new JVMs. Thankfully, the solution is just to include the relevant jar that implements the classes that have been removed.
I haven't programmed in COBOL, but it is quite stable. One of the really nice things in COBOL is the "Environment Division", which has a Configuration Section, which provides information about the system on which the program is written and executed. It consists of two paragraphs − – Source computer: System used to compile the program. – Object computer: System used to execute the program.
Another remarkably stable language is Ada, I have used it to compile non-trivial programs from 30+ years ago, on a different architecture than it was originally written for (granted, without system dependency) using a modern compiler without anything more than (1) renaming identifiers which had been made keywords, (2) splitting files due to GNAT's implementation limitation regarding compilation-units.