I agree with the author’s statement of the factual elements, size of binaries, memory utilization, load speeds, resource intensive simple task applications.
But I disagree with the author’s reasoning and line of thinking regarding the how and why.
The functionality and tome period being referenced for when things were simple and fast referred to a period when your interface was lot resolution or entirely text baed. The action of updating information on the screen and the information on the back end was minimal. Contrast that to today, where you are dealing with a large display with high resolution imaging. You are now talking about a full blown HD gui where your screen updates includes plenty of images, videos, and on the back end, you’re handling edits that may or may not even be local resources, subject to network latencies.
Also, modern computers are basically all multi-user systems under the hood, configured by design to be able to recognize, load drivers for, and initialize any and all devices you might deem fit to stick into the computer. Your text editing is running at the same time the system is performing back end scans, probably running multiple web pages, mini services, etc.
Not saying there isn’t inefficiency or that there isn’t really bad design. But rather than look at it as meaningless, understand the underlying mechanism for why.
Why has no major project taken on the task of a new lean kernel? Why? You can existing kernels and slim them down. Open source means being able to take kernel source, reconfigure it to remove the bulk of the cruft you don’t need, and shrink down your footprint.
It also means you OS doesn’t need to be the size of one or more DVD(s), you can slim it down.
Same thing for compilation toolchains. You can slim it down. You don’t need to include every library you’ve ever loaded onto your compile environment.
There ARE lightweight text editors out there. The heavy weight ones are because people wanted to support all kinds of fonts, formatting, input/output file formats, multi-media, etc. You want to pare that down, you can.
Sure, there are lazy coders out there. But what one person calls extra cruft, another person calls tech debt waiting to happen.
So you write a super light weight piece of code that doesn’t need to incorporate any special libraries because you wrote it all using standard library calls. Yay. Who is going to maintain that when you leave?
You write an application component and forego all of the build toolchain and frameworks that make up so much bulk now, so you hardcore everything. That’s a maintennace nightmare when it gets deployed and other people need to integrate it into a productional stack because no one ever bothered to ready it for CD/CI.
Yes, there is alot that sucks about software design at large. But the author is painting with a broad brush, focusing on one set of pet peeves, as observed, and ignoring the underlying reasons for why those design decisions might be in place.
For build environments: npm, python, runy, golang, etc: you can configure the build environment for your piece of code to require a specific version of npm, dependencies, etc. this would freeze the runtime environment so that as the language at large advances, you aren’t forced into a broken state. This applies to OS package management as well.
The example of DOS being able to run on modern hardware... that is only seeing one facet of the situation. Yes, DOS itself, which is x86 code, can run on modern hardware unchanged.... but that isn’t because of excellent coding. That is because of the massive effort put in by the chip makers to maintain backwards compatibility. In that example, the bulk and legacy stuff just got offloaded to hardware. :/ it works not because it’s great, but because the hardward was designed to allow it to keep working.
Much in the same say that some of the more visible software bloat exists: backwards compatibility, cross compatibility, wide array of hardware compatibility, file and data format compatibility, language compatibility, etc.
The author makes some good points, but I think that the author also has some tunnel vision going on.
Can UI be improved and be less bulky? Hell yes.
Can applications return to their simple roots and be highly performant and low latency, hell yes(as long as you are willing to pare down on optional functionality)
- can we tun fast OS environments on “older” hardware? Yes! But with the caveat that the price you pay is using older libraries, older methods, or having to back-port code yourself.