This is an interesting point, but I raise you <i>search</i> and <i>types</i>. One of the points where &quot;the Unix philosophy&quot; (as usually espoused at least) is sorely lacking is that all programs interact with what is popularly called &quot;text&quot; (or a &quot;single type&quot;&#x2F;&quot;unitype&quot;).<p>For practical reasons it isn&#x27;t always text, but more importantly (the first bit is a subset of this problem): almost every program has to understand (100%) the output of <i>every</i> other program it has to interact with.<p>If output were <i>typed</i> our applications could <i>ignore</i> (reliably) the bits they don&#x27;t care about.<p>If output were <i>typed</i> we could <i>search by output-type</i> (e.g. diff produces patch-like-output, so don&#x27;t bother piping to &quot;xargs&quot;, but allow &quot;less&quot; (any type of input) or &quot;git apply&quot; (patch-like-input) or &quot;patch&quot; (patch-like-input).<p>Types could add a <i>huge</i> amount of searchability to CLIs -- and for some reason this isn&#x27;t appreciated even though we&#x27;ve seen it in a much more limited context such as OOP.<p>(I think my original inspiration for this line of thinking is Paul Chiusano, and he probably deserves most of the credit, honestly.)<p>EDIT: Actually, pondering this a little more: All programs should be forced somehow(!) to carry a &quot;source location&quot; for the source of their output. This is such an annoyance in the daily life of a programmer if you perform a chain of commands like &quot;git diff ... | grep FIXME | grep ^+ | ...&quot; just to get a grip on the FIXMEs <i>you&#x27;ve</i> introduced. The output doesn&#x27;t show line numbers, because... well, for no <i>really</i> good reason, really. It&#x27;s just that transformation as text meant that we sort of lost that bit.