So a few weeks ago I come across a post calling the engineers of old “lazy” because a decision to not record all 4 digits of a year led to a worldwide crunch that became known as “Y2K”. And now… we have a post saying “And yet we wonder why software today is so bloated and inefficient” because… Doom, from 1993, could fit on two floppy disks…
Oh brother…
“Fast forward to today, and a simple video player app like YouTube is more than 300MB. Just to play videos.”
The YouTube app is a lot more than just a video player. And playing videos involves a lot more than he seems to realize. VLC has an installation footprint of nearly 200 MB, and it is literally *just* a media player.
He’s also vastly overstating Doom’s simplicity. It wasn’t “full 3D”, for starters, nor immersive. And Doom overall is very simple: run and shoot, grab keys and other items and weapons, open doors, push buttons.
Doom also targeted the i386 processor. Yes, that detail matters. A lot.
To get an idea of what trying to write a game like Doom for the i386 involved, the source code for it is on Github.
Here’s a challenge: go through the code and count the number of coding best practices that are NOT being followed. To get something like Doom performing reasonably well on the i386, you needed to make a lot of compromises.
Simply due to the limitations of the hardware. Limitations that largely don’t exist today.
He’d say in another comment: “When your options shrink, your creativity expands. Constraints are the best teacher.”
To an extent this is true. It also reveals whether everything you want to include in the product can be included.
Since that’s the singular reason software today could be called “bloated” compared to years prior: more and better functionality.
VLC, for example, plays most every media file format that’s ever existed. It takes a LOT of code to support that. Even browsers haven’t been immune to that “bloat” with everything they need to support, with Chromium-based browsers and Firefox both having install footprints of a few hundred megabytes.
And sure constraints are a good teacher. I’d like to see young devs today try to write programs for the TI-82 and it’s 28 kilobytes of user space.
But those constraints can also push you to write bad code to get it working per your requirements, provided that’s even possible at all, potentially introducing bugs that may not be repairable due to your constraints.
Personally having faced the limitations of the past, including coding for the TI-82 and TI-85, I’m glad they, for the most part, don’t really exist anymore.
Since, again, much of the “bloat” Marc is describing (and complaining about) is due to… more and better functionality. Giving customers what they want and what they didn’t know they needed till they had it.
