Hacker News new | ask | show | jobs
by strangetortoise 1723 days ago
> But I will say this, I've long been thinking that there should at least be a programming language and OS that does its best to not change. A sort of whole environment where every single piece that's out of beta commits to minimal interface changes over time

At the risk of this being interpreted as trolling; don't we have this, for crucial OS interfaces at least? Linux is famous for "we do not break user space" (yes, I know it's not 100% true, but it's closer than anything else I've seen), and afaik the posix standards are pretty stable too.

The C language also has a stable ABI, which is basically the ffi for most languages, and most static libraries that were developed decades ago can link just fine.

In my mind, the problem is caused by at least two things:

- Languages that are not compiled to machine code have no incentive to have a stable API or ABI. This has the effect that code reuse now necessitates replicating the state of the machine it was developed on (Which might be using a different language version, runtime, etc).

- Programming culture has progressed to a "get it done quickly, just grab a library" culture. This is not to say you should develop everything in-house, but on a spectrum, I have the hunch that this easy accumulation of dependencies induces a culture that does not vet the stability of the dependencies. Once one of your dependencies is unstable, the project on which it depends cannot be stable.

5 comments

> At the risk of this being interpreted as trolling; don't we have this, for crucial OS interfaces at least?

For crucial OS interfaces, yes. For the ecosystem of libraries and packages, no. But ultimately Linux is more than just crucial interfaces. The ecosystem of applications and libraries that we need to get anything really useful done does constantly change, and it would be nice if there was a OS + programming language + culture for "forever apps" that are designed to work for centuries without a material risk of an auto-update breaking anything.

Sort of how Rust is designed around safety, that's what would be nice. I know it wouldn't be perfect, for the reasons I listed above, but for the areas where we are at least trying to have things work for good I think it would materially help.

> The ecosystem of applications and libraries that we need to get anything really useful done

I'd argue that you can get lot of useful things done with plain POSIX/C

> a OS + programming language + culture for "forever apps"

Isn't POSIX + C exactly that? Sure, not many people stick within those bounds, but those who do tend to care a lot about not breaking stuff.

yeah, except POSIX and C also aren't set in stone, also evolve, deprecate stuff, remove features, just like everything else.
Yeah, C and Java have had non-breaking changes for years. Java code from 1995 can still compile and execute in Java 17 (2021).

I imagine COBOL is similarly stable but I have no experience there.

> 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,...

But Java 8 -> 16 doesn’t work without changes.
Completely depends. You can write Java in 2021 that works with both old and new Java, especially if you don’t use any dependencies.
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.

Not any longer, as per Java 17, people have had enough time to port their code, and those switches now "do nothing".

This is the last step before they get fully removed.

None of those changes are required for use, and more importantly, nothing has been DROPPED to make old code obsolete.
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.
Depends, some libraries work, some need special parameters, some don't work at all
Good luck running a binary from 2005 on a modern Linux distro.
GitHub was built to host source code though.
> a programming language and OS that does its best to not change

you've heard of this thing called Windows?

Yes. Windows is extremely backwards compatible. This could be, ironically, one of the reasons some people don't like it too much. See Raymond Chen's The Old New Thing [1] for some technical details.

[1] http://ptgmedia.pearsoncmg.com/images/9780321440303/samplech...

The latest Windows update won't install for me. It pops up an error saying "Uninstall this app now. It is not compatible with Windows 10."

Yes, it says "now," in command form. And the app, VirtualBox, works just fine in Windows 10.

Doesn't seem very backwards compatible these days.

If the program manifest doesn't advertize compatibility with the current version of the system, its window will be scaled.
Since when do windows break most programs every few months? Having to write a patch every few years when Microsoft releases a new OS is pretty low maintenance. And most of the time windows is backwards compatible nowadays, so usually you don't even need to do that.

Most 10 year old games still runs on modern windows even without patches etc.

> The C language also has a stable ABI, which is basically the ffi for most languages,

C is honestly terrible to target/use as FFI, doing so precludes doing things correctly, or more advanced things like... say arrays that "know their own length" or numeric-types that are range-constrained.

>say arrays that "know their own length"

There's a fair amount of C code that does just that and does it for a long time.

>or numeric-types that are range-constrained.

Those don't need astral and can be passed through C ABI just fine.

>>say arrays that "know their own length"

>

> There's a fair amount of C code that does just that and does it for a long time.

No, there isn't.

There can't be because of how arrays in C degenerate into pointers/addresses; see Walter Bright's "C's Biggest Mistake" -- here: https://www.digitalmars.com/articles/C-biggest-mistake.html

>> or numeric-types that are range-constrained.

> Those don't need astral and can be passed through C ABI just fine.

No, they can't.

If you're passing a "Positive" through C's ABI you lose the fact that the value can be neither negative, nor zero. (Unless you mean "passed through" as in, "not mangled", but this is setting the bar so low as to be laughable.)