Most of these are fine, but U is a massive mistake.<p>The Unix philosophy is fine for <i>tiny</i> systems, but absolutely terrible for building any nontrivial system, because it causes the complexity of the system to grow super-linearly with the number of features - O(n^2), in big-O notation, where n is the <i>intrinsic</i> complexity of the application (roughly, the features you want) and the big-O measures the <i>total</i> complexity of the application.<p>Why? Super quick breakdown: code has to be broken up into modules in order to prevent human brains from exploding, if the modules are too small then inter-module communication complexity dominates (because you then need a large number of modules to implement your features), if the modules are too large than intra-module implementation complexity dominates, and the Unix philosophy <i>requires</i> erring on the size of too-small modules.<p>For empirical evidence: none of the non-trivial applications you use daily (bash, firefox, chrome, windows, linux, macos, blender, krita, gcc, cargo, llvm, npm, node, vim, emacs, vscode, sublime - whatever you want) are composed of a collection of Unix utilities, or the equivalent (flat program hierarchy consisting of thousands of call sites to hundreds of tiny functions).<p>The evidence is very clear: the Unix philosophy <i>does not work</i> for anything but small systems.