Let's say you take a mega-program, break it into 100 programs.
Each now becomes more stable, due to simplicity. Yes, it really does.
But my point is, when you use those individual things, you use a random allotment of 3 or 4 of them. Not all 100.
Thus, the stringing-together bit is far, far less complex.
This is the statement I disagree with the most.
The problem is that combining different programs, that aren't strictly written to interoperate in a specific way, gives you an order of magnitude increase in the complexity. Sure, running find and grep together is common enough, but how about running {obscure_command_rarely_used} through {other_command} through {other_other_command}. There are always corner cases that can crop up, and even before we get to corner cases, just understanding how to fit the pieces together correctly is not so simple.
One cohesive program designed to all work together sometimes just makes more sense, especially when we're talking about complicated, high level actions, as opposed to the more common low-level actions of unix commands. (Or well, maybe high level and low level is the wrong way to put it - maybe the lower abstraction stuff in Word vs. the higher abstraction stuff that Unix tools deal with.)
Yes, your example of find|grep is perfect for this. Sometimes (not often) I have a situation where a simple pipe combination doesn’t work and I have to fall back to awk, which would be the single cohesive (and more complicated ) program.
And so you find that a small change somewhere like deprecating an option, fixing a typo, or adding extra data to the output makes the integration explode horribly in a confusing fashion.
There's also that plain text is a horrible serialization mechanism. Every program has to deal with parsing text that's mostly made for human consumption and deal with things like imprecise boundaries and arbitrary limitations per tool and per system.
Eg, /etc/passwd is a nice simple format, until you consider that somebody might want to use a ":" in a field, or to add more fields, or to store multiple lines of data. And all those quirks are specific for that particular file and may be handled subtly differently by other parts of the system.
And internationalization is an extra bit of fun, which ensures random bizarre bugs that use ',' instead of '.' as the decimal separator, or just emit text in some language that isn't English.
You're right, systemd does fail in this.
And the umbrella just seems arbitrary - GNU, Mozilla, X11, anything that's a package group, etc. are also failing.
Integration and ease of use are features in themselves.
The best of both worlds would be building things that is modular from the developers perspective but integrated from the perspective of the user. Few will pull that off though, and when they do the modular systems become complex and expensive bespoke setups (Typical of e.g SAP, Oracle).
I disagree, I think the Unix philosiphy solves the problem. You build simple tools that do one thing, and do that one thing well, but you make it easy for the tools to work together and then you can have pieces that do one simple thing while still serving needs.
When new needs come up that aren't addressed by current tools you simply put together another simple tool that does that.