I wrote a reply to this on my blog (<a href="https://jlelse.blog/links/2020/11/stupid-light-software" rel="nofollow">https://jlelse.blog/links/2020/11/stupid-light-software</a>):<p>With software I most often go from “heavy” to “light”. First, I try to realize the features I need and then I try to optimize where possible. First, I will use many libraries and after I got everything working, I will see if I really need all those libraries and may replace a whole library with a custom more simple implementation that still fits the needs.<p>A case for “stupid light” software is probably trying to use a static website when an optimized dynamic site is much more appropriate. You start to over-engineer a complex build workflow, when all that’s really needed to speed up a site is better caching.<p>I have some experiences especially related to the database point. When I developed Android apps, I tried to use flat text files too. But recently I discovered how awesome SQLite is. In some cases flat files are great, but especially when you need to parse those files or retrieve specific information from them, SQLite might be better than flat files. But in many cases SQLite could replace complex PostgreSQL or MariaDB databases, especially when concurrent writing isn’t needed.
Is "stupid light hiking" really a proper comparison. In the case of hiking, the hiker is making the choices and the hiker is the one who will have to live (or die) with them. In the case of software, too often it is a commercially-oriented application developer making the choices and it is a different person, a user, who must live with them. The hiker has control over her choices. The user has no control over the application developer's choices.<p>In some ways, the best programs are the ones I write for own use only. I know the user better than anyone and I have full control over the design choices. Obviously, choosing not to use someone else's software is ineffective as a means of controlling someone else's design choices. Perhaps unsolicited "advice" found in blogs might have some influence though.
I once heard someone say (paraphrased), "To some programmers RAM is like that couch in your grandmother's living room, with a plastic cover, that nobody's ever actually allowed to sit on."
As an aside "Stupid light" hiking is a great term for it. I recall a case where a British hiker died a long and lonely death in our country when he broke a leg a few days into a 4 week journey. Locals had encouraged him go take a locator beacon (due to the rough terrain and remoteness), but he'd refused, because it weighed too much.
If i am ever in a situation where i am considering SQLite, i will try to use DuckDB instead. It's a similar weight (the all-inclusive JARs are 6.9 MB for SQLite and 8.7 for DuckDB), it also stores a database in a single file, it's different in many ways, but for me, the killer feature is that it uses the PostgreSQL SQL syntax (and parser). This should make it very easy to migrate from DuckDB to PostgreSQL if that becomes necessary.<p>I currently work on a project based around SQLite, which suffers from that fact. Migrating it to PostgreSQL would be great, but would involve a lot of tedious work.
This article, in the age where a chat app eats gigabytes of RAM, is almost insulting.<p>And it's not like it's nothing because we have terabytes of RAM now. A 2020 laptop I'm eyeing only comes in 8GB/16GB soldered RAM config; and the 16GB version has been sold out since the release. Which is not surprising, since the browser alone easily needs 8GB in a medium-heavy session.<p>Stupid light? Call me when common software isn't <i>stupid heavy</i>.