Hacker News Reader

Comment by nickcw | Hacker News Reader

I feel like this ship has sailed. SQL has been around for more than 50 years and everyone who needs to generate it has already put that extra `if` statement in to suppress trailing commas.

What annoys me far more often is the lack of support for trailing commas in JSON.

View on HN

> lack of support for trailing commas in JSON

This, 100%! And the lack of comments.

JSON5 allows comments, it's been around since 2012. That said, JSON is not meant for humans / manual editing, and deciding to use it for configuration files was a mistake.

How am I supposed to make changes to this configuration file?

even if it wasn't meant for humans and manual editing, it works reasonably well for these usecases

I'd say it even works better than many common configuration filetypes such as YAML or INI.

Thinking that a new, least sucking data format won’t be used for configuration was a bigger mistake. Like, yeah, I will exchange all my data in JSON now, but store configs in a good old XMLNS XSLT DTMF?

Store configs in the program if you can. Store in INI, TOML, or something similarly simple for humans if you must. Never use anything that requires matching syntax as the default (closing tags and matched brackets being the two main ones).

JSON is already strictly worse than XML though as it doesn’t support comments and multi-line strings in a sane way.

Thanks, but I tend to ignore this. Every time you, as a direct end-user, provide feedback on format or software, someone appears with a whole philosophy around why you shouldn't be like that and what you should do instead. And sometimes there's no "why" part even.

But I really don't need philosophy. I know what I want, and I want json with $subj, //comments and optional key quoting. Feels like some people just love making inconvenient things standard and/or teaching others how to live. (I mean the idea "json is not for X" here, not your comment)

Funny I’m the exact opposite: I essentially never write JSON by hand, or add json content to repositories, so could not care less about the lack of trailing commas, I do semi routinely write or review SQL.

I agree. And JSON basically isn't meant to be hand-written, just easy to glance over, if you need to or do basic tests with. It's a serialization format. It's not a config format or anything like that. The idea of wanting to use it for that (when the config needs to be hand-written) should be a red flag for anyone. Why would you want to hand-write something where a key is denoted with double quotes?

And just to be clear: YAML is also not a config format and wasn't meant to be. YAML is for metadata style stuff that is supposed to be close to humans, heck the whole yes/no and "not so strict" typing parts.

If you want a config format you got many options: There is toml/ini and friends on one side and UCL/HCL/... on the other. Or if you want to go really simple, do something like Postgres, Tor, etc. do and just use space separated strings.

I've been bitten by trailing commas in my python+sql code repeatedly, it's an easy mistake to make when python itself has trailing commas (which I make deliberate use of).

I feel the same way about SQL too, it's set and difficult to shift. But I also look at PRQL longingly - https://prql-lang.org/

Have you seen the Google BQ pipe syntax? https://cloud.google.com/bigquery/docs/reference/standard-sq...

Feels like it does 75% of what PRQL does while still staying somewhat backwards compatible. Already works in BQ if you opt in.

Douglas Crockford made a commitment that JSON would never, ever get better. He promised us that it would always suck. He is as good as his word.

It has the small benefit that you never, ever have to worry about running into an old version of a JSON parser that bounces your fancy trailing commas.

Worth it? Not to me but Douglas Crockford does not care what I think. Or you either, apparently.

What extra "if"?

  ', '.join(fields)

;)

The closing tags should be optional too.

[{},{},,,,{},,

Should be fine. Now you can push things to the eof.

You probably want jsonlines. Being able to open a file in append mode without needing to parse the whole thing is great.

https://jsonlines.org/

I get why one wants strict parsing rules but i don't see the point of closing tags. It seems nice enough to have [say] logs in json. Why would one need to add closing tags before consuming the json elsewhere? Parsing the entire thing is a huge waste of time if it is large.

I can use csv or html ofc.

Reply on news.ycombinator.com