> This could have been a simple JSON string.

There's nothing "simple" about parsing JSON as a serialization format.

Having attempted writing a JSON parser from scratch and a protobuf parser from scratch and only completing one of them, I disagree.

▲

wvenable 6 days ago | parent | prev [-]

Except that most often you can just look at it and figure it out.

▲

tgma 6 days ago | parent | next [-]

Sure you can look at it[1], but you're not expected to look at Apple Photos database. The computer is.

Write a correct JSON parser, compare with protobuf on various metrics, and then we can talk.

[1]: although to be fair, I am older than kids whose first programming language was JavaScript, so I do not think of JSON object format with property names in quotes and integers that need to be wrapped as strings to be safe, etc., lack of comma after the last entry--to be fair this last one is a problem in writing, not reading JSON--as the most natural thing

▲

wvenable 6 days ago | parent [-]

I'm also "older" but I don't think that means anything.

> Sure you can look at it[1], but you're not expected to look at Apple Photos database.

How else are you supposed to figure it out? If you're older then you know that you can't rely on the existence or correctness of documentation. Being able to look at JSON and understand it as a human on the wire is huge advantage. JSON being pretty simple in structure is as advantage. I don't see a problem with quoting property names! As for large integers and datetimes, yes that could be much better designed. But that's true of every protocol and file format that has any success.

JSON parsers and writers are common and plentiful and are far less crazy than any complete XML parser/writer library.

	▲	tgma 6 days ago \| parent [-]
		> Being able to look at JSON and understand it as a human on the wire is huge advantage I don’t think this is a given at all. Depends on the context. I think it’s often overvalued. A lot of times the performance matters more. If human readability was the only thing that mattered, I would still not count JSON as the winner. You will have to pipe it to jq, realistically. You’d do the same for any other serialization format too. Inside Google where proto is prevalent, that is just as easy if not more convenient. The point is how hard or easy it is for an app’s end user to decipher its file database is not a design goal for the serialization library chosen by Apple Photos developers here. The constraints and requirements are all on different axis.

▲

IshKebab 6 days ago | parent | prev [-]

Sure but unless you want to embed an LLM in every JSON library, computers can't do that.