Two views on software 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.



Yeah, absolutely. It depends on what level of abstraction you're working at—you can almost always zoom in to a particular task and break it down into independent tasks at a lower level of abstraction.

I guess a different way of putting my thought is that operating at too high *or* too low a level of abstraction could lead to complex software.

Sign in to participate in the conversation

Fosstodon is an English speaking Mastodon instance that is open to anyone who is interested in technology; particularly free & open source software.