Following what you say we should only have binary format.
I think you underestimate the convenience of a text format.
It does not only provide a simple way to generate it, but also provide a way to modify it by hand.
I think you underestimate the convenience of a text format.
It does not only provide a simple way to generate it, but also provide a way to modify it by hand.
One of the biggest issues with the most popular 'tool-only language' (Excel) is that there is no reasonable way to audit changes. Same goes for UIs that are backed by inscrutable file formats.
Readability and understandability depend on more strict requirements that a text file format may or may not have. Many do, but far from all do.
For instance, JSON files do not have requirements on the ordering of keys. When making a small change to a JSON file, it is entirely legal to reorder every single key, completely destroying the diff, and an automatic tool may very well do this.
And as a counter-example, we could easily use a binary representation of JSON data, but use a diffing tool that normalises key ordering to provide diffs that are more readable and understandable than a text diff of a JSON file, even without malicious reordering of lines.
Of course semantic diffs would be nice; even, or especially, for code for example but while they do exist they haven't seen much uptake because they do not integrate well with existing tooling.
Only if you ignore the bit where I said "once you hit a moderate level of complexity". Text file formats work really well for simple things.