What is software bloat? Throughout my life, and the decades before, I have heard over and over again about the advances in computer hardware. I have studied how computers execute instructions, designed simple ones in RTL, and seen them get faster over time, mostly due to making use of the advances in semiconductor nodes. However, software has, on average, remained roughly the same speed and proportional memory usage throughout my lifetime, as seen in Wirth’s Law.

I’m not sure if I’m allowed to promote my own (relevant) articles on here, please let me know. I have a series of blogs about my takes on technology and a work in progress series on how to get computers to count really fast.

  • Arrandee@lemmy.worldEnglish
    3·
    16 hours ago

    Scroll through your typical node_modules directory without learning a little something about software bloat. Yikes.

    It’s quite a lot, what we expect from our technology now. But we made it this way because the marketplace has deemed there must always be a winner and a loser, so it’s a never ending game of accelerationist oneupmanship.

    The market pressures the competitors, the competitors pressure the engineers, the engineers pressure each other to deliver faster and faster. Sometimes they’re backed into a corner and have to focus on more speed and efficiency, which is shortly thereafter consumed by frameworks, languages, and operating systems that are also competing for adopters, and thus supply stuff like JIT compilers and UI frameworks.

    Even before we were plunged into the hellscape of vibe coding, you could knock an app together with a kit of parts using a pinch of glue code, having no clue what’s happening underneath the gui. Who cares? My Mac at idle is running hundreds of processes, it can take it. Until of course it can’t.

    Back in olden times, a piece of software was painstakingly hand-built in assembler and C over a course of many months. But ain’t nobody got time for that when your manager can shit out an app with Claude in an afternoon.