It's funny how if you ask people about forward-looking systems today, they have either learned mistruths or haven't learned enough about the history of computing to picture much that's reasonable.
"Java!" used to be talked about as a good way to create software that you could run in the future, but anyone who has had to keep around old laptops / old VMs to run ancient Java to handle KVMs or device management tools knows how ridiculous an expectation about the stability of Java can be.
"Windows!" is funny, because I can't tell you the number of places that have an ancient Windows PC that has either been repaired or carefully replaced with new enough, yet old enough hardware to still run Windows 2000 or XP, because copy protection is stupid, and / or because drivers for specific hardware can't be updated or run on newer Windows, and / or because the software can't be compiled and run on newer Windows without tons of work.
On the other hand, you can take large, complicated programs from the 1980s written in C and compile them on a modern Unix computer without issues, even when the modern computer is running architectures which hadn't even been dreamt of when the software was written...
> "Java!" used to be talked about as a good way to create software that you could run in the future, but anyone who has had to keep around old laptops / old VMs to run ancient Java to handle KVMs or device management tools knows how ridiculous an expectation about the stability of Java can be.
Hard disagree. In my 20 years of experience, Java is very, very, extremely stable and backwards-compatible.
I would absolutely expect Java bytecode compiled in 1996 on Java 1.1 to have a very good chance to run without errors on a brand new Java 20 JVM, and source code from that time to compile with some very minor adjustments such as changing identifiers that clash with newly introduced keywords. Ironically, the older the code, the less likely it is to have problems with the post-Java 8 breaking changes.
But you talk about "handling KVMs or device management tools" - that's hardware stuff not covered by Java's standard API, so it will involve native code. That will bring you compatibility problems, not Java. Admittedly, that could be seen as Java avoiding the hard problems rather than solving them.
> On the other hand, you can take large, complicated programs from the 1980s written in C and compile them on a modern Unix computer without issues, even when the modern computer is running architectures which hadn't even been dreamt of when the software was written...
I want some of what you're smoking. Toy programs, sure. But nothing that does any kind of hardware interfacing (notice a theme?) or uses any but the most trivial syscalls (this would be pre POSIX), or makes any of a myriad common assumptions about hardware architecture (see https://catb.org/jargon/html/V/vaxocentrism.html). So how many large, complicated programs does that really leave?
Good point about Java, even though talking to KVMs over the network and displaying a GUI isn't really hardware stuff.
But I think you're forgetting how much code is written to C89. How much of bash, for instance, is ancient, with updates that avoid newer toolchain features so that it can be as portable as possible?
Yes, people don't often write stuff with portability as a goal at the beginning, but once something is relatively portable, it stays that way. Lots of code that wasn't poorly written made it from all-the-world's-a-VAX to i386, from i386 to amd64, and now ARM and aarch64, with a minimum of extra effort. There just had to be a little effort to NOT program like a jerk, which, as funny as it is, is still an issue now.
I'm running Pine as my daily email program, which was written in 1989 and hasn't had any real updates since 2005. New architecture? Compile it. Lots of modern software started out as C software from the 1980s.
> Good point about Java, even though talking to KVMs over the network and displaying a GUI isn't really hardware stuff.
If it's over the network (using IP sockets), Java can do it just fine and what I wrote about downwards compatibility applies. Same if it's a Swing GUI, which is part of the standard API. Admittedly, Swing is the area where I once witnessed a real bug caused by version incompatibility; IIRC code made some assumptions about undocumented behaviour in event handling, which caused an endless loop on a newer JVM.
As for portable C, I have very limited experience really working with C, but remember trying to get some tarballs to compile and having big problems with fragile autoconf scripts.
Windows is a particularly funny one, considering how quick the advice for most issues turns to doing a fresh install. It's a very brittle black box once you try to do any amount of changes from default settings.
"Java!" used to be talked about as a good way to create software that you could run in the future, but anyone who has had to keep around old laptops / old VMs to run ancient Java to handle KVMs or device management tools knows how ridiculous an expectation about the stability of Java can be.
"Windows!" is funny, because I can't tell you the number of places that have an ancient Windows PC that has either been repaired or carefully replaced with new enough, yet old enough hardware to still run Windows 2000 or XP, because copy protection is stupid, and / or because drivers for specific hardware can't be updated or run on newer Windows, and / or because the software can't be compiled and run on newer Windows without tons of work.
On the other hand, you can take large, complicated programs from the 1980s written in C and compile them on a modern Unix computer without issues, even when the modern computer is running architectures which hadn't even been dreamt of when the software was written...