> “ suboptimal" from the global perspective, because to me a simple solution should be a local optimum for a specific problem.
Except if that requires a company to create and support dozens of “optimal” versions of the same functionality for similar, but different performance impacting, circumstances.
That is not globally simple for the producer, or for customers trying to figure out what version they need. Or having to manage multiple versions for different uses.
> For instance, one could argue that the Unix motto "do one thing well" generate lots of specialized programs
The clear design philosophy of Unix file and stream tools, and there interoperability, does enable much simpler command construction.
But as a maker of tools, you can only leverage interoperability standards if they exist. For many software objects, and ways of combining them, standardized conventions are less well defined, less reliable, or non-existent.
Thus ubiquitous glue code - navigating complex mismatches in information and conventions between components.
Also note, that Unix scripting didn’t eliminate C apps! The cost of Unix tool simplicity, is a massive loss of performance for many use cases. So similar functionality gets recreated over and over again, in virtually every C (or other language) app, to optimize for slightly different contexts.
With work and standards, simplicity “islands” are achieved. But they form an archipelago - not a continent. Need to go in an unsupported direction and you have to swim a mile, instead of walk one.
Except if that requires a company to create and support dozens of “optimal” versions of the same functionality for similar, but different performance impacting, circumstances.
That is not globally simple for the producer, or for customers trying to figure out what version they need. Or having to manage multiple versions for different uses.
> For instance, one could argue that the Unix motto "do one thing well" generate lots of specialized programs
The clear design philosophy of Unix file and stream tools, and there interoperability, does enable much simpler command construction.
But as a maker of tools, you can only leverage interoperability standards if they exist. For many software objects, and ways of combining them, standardized conventions are less well defined, less reliable, or non-existent.
Thus ubiquitous glue code - navigating complex mismatches in information and conventions between components.
Also note, that Unix scripting didn’t eliminate C apps! The cost of Unix tool simplicity, is a massive loss of performance for many use cases. So similar functionality gets recreated over and over again, in virtually every C (or other language) app, to optimize for slightly different contexts.
With work and standards, simplicity “islands” are achieved. But they form an archipelago - not a continent. Need to go in an unsupported direction and you have to swim a mile, instead of walk one.