I wish that that someone did some tests between old and new software, I bet uptime of old software/hardware would be higher than our current tech stack.
I don't know about uptime, but most of the new programming languages have no undefined behavior (a Java program always behaves as a Java program whatever your bugs are), while most of the old languages do have undefined behavior (even Ada has garbage-initialized variables.) Hardware-wise, there's memory protection and virtualization, whereas old Unix, Windows, etc. all let you crap all over any piece of memory because there was no efficient way to prevent arbitrary machine code from doing that. Security also improved tremendously, in relative terms.
So we're far from unhackable, never-crashing software, but then cars, too are still relatively dangerous, just much less so than they used to be.
(Now one interesting thing that I wonder about, though, with all those thank yous going out to the government, Ralph Nader and other deities in sibling comments, is just how reliable this crash test is; meaning, what happens if you try other angles, which are not in the standard test.)
>I don't know about uptime, but most of the new programming languages have no undefined behavior (a Java program always behaves as a Java program whatever your bugs are), while most of the old languages do have undefined behavior (even Ada has garbage-initialized variables.)
BTW, Java does have implementation-defined or unspecified behavior (for instance, using the same objects from different threads without proper coordination), but there's much less of it and it's easier to avoid.
That's true, and it's true of most languages, and unfortunately people trip over it even when they can totally avoid it by hiding threads behind other abstractions. So yeah, silly of me to have forgotten it.
That said, AFAIK language-level invariants in Java (and Python, etc.) cannot be violated by the lack of thread safety; meaning, you can still inspect every live object and see its state. Program-level invariants might go to heck, for sure. So what I should have said is more along the lines of "memory safety" than "lack of undefined behavior"; I'm not sure what the shortest and most precise way to put it is, though. (It does not quite end with memory safety but it doesn't quite get to lack of undefined behavior, either.)
Much of development and the stack has become better. I still remember writing code in Pascal when I'd been much younger when my program would randomly stop working. Eventually I would insert an empty line between two lines of code and suddenly it'd work again.
A lot of work has been put into tools and our general ability to write better code (although whether we do so or not is a different issue).
Also consider line counts, driven by functionality demands. A Unix from the 1970s has a kernel with maybe <10KLOC? Linux is more like 15000KLOC. If due to bugs, Linux crashes twice as often as that old Unix, then on a line for line basis, each Linux line is still 750x more reliable on average than the old Unix lines.
So we're far from unhackable, never-crashing software, but then cars, too are still relatively dangerous, just much less so than they used to be.
(Now one interesting thing that I wonder about, though, with all those thank yous going out to the government, Ralph Nader and other deities in sibling comments, is just how reliable this crash test is; meaning, what happens if you try other angles, which are not in the standard test.)