3 ms·
> problems which are not problems (readability of serialized representation) I don't know that I fully agree. A format that is both human- and machine-readable
by williamdclt 2y ago
> problems which are not problems (readability of serialized representation)
I don't know that I fully agree. A format that is both human- and machine-readable is very useful, for configuration and debuggability for example. It's indeed more expensive in compute and storage, but that's additional work _for machines_ rather than _for humans_ (having to compile/encode/decode data at the human/machine interface).
Certainly doesn't mean it's always the right trade-off, but it's an appealing one, as the popularity of these formats shows, in particular JSON which isn't even that good for human-readability (eg no comments in standard JSON).
- vacuity 2y agoBut that's the thing: if we want to optimize both machine and human experience, we should create a 1:1 dual format, one which is machine-readable and one which is human-readable. A standard tool easily converts one to the other. This should not still be a problem. Yes, we have computers and should offload work onto them. But exactly what that work is is still important. Two approaches aren't equal because they both put the burden on the machine.
- addaon 2y ago> But that's the thing: if we want to optimize both machine and human experience, we should create a 1:1 dual format, one which is machine-readable and one which is human-readable. A standard tool easily converts one to the other. So… plists and plutil?