Earlier quoted context omitted.
Being someone from back in those days they'll tell you to load up that software that fits in some small amount of memory. You'll find most of it is crash filled hot garbage missing the features you need. And the moment you wanted to add new features you'd start importing libraries bloating the size of the application.
So you would say programs today are equally efficient and more stable, just have more features?
But this of course is in the metrics of how you measure. Windows 3.1 for example was a huge crashing piece of crap that was locking up all the damned time. MacOS at the time wasn't that much better. Now I can leave windows up for a month at a time between security reboots. Specialized Windows and Linux machines in server environments on a reduced patching schedule will stay up far longer, but generally security updates are what limits the uptime.
I remember running Windows applications and receiving buffer overflow errors back then. If you got a buffer overflow message today you'd think that either your hardware is going bad or someone wrote a terrible security flaw into your application. And back there were security flaws everywhere. 'Smashing the stack for fun and profit' wasn't wrote till '95, well after consumers had started getting on the internet in mass. And if you were using applications like Word or Excel you could expect to measure 'crashes' per week rather than the crashes per month, many of which are completely recoverable in applications like office.