“UNIX descendants follow the pattern of encoding data types with filename endings.”
An ad-hoc arrangement with little formal support at the GUI level and none at all at the shell level.
`some_program --out_type=json | jq` to `some_program | jq`.
JSON only tells you how the data is encoded, not what it means. Contrast this MIME type:
application/atom+json
Knowing data is JSON-encoded only enables (unsafe) generic JSON operations. Knowing the data is, say, ATOM allows task-specific operations. Consider a search tool. Having precise type information enables format-specific parsing operations to be decoupled from generalized tree/table searching operations.
Not only that, but looking up parsers and inserting them into the pipeline can be completely automated away. `some_program` doesn’t need to be told to output JSON; it can negotiate that itself with the program that follows, the shell acting as broker. (Content negotiation is one of the Great Ideas of HTTP; sadly utterly ballsed by the WWW, but that doesn’t mean others couldn’t do it right.)
Or consider `ls`. How many options/arguments does that have? (If you don’t know off the top of your head, I totally understand and am happy to wait.) Now, how many out of those options relate to recursion, filtering, and presentation? Because none of those should be built-ins; they should all be separate, general, composable tools. How much duplication of effort would be eliminated across the entire Unix command line? How much easier would it be to learn the entire system?
This is Unix Philosophy 101, yet even a simple standard tool like `ls` utterly fails it. Why? Because for effective, efficient, safe composition to be the easiest route, it needs to Just Work. Which it can’t do, because lack of IO typing and tagging means that What You See Is All You Can Get. Consider: for some consumers it’d make more sense for `ls` to output a list of inodes; for others, a list of full paths; for others, URLs. Outputting a list of file names is crap (assumes shared global state—cwd—that will not change between time of creation and time of use). Outputting a list of file names arranged in multiple vertical visual “columns” each offset by N spaces is insane. This is the very definition of Big Ball Of Mud.
Like I’ve said, there is no point trying to “fix” Unix because fundamentally it does not want to be fixed; never mind whether or not fixing it is even technically feasible. But that’s fine: there’s value in stability and it is a sunk cost so nothing is lost. Just leave Old Unix to be itself, which is what it’s good at, and build a new system unencumbered by legacy baggage and baked-in mistakes, making full use of all the wisdom and resources gained over the decades since.
Okay, so a brand new system will have to be radically better than the old in order to attract audience, but that’s totally doable. Heck, there were already way better CLIs forty years ago (VMS, Plan9, Symbolics Lisp, Smalltalk), so it’s not like there isn’t a wealth of knowledge and experience to purloin for free. It’s just a question of motive: who now benefits from propping up all the old complexity and makework vs who’ll benefit by completely disrupting it. And you just have to look at how an aggressive reborn Apple handed the mighty untouchable Microsoft its own ass back in the 2000s to work out the answer to that. Or Kodak. Or Xerox. Or the US car industry. Or the British Empire. And so on.
Incidentally, your jq example is a perfect illustration of Zawinski’s Law† in action:
“jq 1.5 released, including new datetime, math, and regexp functions, try/catch syntax, array and object destructuring, a streaming parser, and a module system”
These big bloated behavioral silos that keep popping up on Unix are neither good nor accidental: they’re the symptom of a fundamental fault in the underlying host. Because when the most complex concept it is capable of communicating on clients’ behalf is “Ugg bang rock!”, it should come as no surprise when its clients all go “fuckit, I’ll just do it all myself”. And so it goes.
An ad-hoc arrangement with little formal support at the GUI level and none at all at the shell level.
`some_program --out_type=json | jq` to `some_program | jq`.
JSON only tells you how the data is encoded, not what it means. Contrast this MIME type:
application/atom+json
Knowing data is JSON-encoded only enables (unsafe) generic JSON operations. Knowing the data is, say, ATOM allows task-specific operations. Consider a search tool. Having precise type information enables format-specific parsing operations to be decoupled from generalized tree/table searching operations.
Not only that, but looking up parsers and inserting them into the pipeline can be completely automated away. `some_program` doesn’t need to be told to output JSON; it can negotiate that itself with the program that follows, the shell acting as broker. (Content negotiation is one of the Great Ideas of HTTP; sadly utterly ballsed by the WWW, but that doesn’t mean others couldn’t do it right.)
Or consider `ls`. How many options/arguments does that have? (If you don’t know off the top of your head, I totally understand and am happy to wait.) Now, how many out of those options relate to recursion, filtering, and presentation? Because none of those should be built-ins; they should all be separate, general, composable tools. How much duplication of effort would be eliminated across the entire Unix command line? How much easier would it be to learn the entire system?
This is Unix Philosophy 101, yet even a simple standard tool like `ls` utterly fails it. Why? Because for effective, efficient, safe composition to be the easiest route, it needs to Just Work. Which it can’t do, because lack of IO typing and tagging means that What You See Is All You Can Get. Consider: for some consumers it’d make more sense for `ls` to output a list of inodes; for others, a list of full paths; for others, URLs. Outputting a list of file names is crap (assumes shared global state—cwd—that will not change between time of creation and time of use). Outputting a list of file names arranged in multiple vertical visual “columns” each offset by N spaces is insane. This is the very definition of Big Ball Of Mud.
Like I’ve said, there is no point trying to “fix” Unix because fundamentally it does not want to be fixed; never mind whether or not fixing it is even technically feasible. But that’s fine: there’s value in stability and it is a sunk cost so nothing is lost. Just leave Old Unix to be itself, which is what it’s good at, and build a new system unencumbered by legacy baggage and baked-in mistakes, making full use of all the wisdom and resources gained over the decades since.
Okay, so a brand new system will have to be radically better than the old in order to attract audience, but that’s totally doable. Heck, there were already way better CLIs forty years ago (VMS, Plan9, Symbolics Lisp, Smalltalk), so it’s not like there isn’t a wealth of knowledge and experience to purloin for free. It’s just a question of motive: who now benefits from propping up all the old complexity and makework vs who’ll benefit by completely disrupting it. And you just have to look at how an aggressive reborn Apple handed the mighty untouchable Microsoft its own ass back in the 2000s to work out the answer to that. Or Kodak. Or Xerox. Or the US car industry. Or the British Empire. And so on.
Qui audet adipiscitur. She who dares, wins.