One my friend noted that many people think that the UNIX principle is “do one thing”, while its original wording is “do one thing, and do it well”.
So many “lightweight” projects indeed don’t do anything especially well, and then it doesn’t matter whether they do one thing or many. Size by itself is not an advantage.
I’ve always found that ‘one’ thing is a bit ambiguous. You can argue that ‘converting file formats’ is a single thing just as well as ‘converting png to bmp files’ is one thing. People probably expect something in the middle, e.g. ‘converting images’. In practice, many programs will also allow you to resize, clip, rotate, etc.
So maybe ‘clearly define your scope’ is a better alternative to ‘do one thing’. Not as catchy, of course.
Good point. In my mind, VLC does one thing. But of course it does a lot. I mean it can even show videos on a chrome cast. It exists on pretty much all major platforms and now to contradict myself I’m not sure if it does one thing… I’m just confused.
Does OBS do one thing? I’d say so but it has a lot of uses: like you can even use it as a virtual camera…
Sometimes the web comes close. Depending on how you use it, smalltalk can. Maybe by “close” I should say “closer than anyone else”. We need to do better.
I think many browsers come close. Netscape. IE. Opera 3-12 wanted to do many things, but you could disable all but the browser components. Today, it’s browsers like Dillo, NetSurf, and Links. My favorite browser today is great too, but it might as well be textmode…
SimpleScreenRecorder is amazing, and does no more and no less than it promises, unless you count partial screen recording as a different thing.
Looking only at GUI composability and nothing else, I’ve yet to see anything come close to how good Visual Basic is, and I’m talking about VB3 - VB6, not newer stuff. VBA falls under this umbrella as well, though Office integration complicates things a bit.
As far as what’s available, relevant, and floss today, you’re looking at it, it’s HTML, JS, and CSS. If you try my website, it works in 25 years worth of browsers. I’ve tested it on Windows 95 and up, and I’m confident it would work in Windows 3.1. It works (in compat mode) in IE2 on NT4. It also works in textmode browsers and with various accessibility useragents such as screenreaders. It’s zoomable, resizable, and modifiable.
It’s written by one borderline-idiot but very determined programmer, working part time, over the course of a couple of years. A roomfull of Googlers could rewrite it in 36 hours, probably. Why don’t they? I don’t know, but I would be embarrassed to have anything to do with most of today’s mainstream Web properties. If I could put today’s Gmail or Reddit on my resume, I’d probably leave it off out of shame and pad the time with something else…
But neverthless, the Web itself remains, and so does the freedom to write compatible code.
This wonderful, miraculous platform has remained stable enough over this time for me to be able to plan ahead and not be caught off-guard by something like “we’re deprecating version 2.0, please use new version 3.0 syntax” or “your platform is now obsolete, please switch to the new HTML.NET”. The W3C gang tries, and they fail, because HTML is stronger and bigger than them. The Web is stronger and bigger than all of them combined.
Many have tried to contain it, to own it, to be the main one calling the shots, and HTML laughs in all their collective faces. All thanks to its basic concept of “be strict with yourself, and accepting with others.”
Mosaic was the first browser for which “best viewed with” buttons were used. They failed to own the Web. Then came Netscape, “Mosaic killa”, and they managed to kill Mosaic, but they failed to tame HTML, because HTML will not be owned. Netscape was destroyed by Microsoft-IE, who also wanted to tame and own HTML, and they also failed, because HTML is not ownable.
Then Firefox came and fucked up IE, and things were good for a while, Mozilla was a decent steward. Then Google came and took ownership of Mozilla, and together with Chrome they also tried to tame HTML. They will fail just like the others. HTML cannot be tamed or owned. The Web was built for freedom.
If you want composable, future-proof GUI, open up your notepad.exe and write this:
I’ve generally thought of the “Do one thing” more as “Answer one question, and answer it as completely as possible.”
So if the question is “How do I convert an image to another format.” then an image converting tool should try to completely answer that question. VLC falls into that model much more easily than the ‘do-one-thing’ version. Same thing with Vim or Emacs or VSCode – all different, but fairly complete answers to the question of “How do I efficiently edit text?”
That model helps with the ‘clearly define your scope’ mentioned by @rustybolt fairly effectively, though it is subject to some of the same problems as ‘do one thing’ (“What question should I try to answer?” is a very natural way to break this rubric), but overall it seems to avoid at least some of the problems of the D1TW axiom.
I would add “and play well with others” to that Nix maxim. That’s generally not a problem in the Nix world from what I’ve seen but it’s important to keep in mind: focusing on doing just one thing often means the users has to depend on several pieces of software to accomplish and they need to work well together.
This is a product design question (what features and for whom you want to deliver).
But if we are discussing the simplicity from the user point of view, modular architecture has significant advantage: the user can enable (install, buy, audit, study…) only those features he needs.
The complexity should be optional.
(obviously there is no silver bullet and we can not expect miracles from the modular architecture – it will not solve all your problems, walk your dog and make you a coffee; sometimes even the finding the right combination of modules becomes too complex – then you may need some packs, profiles or separate products that just share some components or the core… however it is still better than monolithic solution where each user uses different 20 % of features)
I’ve often quoted Joel on this myself, but I think that’s missing in Joel’s take is that the 20% of features people use aren’t randomly distributed; you can usually divide use cases and users up in chunks: group A (maybe 30% of the users) use feature set A, group B (20% of users) uses feature set B, etc.
For a lot of stuff it makes sense to think about which “chunk” of users you want to serve. Sometimes “all of them” is a valid answer. Other times less so.
For example, I wrote a User-Agent parsing library a while ago; this is very simple and essentially just returns Firefox on Linux, and nothing more. Many other libraries offer more information, but my guess is that for a good chunk of users this information alone is enough. It doesn’t solve all use cases because it doesn’t need to for many people, and as a consequence the code is a lot simpler, often more reliable, and two times faster than anything else.
Obviously Joel’s remark is only a simplification, but even if you model the distribution better, or even frame it as common features vs long tail, it explains why we keep wanting “simple” software, but keep ending up with “stupid simple” or “bloated” ones.
The phrasing for something closely related in a few circles I move in is ‘simplicity as narcissism’ - though less used to refer to self-deprecating engineering decisions and more of a way of dismissing someone else’s solution in favour of your own, current or tentative; even for motivation as vainly naïve as “I don’t understand this without effort thus it can’t be rightly considered simple.”
I tend to write down and track when someone derides or dismisses something else as ‘bloat/not-simple’ (without any signs of the accuser actually having done due diligence on target audience requirements or basic research hygiene) and check up on it from time to time. The majority of cases, it has turned out that the now competing solution tend to have hilariously complex workarounds for things that the other solution had accounted for.
Demonstrating something being actually simple, not just claiming so because you had the wrong bias-glasses on, is depressingly difficult.
To me this is like voter fraud. The amount of “stupid light” software I actually encounter is statistically zero — especially relative to “stupid heavy” software, which is far more pernicious. And so efforts to stamp it out or whatever wind up catching predominately “smart light” software, and do more harm than good.
I think a lot of suckless projects count as “stupid light”, or at least have major subsystems that count. The complete lack of basic config without recompilation across almost all their projects is an example.
Right. “Stupid light” is a subjective classification, what’s stupid light for you might not be for me. If you find Suckless software stupid light then you wouldn’t use it, and (presumably) everyone using it doesn’t find it stupid light.
The complete lack of basic config without recompilation across almost all their projects is an example.
Does the actually cause a problem for anyone in the target audience for those tools? The dwm config.h is better documented and easier to read than half the other configuration file formats I have to work with. Sure, I have to type “make” after I edit the file, but that’s hardly a hardship – restarting my X environment is more annoying than typing “make”
Sure, when it’s just re-configuration it isn’t much more difficult than typical configuration patterns. However when it gets to managing patch sets for features, I believe it becomes “stupid light.” Because now I must decide on which patch sets I want, ensure they work together, that I’m including them correctly, etc. That is a ton of extra work when compared to some_feature = true|false in a config.
Small nit, source that’s better documented than a config isn’t an argument for using source as the config. Nothing is stopping anyone from documenting a config to the same extent.
Small nit, source that’s better documented than a config isn’t an argument for using source as the config. Nothing is stopping anyone from documenting a config to the same extent.
Absolutely. My point was that the header file is a perfectly fine config file, not that it was magically better documented because of that.
However when it gets to managing patch sets for features, I believe it becomes “stupid light.”
I don’t necessarily disagree, however I would point out that the patches for suckless projects exist to represent rejected features, not optional ones. If you’re using more than one or two at most you’re building a divergent fork, a new project, not configuring withing the scope of the original project.
This comes off a bit as “the other side is worse, so what’s the problem?” I don’t think it’s “statistically zero” either; for example in the Go community sometimes people get a bit too carried away with this IMHO. The whole math.Round() saga is a somewhat famous example of this.
Software design is so contextual. Developers tend to use 3-tier architecture for everything as the default.
I have a solo, multi-million dollar software business. My entire “database” is CSV files. Why? Because I realized I’m unlikely to have more than a few thousand customers and that “database” changes only a few times per day, why do I need a high-performance DBMS running 24/7? OTOH I can make backups with cp, filter with grep, etc and the maintenance overhead is nil.
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.
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.
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.
I get the impression that a lot of the “stupid light” software is designed in the opposite way from that which you describe: that they attempt a minimalist design for every use case rather than building a heavier system and then stripping down the minimum needed to provide the capabilities you want. Perhaps I’m incorrect there, but it seems like much of the “stupid light” cruft out there has to do with programmers who think that their mental model of the world is more real than the world itself and act accordingly.
I am interested in what people in line with this sort of thinking would do when confronted with software like Fusion 360 for 3d modelling.
For word processing, I could argue that Wordperfect 5.1 was probably one of the most useful word processors I had ever used - even though I might miss a few things from Word today.
For me it’s rather strange that neither the post nor comments even try to name a piece of software that falls into this “stupid light” category. Should, for example, suckless tools be placed under this label?
I don’t really want to call out people’s work as “stupid”, especially if they’re hobby projects people work on in their spare time. I can think of a few examples, but does adding them really add any value? I’m not so sure that it does. Arguably “stupid light” isn’t really the best wording here – the original usage in hiking context is mostly a self-deprecating one – and a different one without “stupid” would be better, but I couldn’t really think of anything better 🤷♂️ And it does have a nice ring to it.
More importantly, what might be stupid light for one person might actually be just fine for another. I usually use very lightweight sleeping bags because I don’t get cold easily, so cutting out weight here makes sense for me. Other people get cold easier and it would be a poor choice for them. It also depends on what you’re doing and environment; a 2 day hike though the forest with a 30°C temperature is not the same as a 3 week hike in the mountains.
For me, dwm, dmenu, and st are exactly right; they cut out features I don’t need or use, and provide the exact feature set I want (I actually stripped some features from dwm). For others, it’ll be different. If you’re not at least superficially familiar with C then the lack of an easier config file would be stupid light. The whole advanced ways to split windows in i3 is just needless bloat and more confusing than anything else, and much prefer dwm’s simpler model. Others would undoubtedly disagree as they use this a lot, and for them dwm would be stupid light.
This post was inspired by a comment I made when someone asked for opinions on 40% keyboards, and I called them “stupid light”. But clearly these keyboards are useful to some people and aren’t stupid light for them. For me they are, as I often use keys not present on them.
This isn’t something you can measure and define exactly, just like you can’t measure and exactly define bloat. It depends on a lot of factors. But just as it’s worth thinking about “do we really need this?” to avoid bloat, it’s also worth thinking about “can we really do without this?” to avoid stupid light.
This deck was a great read. I feel like it might be the opposite takeaway, although it’s definitely relevant.
In mandoc’s case they shifted from reusing a heavier tool (SQLite) to writing a lighter one that was better-suited for their problem (less maintenance from audits).
In this article’s case they’re advocating to be careful when favoring a lighter tool over a heavier one, because you might end up with a tool that’s stupid light (useless and fragile).
I think “light” and “heavy” are too vague, multidimensional, contextual, and sometimes subjective to generalized into any kind of coherent or mature software ideology. Maybe I’m boring, but I feel that minimalism and other aesthetic value sets should be left to more artistic disciplines, and engineers should focus on more meaningful targets like correctness, safety, and performance.
I don’t see it as an aesthetic. Software is hard, and the more you have of it the harder it gets. Time is limited, and best spent on things that matter the most. For me anyway, it’s very pragmatic and targetted towards exactly those things you mentioned: correctness, safety, and performance. I mean, the less code you have, the better the chance that it’s correct, safe, and performant? You just need to make sure you don’t get too carried away with this.
A reaction I often have to discussions of software minimalism online is, they’re not minimizing what I want to minimize. Not that I judge anyone for picking themselves a specific metric or bright line, it’s just rare that I read about it and say, “yeah, that’s me.”
When I think about smaller software, I’m not exactly optimizing for CPU cycles, RAM, bandwidth, lines of code, ms of response time, or strictly minimizing deps on libs/services/technologies (say, commercial cloud services or JS). I think the question I ask myself is what choices make a personal (or otherwise small) project likely to be worthwhile long-term. That means worth the effort to build, worth any bills to run it (so resource use does matter to some extent), worth the trouble to maintain (many dependencies or bad deps can bite you there), and worth using (so user-facing perf also does matter some).
A corollary to that is that different things can feel “light” to different people depending on what they’re comfortable with and their task, and I think that’s a feature not a bug. SQLite is simpler than MySQL, and Postgres has many advantages, but after dealing with MySQL most of my working life, maybe it’s what I reach for even if many shouldn’t. Or: the Rust folks are doing great stuff and I’d like to keep learning the language but today I’d have an easier time whipping something up in Go.
And likewise I don’t judge someone who is up-to-date on frontend stuff and finds it simpler to build an SPA with React hitting a JSON API instead of rendering HTML server-side, though that wouldn’t make sense for me. Or someone who knows WordPress or Drupal or something and wants to go to town with it.
Then, of course, you might ask how you can pick out what software is doing this best, or know when you’ve got your own choices right. You don’t! And that’s fine. I’m happy to read people’s writeups of their projects using wildly different approaches, with no need to rank them at the end. I might find some folks whose quirks align with mine, or might learn new stuff from someone with a different approach.
Again, I’m not trying to yuck anyone’s yum, and some flavor of minimalism is a big part of what kept my job sustainable. It’s just that it’s a local, pragmatic, balancing, vague minimalism that doesn’t really lend itself to universal principles/comparisons/definitions.
It seems like some commenters here didn’t read the article carefully and interpreted “stupid light” to be a positive description. I interpret it to be negative: as in, software that’s so “lightweight” it’s not actually useful.
I think one important bit to recognize is that switching to something “heavier” from something stupid light because you need additional features is often easier than switching to something lighter, because you might (inadvertently, or on purpose) be using all those extra features somewhere. I think that’s why people tend to complain more about bloated software than “stupid light” software. For instance, switching from a static site generator to a CMS because you need complicated overviews is easier (you can just import the existing pages and add the new functionality) than the other way around (there’s no easy way to export all that complexity out to simpler pages and sometimes you have to rethink the entire approach), so one tends to stick with the heavier solutions for longer, all the while bemoaning how bad it is.
One my friend noted that many people think that the UNIX principle is “do one thing”, while its original wording is “do one thing, and do it well”. So many “lightweight” projects indeed don’t do anything especially well, and then it doesn’t matter whether they do one thing or many. Size by itself is not an advantage.
I’ve always found that ‘one’ thing is a bit ambiguous. You can argue that ‘converting file formats’ is a single thing just as well as ‘converting png to bmp files’ is one thing. People probably expect something in the middle, e.g. ‘converting images’. In practice, many programs will also allow you to resize, clip, rotate, etc.
So maybe ‘clearly define your scope’ is a better alternative to ‘do one thing’. Not as catchy, of course.
Good point. In my mind, VLC does one thing. But of course it does a lot. I mean it can even show videos on a chrome cast. It exists on pretty much all major platforms and now to contradict myself I’m not sure if it does one thing… I’m just confused.
Does OBS do one thing? I’d say so but it has a lot of uses: like you can even use it as a virtual camera…
Almost no GUI does “one thing” because very few platforms come close to cracking the nut that is GUI composability.
Which do you think come close?
Sometimes the web comes close. Depending on how you use it, smalltalk can. Maybe by “close” I should say “closer than anyone else”. We need to do better.
I think many browsers come close. Netscape. IE. Opera 3-12 wanted to do many things, but you could disable all but the browser components. Today, it’s browsers like Dillo, NetSurf, and Links. My favorite browser today is great too, but it might as well be textmode…
SimpleScreenRecorder is amazing, and does no more and no less than it promises, unless you count partial screen recording as a different thing.
Audacity is great.
ScreenKey.
I’m sorry; I should have been more clear. I meant which platforms come close to cracking GUI composability.
Looking only at GUI composability and nothing else, I’ve yet to see anything come close to how good Visual Basic is, and I’m talking about VB3 - VB6, not newer stuff. VBA falls under this umbrella as well, though Office integration complicates things a bit.
As far as what’s available, relevant, and floss today, you’re looking at it, it’s HTML, JS, and CSS. If you try my website, it works in 25 years worth of browsers. I’ve tested it on Windows 95 and up, and I’m confident it would work in Windows 3.1. It works (in compat mode) in IE2 on NT4. It also works in textmode browsers and with various accessibility useragents such as screenreaders. It’s zoomable, resizable, and modifiable.
It’s written by one borderline-idiot but very determined programmer, working part time, over the course of a couple of years. A roomfull of Googlers could rewrite it in 36 hours, probably. Why don’t they? I don’t know, but I would be embarrassed to have anything to do with most of today’s mainstream Web properties. If I could put today’s Gmail or Reddit on my resume, I’d probably leave it off out of shame and pad the time with something else…
But neverthless, the Web itself remains, and so does the freedom to write compatible code.
This wonderful, miraculous platform has remained stable enough over this time for me to be able to plan ahead and not be caught off-guard by something like “we’re deprecating version 2.0, please use new version 3.0 syntax” or “your platform is now obsolete, please switch to the new HTML.NET”. The W3C gang tries, and they fail, because HTML is stronger and bigger than them. The Web is stronger and bigger than all of them combined.
Many have tried to contain it, to own it, to be the main one calling the shots, and HTML laughs in all their collective faces. All thanks to its basic concept of “be strict with yourself, and accepting with others.”
Mosaic was the first browser for which “best viewed with” buttons were used. They failed to own the Web. Then came Netscape, “Mosaic killa”, and they managed to kill Mosaic, but they failed to tame HTML, because HTML will not be owned. Netscape was destroyed by Microsoft-IE, who also wanted to tame and own HTML, and they also failed, because HTML is not ownable.
Then Firefox came and fucked up IE, and things were good for a while, Mozilla was a decent steward. Then Google came and took ownership of Mozilla, and together with Chrome they also tried to tame HTML. They will fail just like the others. HTML cannot be tamed or owned. The Web was built for freedom.
If you want composable, future-proof GUI, open up your notepad.exe and write this:
This GUI will work as expected and render in 25+ years worth of platform. And it could have been composed by a 10-year-old.
I’ve generally thought of the “Do one thing” more as “Answer one question, and answer it as completely as possible.”
So if the question is “How do I convert an image to another format.” then an image converting tool should try to completely answer that question. VLC falls into that model much more easily than the ‘do-one-thing’ version. Same thing with Vim or Emacs or VSCode – all different, but fairly complete answers to the question of “How do I efficiently edit text?”
That model helps with the ‘clearly define your scope’ mentioned by @rustybolt fairly effectively, though it is subject to some of the same problems as ‘do one thing’ (“What question should I try to answer?” is a very natural way to break this rubric), but overall it seems to avoid at least some of the problems of the D1TW axiom.
I would add “and play well with others” to that Nix maxim. That’s generally not a problem in the Nix world from what I’ve seen but it’s important to keep in mind: focusing on doing just one thing often means the users has to depend on several pieces of software to accomplish and they need to work well together.
I like Joel’s (old) take: everybody uses 20% of your software’s features, but the 80/20 rule doesn’t save you, because each person uses different 20%: https://www.joelonsoftware.com/2006/12/09/simplicity/
The answer is: modular architecture.
That’s not an answer: you still need to maintain the 20%-for-every-user, but you now have a module system to contend with.
Unless you can trick your users into being programmers and extending your functionality for you.
This is a product design question (what features and for whom you want to deliver).
But if we are discussing the simplicity from the user point of view, modular architecture has significant advantage: the user can enable (install, buy, audit, study…) only those features he needs.
The complexity should be optional.
(obviously there is no silver bullet and we can not expect miracles from the modular architecture – it will not solve all your problems, walk your dog and make you a coffee; sometimes even the finding the right combination of modules becomes too complex – then you may need some packs, profiles or separate products that just share some components or the core… however it is still better than monolithic solution where each user uses different 20 % of features)
You need to maintain the 10% that everyone uses. Other people can provide plugins that do the other 90%.
I’ve often quoted Joel on this myself, but I think that’s missing in Joel’s take is that the 20% of features people use aren’t randomly distributed; you can usually divide use cases and users up in chunks: group A (maybe 30% of the users) use feature set A, group B (20% of users) uses feature set B, etc.
For a lot of stuff it makes sense to think about which “chunk” of users you want to serve. Sometimes “all of them” is a valid answer. Other times less so.
For example, I wrote a
User-Agentparsing library a while ago; this is very simple and essentially just returnsFirefox on Linux, and nothing more. Many other libraries offer more information, but my guess is that for a good chunk of users this information alone is enough. It doesn’t solve all use cases because it doesn’t need to for many people, and as a consequence the code is a lot simpler, often more reliable, and two times faster than anything else.Obviously Joel’s remark is only a simplification, but even if you model the distribution better, or even frame it as common features vs long tail, it explains why we keep wanting “simple” software, but keep ending up with “stupid simple” or “bloated” ones.
The phrasing for something closely related in a few circles I move in is ‘simplicity as narcissism’ - though less used to refer to self-deprecating engineering decisions and more of a way of dismissing someone else’s solution in favour of your own, current or tentative; even for motivation as vainly naïve as “I don’t understand this without effort thus it can’t be rightly considered simple.”
I tend to write down and track when someone derides or dismisses something else as ‘bloat/not-simple’ (without any signs of the accuser actually having done due diligence on target audience requirements or basic research hygiene) and check up on it from time to time. The majority of cases, it has turned out that the now competing solution tend to have hilariously complex workarounds for things that the other solution had accounted for.
Demonstrating something being actually simple, not just claiming so because you had the wrong bias-glasses on, is depressingly difficult.
To me this is like voter fraud. The amount of “stupid light” software I actually encounter is statistically zero — especially relative to “stupid heavy” software, which is far more pernicious. And so efforts to stamp it out or whatever wind up catching predominately “smart light” software, and do more harm than good.
I think a lot of suckless projects count as “stupid light”, or at least have major subsystems that count. The complete lack of basic config without recompilation across almost all their projects is an example.
Suckless stuff is entirely opt-in, and so not really germane.
Opt-in, as in you can opt to use the software or not, or what specifically do you mean?
Right. “Stupid light” is a subjective classification, what’s stupid light for you might not be for me. If you find Suckless software stupid light then you wouldn’t use it, and (presumably) everyone using it doesn’t find it stupid light.
Does the actually cause a problem for anyone in the target audience for those tools? The dwm config.h is better documented and easier to read than half the other configuration file formats I have to work with. Sure, I have to type “make” after I edit the file, but that’s hardly a hardship – restarting my X environment is more annoying than typing “make”
Sure, when it’s just re-configuration it isn’t much more difficult than typical configuration patterns. However when it gets to managing patch sets for features, I believe it becomes “stupid light.” Because now I must decide on which patch sets I want, ensure they work together, that I’m including them correctly, etc. That is a ton of extra work when compared to
some_feature = true|falsein a config.Small nit, source that’s better documented than a config isn’t an argument for using source as the config. Nothing is stopping anyone from documenting a config to the same extent.
Absolutely. My point was that the header file is a perfectly fine config file, not that it was magically better documented because of that.
I don’t necessarily disagree, however I would point out that the patches for suckless projects exist to represent rejected features, not optional ones. If you’re using more than one or two at most you’re building a divergent fork, a new project, not configuring withing the scope of the original project.
This comes off a bit as “the other side is worse, so what’s the problem?” I don’t think it’s “statistically zero” either; for example in the Go community sometimes people get a bit too carried away with this IMHO. The whole
math.Round()saga is a somewhat famous example of this.That saga sounds interesting. Do you have a link handy for reading more?
Not the OP but here’s what I’ve found: https://github.com/golang/go/issues/20100
Software design is so contextual. Developers tend to use 3-tier architecture for everything as the default.
I have a solo, multi-million dollar software business. My entire “database” is CSV files. Why? Because I realized I’m unlikely to have more than a few thousand customers and that “database” changes only a few times per day, why do I need a high-performance DBMS running 24/7? OTOH I can make backups with
cp, filter withgrep, etc and the maintenance overhead is nil.I wrote a reply to this on my blog (https://jlelse.blog/links/2020/11/stupid-light-software):
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.
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.
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.
I get the impression that a lot of the “stupid light” software is designed in the opposite way from that which you describe: that they attempt a minimalist design for every use case rather than building a heavier system and then stripping down the minimum needed to provide the capabilities you want. Perhaps I’m incorrect there, but it seems like much of the “stupid light” cruft out there has to do with programmers who think that their mental model of the world is more real than the world itself and act accordingly.
I am interested in what people in line with this sort of thinking would do when confronted with software like Fusion 360 for 3d modelling.
For word processing, I could argue that Wordperfect 5.1 was probably one of the most useful word processors I had ever used - even though I might miss a few things from Word today.
For me it’s rather strange that neither the post nor comments even try to name a piece of software that falls into this “stupid light” category. Should, for example, suckless tools be placed under this label?
I don’t really want to call out people’s work as “stupid”, especially if they’re hobby projects people work on in their spare time. I can think of a few examples, but does adding them really add any value? I’m not so sure that it does. Arguably “stupid light” isn’t really the best wording here – the original usage in hiking context is mostly a self-deprecating one – and a different one without “stupid” would be better, but I couldn’t really think of anything better 🤷♂️ And it does have a nice ring to it.
More importantly, what might be stupid light for one person might actually be just fine for another. I usually use very lightweight sleeping bags because I don’t get cold easily, so cutting out weight here makes sense for me. Other people get cold easier and it would be a poor choice for them. It also depends on what you’re doing and environment; a 2 day hike though the forest with a 30°C temperature is not the same as a 3 week hike in the mountains.
For me,
dwm,dmenu, andstare exactly right; they cut out features I don’t need or use, and provide the exact feature set I want (I actually stripped some features fromdwm). For others, it’ll be different. If you’re not at least superficially familiar with C then the lack of an easier config file would be stupid light. The whole advanced ways to split windows in i3 is just needless bloat and more confusing than anything else, and much prefer dwm’s simpler model. Others would undoubtedly disagree as they use this a lot, and for them dwm would be stupid light.This post was inspired by a comment I made when someone asked for opinions on 40% keyboards, and I called them “stupid light”. But clearly these keyboards are useful to some people and aren’t stupid light for them. For me they are, as I often use keys not present on them.
This isn’t something you can measure and define exactly, just like you can’t measure and exactly define bloat. It depends on a lot of factors. But just as it’s worth thinking about “do we really need this?” to avoid bloat, it’s also worth thinking about “can we really do without this?” to avoid stupid light.
This reminds me of mandoc’s conversion away from sqlite.
This deck was a great read. I feel like it might be the opposite takeaway, although it’s definitely relevant.
In mandoc’s case they shifted from reusing a heavier tool (SQLite) to writing a lighter one that was better-suited for their problem (less maintenance from audits).
In this article’s case they’re advocating to be careful when favoring a lighter tool over a heavier one, because you might end up with a tool that’s stupid light (useless and fragile).
I think “light” and “heavy” are too vague, multidimensional, contextual, and sometimes subjective to generalized into any kind of coherent or mature software ideology. Maybe I’m boring, but I feel that minimalism and other aesthetic value sets should be left to more artistic disciplines, and engineers should focus on more meaningful targets like correctness, safety, and performance.
I don’t see it as an aesthetic. Software is hard, and the more you have of it the harder it gets. Time is limited, and best spent on things that matter the most. For me anyway, it’s very pragmatic and targetted towards exactly those things you mentioned: correctness, safety, and performance. I mean, the less code you have, the better the chance that it’s correct, safe, and performant? You just need to make sure you don’t get too carried away with this.
A reaction I often have to discussions of software minimalism online is, they’re not minimizing what I want to minimize. Not that I judge anyone for picking themselves a specific metric or bright line, it’s just rare that I read about it and say, “yeah, that’s me.”
When I think about smaller software, I’m not exactly optimizing for CPU cycles, RAM, bandwidth, lines of code, ms of response time, or strictly minimizing deps on libs/services/technologies (say, commercial cloud services or JS). I think the question I ask myself is what choices make a personal (or otherwise small) project likely to be worthwhile long-term. That means worth the effort to build, worth any bills to run it (so resource use does matter to some extent), worth the trouble to maintain (many dependencies or bad deps can bite you there), and worth using (so user-facing perf also does matter some).
A corollary to that is that different things can feel “light” to different people depending on what they’re comfortable with and their task, and I think that’s a feature not a bug. SQLite is simpler than MySQL, and Postgres has many advantages, but after dealing with MySQL most of my working life, maybe it’s what I reach for even if many shouldn’t. Or: the Rust folks are doing great stuff and I’d like to keep learning the language but today I’d have an easier time whipping something up in Go.
And likewise I don’t judge someone who is up-to-date on frontend stuff and finds it simpler to build an SPA with React hitting a JSON API instead of rendering HTML server-side, though that wouldn’t make sense for me. Or someone who knows WordPress or Drupal or something and wants to go to town with it.
Then, of course, you might ask how you can pick out what software is doing this best, or know when you’ve got your own choices right. You don’t! And that’s fine. I’m happy to read people’s writeups of their projects using wildly different approaches, with no need to rank them at the end. I might find some folks whose quirks align with mine, or might learn new stuff from someone with a different approach.
Again, I’m not trying to yuck anyone’s yum, and some flavor of minimalism is a big part of what kept my job sustainable. It’s just that it’s a local, pragmatic, balancing, vague minimalism that doesn’t really lend itself to universal principles/comparisons/definitions.
It seems like some commenters here didn’t read the article carefully and interpreted “stupid light” to be a positive description. I interpret it to be negative: as in, software that’s so “lightweight” it’s not actually useful.
I think one important bit to recognize is that switching to something “heavier” from something stupid light because you need additional features is often easier than switching to something lighter, because you might (inadvertently, or on purpose) be using all those extra features somewhere. I think that’s why people tend to complain more about bloated software than “stupid light” software. For instance, switching from a static site generator to a CMS because you need complicated overviews is easier (you can just import the existing pages and add the new functionality) than the other way around (there’s no easy way to export all that complexity out to simpler pages and sometimes you have to rethink the entire approach), so one tends to stick with the heavier solutions for longer, all the while bemoaning how bad it is.