[zzo38computer]

Structured output would be helpful in many ways, but JSON is not a good format for this (neither is YAML nor XML nor HTML).

> JSON's not perfect but (non-minified) it's human-readable enough to address the basic issues here without jumping all the way towards binary or (shudder) HTML

It does not address most of the real issues. Programs that deal with pictures, sounds, non-Unicode text, structures of the kinds that JSON does not have, etc, will not do as well; and the input/output will involve converting escaping. (One format that I think is better is DER, although, it is binary format. I did write a program to convert JSON to DER, though.)

[robot-wrangler]

For raw data type of applications, it's definitely important to be able to preserve pipeline oriented use-cases like `cat img.png | convert-stdin-to-jpg | convert-stdin-back-to-png | imgcat`. But in the hypothetical world where all CLI I/O moves towards JSON, I'd still argue this is not only possible but now strictly easier because you can just explicitly embed mimetype info + b64 instead of assuming/detecting encoding or requiring user to specify it, or working with heuristic file-magic. (Jupyter notebooks work like this to persist images instead of just flat text.) And presumably a smarter suite of JSON oriented tools like jcat/jless would either actually display that data, or notice the type and avoid spamming the screen with raw b64.

[zzo38computer]

That can be helpful, although JSON is still a bad format for this, especially since now it requires base64 encoding. People think JSON is a good format but it isn't. (MIME is also not a very good format for identifying file formats, since you can only specify one format; although there is a "added on" specification like "+zip" and "+der" this isn't very good.)