JSONL/JSON Lines seems like a good replacement for CSV-type data, so I'm trying very hard to not have a kneejerk negative reaction to it

it continues the CSV & JSON heritage of being a format "so simple" that people will write their own parsers/formatters for it, so we're going to be dealing with interoperability issues for the next millennium I'm sure

I'm not 100% sure why it's not just a json subset. It's basically just an array of json dicts, and would be parsable as such, but I guess it works a little better for things like logs where you want append-only writing. A JSONL file can be extended by just adding a new line, while a JSON file would require a either being tricky or reparsing the whole file and re-serializing it

@foone Can't be a subset as there are both JSON documents that are not valid JSONL (anything with a newline in it), and JSONL documents that are not valid JSON (anything with two or more sequential newline-separated JSON frames).

JSONL's original use case was structured logging, which is a stream-like application. Each frame is one log entry.

most of my kneejerk dislike is that the second hit for JSONL on google calls it "The data structure to train and interact with LLMs"

but the format itself is fine, other than at least one of the implementations of it being vibecoded

@foone I dunno if you've ever read an XMPP parser but trying to do streaming of successive elements of a JSON array would hit a lot of the same problems, due to having to ensure that the containing array syntax remains valid while allowing clients to act on elements as they arrive.

@foone I don't know why in twelve fucks someone would use an LLM to write a JSONL parser though

@andy @foone @owen
Huh, TIL. Although that one allows newlines within the JSON objects. For unreliable output it may mean you get a partial record at the end.