> So the idea that there is a "maximum" number of things a product should do, that can be known in advance, is sheer rubbish
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.
That's also how Word solved the problem with the toolbars. It hid the functionality using the ribbon and added plugins. Unix is a monster in terms of features if you look at it as a whole. It's just modular so it can solve all problems.
I don't think this adequately addresses the counterexample of the Word toolbars. Sure, there's Excel, but what if I want the tabular data to live in my Word document? Now the Microsoft engineers are building a whole secondary table editing system into a word processor...
If everything is modular, you can copy any feature between the various parts of your office applications. You've got a plugin doing one thing, and a host whose one thing is bundling all of those one things together.
The unix philsophy might make sense for command line apps — though even there if you look at any manpage you find that they usually do more then one thing, including things you could easily do by piping the output to another command — but what does it mean in the context of a word processor? You want another app to count the number of words in a document, for example?
> 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.)
> One cohesive program designed to all work together sometimes just makes more sense
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.
This trivially becomes very fragile. Each of those 100 programs now doesn't just do stuff, but is held to a contract. A contract that it's well possible nobody intended to provide, but yet organically happened anyway.
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.
Figuring out which of the 100 I use and how to get them to work together is much more complicated than finding the feature in an omnibus program that already does exactly what I want.
Customers don’t want to glue things together they want whatever solves their problem efficiently.
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).
Does it? If you mean 'all things under the systemd umbrella' then sure, but if you think in terms of systemd (core), systemd-networkd, systemd-homed, etc. isn't it pretty much as 'one thing'(s) as it could reasonably be?
And the umbrella just seems arbitrary - GNU, Mozilla, X11, anything that's a package group, etc. are also failing.
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.