Hacker News Reader

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

> a programming language and OS that does its best to not change

you've heard of this thing called Windows?

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.

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.

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.

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

But Java 8 -> 16 doesn’t work without changes.

Depends, some libraries work, some need special parameters, some don't work at all

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

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.

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.

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

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

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

Good luck running a binary from 2005 on a modern Linux distro.

GitHub was built to host source code though.

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

No building stands for 100 years without maintenance. 100 years ago heating and light by coal or gas were still common, so every single old building has had upgrades to electricity (or first gas, then electric). The roof leaked, the wood rotted, a bunch of people died in a fire and now all buildings in a similar style need to add a fire escape...

There are hundreds of churches in Europe who have stood for centuries without the "maintenance" you are talking about. You are talking about upgrades, not maintenance. Adding gas and electricity are modern (< 150 years ago) things, as are earthquake codes, fire escapes, etc. I'm not suggesting people go live in cathedrals, but there's a huge hole in your reasoning.

Hell, here in Sweden there lots of old houses that are in dire shape BECAUSE they received “maintenance” to keep them modern, resulting in problems with mold and insects.

The parallel to breaking working code while updating it to follows modern standards isn’t too far fetched.

Both here and in code, upgrading to keep up with progress of technology is good. Upgrading to keep up with progress of business - aka. ways to provide less value for more money - is bad. Old technology was often immune to value engineering simply because people didn't knew how to cut corners with it.

Ime, “upgrading to keep up with the progress of technology” is often code for “I haven’t learned the paradigm behind this legacy code base, but I know it’s bad”. I’ve spent so much time arguing against fad-driven development where people insist on rewriting year-old redux apps to use hooks because “hooks are the future”. At this point, I more or less reflexively oppose anyone who argues for a new technology just because it’s new.

Every old church I've ever been in has had some kind of donation drive on the notice board asking for help replacing missing tiles, rotting roof beams etc.

I don't know if the British were just exceptionally bad church builders and contemporary European churches are doing just fine but I would hazard a guess that no, they also require spectacularly large amounts of maintenance to keep the weather out too.

True, but this is preventing a kind of decay that software is, by its digital nature, immune to. Information doesn't weather or rot. There's no software equivalent to "missing tiles" or "rotting roof beams".

“Link rot” and “bit rot” are terms that have entered our common vocabulary. I think information gets weathered down by contact with humans, who are an incredible source of entropy.

Yes, this kind of upkeep is definitely required. Replacing little things as they break and keeping an eye out for issues. Old things require this upkeep, which is a different thing from rebuilding, replacing, or upgrading. But the goal of upkeep is to keep the thing in good shape, and usually without any visible change at all, rather than transforming it into something different (assumedly better, but not really). Upkeep is preservation, conservation. We've somehow forgotten how to do that for the vast majority of things.

Then consider NASA Voyager. It's been floating around the galaxy for 44 years. If all goes well, its onboard computer won't run out of power until October 10, 2166.

>"Protocols change, programming languages change, human languages change, boarders change, definitions of time change, laws change, sensors change, and on and on."

I have 17 years old Windows desktop product that I've long abandoned. But it is exactly this: single exe with everything compiled in. It uses DirectX 9 and Directshow. It still runs fine without any tweaking. It even compiles fine from source code. So from a practical standpoint it is maintenance free.

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

Believe it or not this is a core design goal of the Urbit ecosystem. The core bytecode should be simple (and stable) enough that some future archaeologist can implement an interpreter in a weekend and run programs. They take it so far that their version numbers run _backwards_, with the idea that once they reach version 0 nothing will ever change again: https://urbit.org/blog/toward-a-frozen-operating-system

> 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. Fixing security bugs and supporting new emojis, fine. We have to do stuff like that. But everything else is just as frozen as can be. It would be useful for super long term software. If we have buildings still around from 100 years ago we should be able to build for 100 years from now without a team around for constant maintenance. Though I do not think it can ever be maintenance free.

you can fire up QBasic on dosbox just fine

The last update to MS-Dos was over twenty years ago. I'm longing for something more than mere backwards compatibility.

So you want "there should at least be a programming language and OS that does its best to not change", and you also want updates for it?

FreeDOS is regularly updated

> Unless you're doing something mathematical, where you can exhaustively test every input and output and ship something that's essentially close to the platonic ideal of the thing, you're going to need to update.

You only need to update dependencies that interact with things that change autonomously.

For the types of programs I write, that describes very few, sometimes none, of my dependencies.

Continuous updating of dependencies is valuable in some circumstances. Not all.

> 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

A passable implementation of Lorie's UVC concept[1] is sitting right in our lap, it's just hardly ever put to use in this way, and it's considered by some not to be very sexy—or rather, it's popular to dump on it for various reasons. But you're probably using it right now to read this comment, and the reason is that its availability and reliability is a foregone conclusion by every stakeholder in this conversation—whether that be me, you, or our hosts involving Y Combinator &co. And with respect to the article, it's a foregone conclusion that it will also be involved in the tech tree of the example projects given. Jeff even mentions its longevity explicitly—in a comparison to Python, where Python is considered the worse of the two. How about just not depending on Python at all?

If you click through to Jeff's "makerss.py" script and look at the kinds of machinations that it does, consider whether this stuff could instead be taken care of directly in a "README.html" in the repo root. No implicit[2] assumptions about what software is installed on the machine in question—since it's using the UVC after all—and none of the Python 2/Python 3 fuss. (It'd have to forego the symlinking that makerss.py does near the end (currently line 1717 and 1719), but that should arguably already be handled elsewhere, anyway.)

1. https://news.ycombinator.com/item?id=11512892

2. https://news.ycombinator.com/item?id=22991033

> consider whether this stuff could instead be taken care of directly in a "README.html" in the repo root

I'm not sure what you mean?

From <https://news.ycombinator.com/item?id=28407936>:

> If folks were really committed to improving the developer experience, then instead of what we do now [...] development would work like this: ¶1. Download the project source tree ¶2. Open README.html ¶3. Drag and drop the project source onto README.html

If this is still unclear, please let me know. (Please also let me know if it is clear. I'm very interested getting this explanation "right", so it's easy to understand.)

Software would be incredibly "low upkeep" to last as long as HTTP. You don't have to use a new programming language just because it exists. Time zone info is a data file managed by the OS and has no business being baked into specific programs. Translations are likewise data files and should be modular so that you can add or replace them without invalidating the program. Sensors change much slower than software; the oldest and crustiest operating system image you'll ever meet is the one coupled to a multi-million-dollar sensor in a lab or a hospital.

We perhaps need a LongNow Smartphone.