Two views on software #minimalism that are (somewhat) in tension:

1) The Unix philosophy that every program should do one job and do it well.

2) The idea that a minimalist program should not require a complex web of external dependencies.

Neglecting either side can lead to overly complex software, at least in my view.

CC: @sir, since you always have interesting thoughts on minimalism.

@codesections in Unix sed does not *depend* on grep, but the user can choose to compose them freely to solve each individual problem. Minimal general-purpose solutions are composed on the fly to solve complex domain-specific problems


That's fair enough—and I was thinking of cases like that when I said that they're _sometimes_ in tension. But take something like Mutt—it chooses not to implement a number of useful features and, as a result, frequently ends up embedded in a complex web of runtime dependencies. (See image; source:

@codesections this is still the composition of discrete parts, each speaking an API that the others understand and which can be easily manipulated by the user. There are many other possible mutt configurations, and making novel configurations is trivial


That's true. But it also means that one task ("reading email") is reliant on several independently developed pieces of software all continuing to work, and to work together. And, since they're developed independently, they may not be tested together and could potentially have bugs in their interoperability (to say nothing of breaking API changes).

And, since the overall system is more complex, debugging can be more difficult. ("I didn't get an email—what program is to blame?")


But it isn't reading email isn't "one task," it's many - there's fetching the text from servers and getting it in a useful form locally, there's rendering the text on a screen, and manipulating it.

These are are three different tasks - that "doing a read of email" requires them doesn't make it one task anymore than "baking bread" is one task when you've got to turn on the oven, mix the dough, prepare the bakeware.

That is, it's one task, if that's your paradigm. But only if.

@codesections The fact you almost always do one then the other then the last doesn't really change that each task is self-contained and can be done for a completely different purpose with other inputs.

That there are standard stacks of tools for tasks doesn't make one task, any more than 'putting on my shoes" is the same task as "getting the mail," - yeah i can pipe them together as a macro, but that doesn't make them one.


To stick with your bread example, say there's a certain recipe for bread that, from one perspective, is very simple: flower, water, salt, yeast. But, it also depends on having a working oven, a rolling pin, a flat surface, some sort of mixer, etc. And that's one component to the meal; the meal as a whole might have even more "external dependencies".

In contrast, microwave dinner has *one* external dependency: just the microwave.

I can see a fair argument for either being "simpler".


Both are equally complex as long as you accept the level of abstraction presented in their respective documentation. If you try and use your own abstractions, yes, you'll of course make it more complex, because adding layers of translations to anything makes it complex.

Literally both are simple or complex depending on how you squint - but as you say, neither way of squinting is "right".

@codesections I hope this doesn't seem like a non-answer, because it's really meant to be my honest thoughts on it. Like, Windows is the "simplest" if you truly embrace their assumptions about operating a computer.

So I guess what I'm saying is you can do work to find the OS that closest matches your personal abstractions, or work to match your personal abstractions to your OS, but skipping that work and going to looking at programs within the OS, and you're just gonna be dissatisified.


Hmm, I'm a bit concerned that I've been inarticulate. There is a concept of "simple" that means something like "easy to use", but that's *not* the meaning I have in mind.

I'm talking about something more like "few moving parts/reliable/easy to maintain". And, even at that level, the microwave dinner might be "simple". Or maybe a better example is the dried food I use when backpacking—all it needs is the pouch, water, a pan, and a heat source—very few moving parts, and very simple.


Helpful but I stand by it - Windows has very few moving parts if you accept their abstraction (because all the moving parts are behind the scenes/in their factory, like the microwave dinner)

If you're internalizing externalities - looking at the whooole ecosystem of abstractions and work involved in getting to the bread/meal...

...I'd have to say Unix is by far the most simple, because of it's rather strict "one tool one job" means you can make bread, microwave dinner, or dehydrated food, just by shuffling things around the kitchen, rather than buying new equipment

Yeah, agreed.

But, ok, take a Silicon Valley startup: they rely on Stripe to process payments, React to build their site, Redux for state management, Webpack to bundle their code, Zendesk to talk to customers, Slack to talk to themselves, Trello to manage tasks…

You *could* say that it's Unix-philosophy simple—separate tools for separate jobs. But you could *also* say it's an over-designed tangle of interdependent systems that could break at any time.

@sir this is what I meant before

@codesections Would the difference simply be that Unix is simple the same way the whole way down, while your example, the type of 'simple' changes as you descend layers of abstraction (first unixy, but on the inside, each of those tools if very un-Unixy)

Alternatively, is that it isn't actually Unix-simple, because while the tools are purpose-built, the problem they "simply solve" wasn't specified with the same rigidity Unix would've?




...My last point there has me wondering if a crucial part of Unix philosophy isn't simple tools /built for well-specified problems/ - with the specification of the problem being an often-skipped step of things, leading to Unix-y solutions for problems that... aren't Unix-y in spirit at all, so the Unixy solutions... suck?


Sign in to participate in the conversation
Ten Forward

Welcome to Ten Forward, a Star Trek themed Mastodon instance! For more information on what Ten Forward is in the Star Trek universe, please read this page on Memory-Alpha. The instance is not restricted to Star Trek role-play or characters. More general purpose use is welcome.