- software should do one thing and do it well
- code should be understandable, easy to build, easy to port
- dependencies should not be a problem
- the chosen language must not be a burden
- resources are scarce: if you say "unused memory is wasted memory" you are part of the problem
Are you quoting suckless.org? Or paraphrasing? In a skim, I see some philosophy stuff there but not exactly this.
I think those are platitudes: they sound good but aren't specific enough that anyone disagrees with them, so they're not saying anything. Imagine:
> - software should do one thing and do it well
No one ever says "let's do a bit of everything, badly".
And there's tons of wiggle room in "one thing". Imagine a few, very different huge codebases. Let's say Linux, Photoshop, Rust. I think their proponents would say they're each focused on one thing (kernely-stuff, photo editing, foundational software). Their detractors would disagree: use a microkernel instead, separate out the filters or something, people are using it for scripting. Who's right?
> - code should be understandable, easy to build, easy to port
> - dependencies should not be a problem
> - the chosen language must not be a burden
Again, no one ever says differently, even if the result they end up with is none of these things.
> - resources are scarce: if you say "unused memory is wasted memory" you are part of the problem
I think this is the most interesting one, because it's contrasted with something I have actually heard people say (maybe even said myself on occasion). But still, I generally haven't heard people say it for no reason. There's some other attribute they're getting for that RAM, whether it's a compute-vs-RAM trade-off or the ability to use a (believed-to-be) simpler programming language or some such. This one might be more interesting if prioritized relative to "code should be understandable".
About doing one thing and doing it well, the best (anti) example is systemd. I think that having a DNS resolver and mounting your partitions should be two totally separated things. Fortunately nobody uses syste... Oh, wait!
About the code should be understandable and the efficiency, I'm thinking of the old times java. I've seen people in systems department having to profile java stuff because they were OOMing their tomcats. Eventually we had to ask for the code, debug it and send it patched with just some '=null' because the GC wasn't doing its job in the best way. In the early 2000 the philosophy already was "Good hardware is cheaper than expert developers" :(
> About doing one thing and doing it well, the best (anti) example is systemd. I think that having a DNS resolver and mounting your partitions should be two totally separated things. Fortunately nobody uses syste... Oh, wait!
People have asked the systemd folks about this, and their answer is that these are separate things because systemd-resolver is a distinct, optional binary that does one thing well. Is that enough to say they're totally separate things? Opinions obviously differ!
It is really hard to come up with rules of taste that are generally applicable yet specific enough to that people interpret them in the same way to make the same decisions. I don't really have any such rules of my own to offer. I've written coding standards for multiple projects but I definitely can't copy'n'paste one to another and have it still make sense.
> About the code should be understandable and the efficiency, I'm thinking of the old times java. I've seen people in systems department having to profile java stuff because they were OOMing their tomcats. Eventually we had to ask for the code, debug it and send it patched with just some '=null' because the GC wasn't doing its job in the best way. In the early 2000 the philosophy already was "Good hardware is cheaper than expert developers" :(
Yeah, there are plenty of examples of poorly written applications around. [1] But I don't think someone said "let's write this code really badly and just buy bigger machines". Could be wrong, just never heard anyone say that. On the other hand, I do almost universally see people prioritize the next "critical" feature over clearing the bug tracker. So if you said for example "fixing customer-reported memory leaks always takes priority over new features" that'd be making a real, controversial taste choice.
[1] ...and my guess is this was a poorly written application—keeping around reachable references too long, thus forbidding GC from cleaning them up, rather than a flawed Java GC algorithm that didn't detect the parent was also unreachable in a timely way.
It's not wrong per-se, but they practice it to a level of extreme that it seems more like a principled art piece than usable software. Software engineering is all about knowing your project-specific constraints, it should not be wasteful - and that goes for runtime performance / memory usage as much as the time invested. Usability is another factor - suckless software is very inaccessible to people who don't know how to use a compiler by default.
> (I know, I'm a horrible person)
You made a throwaway just for that? I'd hope most people are capable of differentiating the engineering ideology from the (ironic?) nazi reference and tiki torch march ideology bit.
Holy sh... I didn't expect that Godwin's law would apply that quickly.
IMHO, I'm also part of the problem and I think I am a horrible person, but at least I don't consider myself superior to anyone in any way no matter their race, gender, software philosophy or their political views as far as they don't fall in the tolerance paradox.
It's pretty well documented that they called their mailserver "Wolfsschanze" (which was one of Hitler's military bunkers). Whether or not that's just edgy behavior or not, I don't know, but my guess it's a bit of both considering suckless people have complained about "cultural marxism", which is a term with pretty straight lineage to the Nazi's "cultural bolshevism".
So... is that not a nazi reference? Why else would you preempt being "horrible".
By the way, just wanted to be sure about this: Tiki Torch parades have been documented since the XI century on the Pyrenees, I just wanted to be sure how old was the tradition. That's the first place that came to my mind and the place where I myself have gone down a hill with some other hundreds of people carrying a torch... When we finished, in the town in the valley, there was a reggae concert and most of the guys down the hill went there, no problems at all.
Actually my country had a fascist dictatorship until the end of the 70s. I'm old enough to have been hit by nazis in the early 90s. I have seen fascists in a parade and policemen doing nothing.
IMHO, software philosophy does not have anything to do with some developer philosophy. IMHO again, that is like comparing journaling filesystems and B+ trees as apology of gender-based violence because ReiserFS was one of the first mainstream filesystems that implemented it.
- software should do one thing and do it well - code should be understandable, easy to build, easy to port - dependencies should not be a problem - the chosen language must not be a burden - resources are scarce: if you say "unused memory is wasted memory" you are part of the problem
(I know, I'm a horrible person)