> Why does the successor to the terminal need to be text oriented at all?
Terminals are not "text oriented". They are based on a bidirectional stream of tokens - that can be interpreted as text, or anything else.
That simplicity allows for Unix-style composition. If you make the output something different, then the receiving program will need to be able to parse it. The Amiga OS had some interesting ideas with different data types as system extensions - you'd receive "an image" instead of a JPEG file and you could ask the system to parse it for you. In any case, that's still forcing the receiving program to know what it's receiving.
One way to add some level of complexity is to add JSON output to programs. Then you can push them trough `jq` instead of `grep`, `sed`, or `awk`. Or push it through another tool to make a nice table.
> it’s all legacy invented for a world that is no longer relevant.
I hear that since the Lisa was introduced. Character streams are a pretty common thing today. They are also very useful thanks to their simplicity. Much like Unix, it's an example of the "worse is better" principle. It's simpler, dumber, and, because of that, its uses have evolved over decades with almost no change to the underlying plumbing required - the same tools that worked over serial lines, then multiplexed X.25 channels, then telnet, now work under SSH streams. Apps on both sides only need to know about the token stream.
> One way to add some level of complexity is to add JSON output to programs. Then you can push them trough `jq` instead of `grep`, `sed`, or `awk`. Or push it through another tool to make a nice table.
That's still text. Even PowerShell passes objects between commands.
Plan9 did this correctly. A terminal was just a window which could run graphical applications or textual applications. Locally or remotely. It all worked. You create a window, you get a shell with a text prompt. You can do text stuff all day long. But maybe you want that window to be a file manager, now? Launch vdir, and now that same window is home to a graphical file browser. close that and remote into another plan9 machine. launch doom. it runs. it all just works, and it all works smoothly.
And the entire source code for that OS could fit into one person's brain.
It is a very simple OS, appears (to my layman eye) to have sandboxing between all applications by default (via per-process namespaces) making it very easy to keep one application off of your network while allowing others to talk via network as much as they want, for example.
Terminals are not "text oriented". They are based on a bidirectional stream of tokens - that can be interpreted as text, or anything else.
That simplicity allows for Unix-style composition. If you make the output something different, then the receiving program will need to be able to parse it. The Amiga OS had some interesting ideas with different data types as system extensions - you'd receive "an image" instead of a JPEG file and you could ask the system to parse it for you. In any case, that's still forcing the receiving program to know what it's receiving.
One way to add some level of complexity is to add JSON output to programs. Then you can push them trough `jq` instead of `grep`, `sed`, or `awk`. Or push it through another tool to make a nice table.
> it’s all legacy invented for a world that is no longer relevant.
I hear that since the Lisa was introduced. Character streams are a pretty common thing today. They are also very useful thanks to their simplicity. Much like Unix, it's an example of the "worse is better" principle. It's simpler, dumber, and, because of that, its uses have evolved over decades with almost no change to the underlying plumbing required - the same tools that worked over serial lines, then multiplexed X.25 channels, then telnet, now work under SSH streams. Apps on both sides only need to know about the token stream.