Why not both?

Protocol Buffer?

In protocol buffers, you don't have commas. Also comments go where they belong, in the schema ...

It may be used as such but it shouldn't be. YAML serves this purpose much better.

JSON works better as a language independent serialization format that is incidentally readable.

Lua tables are better than both, in my opinion. Simpler than JSON, allows for comments, and whitespace is not syntactically significant.

Yeah json is a fact of life, the fact yaml exists doesn't change that. Actually, toml is even better than yaml and yet...

TOML's array/table syntax is kind of confusing, especially when you're a few levels deep. Having meaningful whitespace in YAML makes it clearer.

It's also kind of messy when you have a lot of multiline strings.

Meaningful whitespace is horrid. I speak from 3.5 years of working on s project that exclusively used yaml as configuration. Yaml is horrid.

Toml is way better. Yes, multilayered objects in toml are ugly. Don't make your users created multilayered objects for their configuration. That's just a bad UX regardless of the language.

> Meaningful whitespace is horrid

Millions of Python programmers might disagree, not to mention that most programmers using languages with meaningless whitespace (as far as the computer is concerned) still put whitespace in there, because humans.

And it isn't like INI is a great experience, either. Flat configs suck in their own ways.

It's weird that a language with the mantra "explicit is better than implicit" has, as a core feature, braces implied by the negative space of the left-hand margin of a text editor.

>And it isn't like INI is a great experience, either. Flat configs suck in their own ways.

Yes, INI isn't great, but people who object to significant whitespace don't object to the "whitespace" part, they object to the "significant" part. That code could not compile or have scope errors because of one extra space or because a space replaced a tab just seems absurd to some people.

This is something about which reasonable people can disagree.

> It's weird that a language with the mantra "explicit is better than implicit"

The lack of braces enforces a certain style - something that can be found throughout Python. For example, the lack of multi-line lambda statements.

> braces implied by the negative space

It's easier to think of it in the same way that the compiler does: indent and dedent. Indent? Creating a new scope. Dedent? Exiting the current scope. All of the "constant 4 spaces" and "spaces instead of tabs" simply makes it easier for humans to interpret the indent and dedents visually.

In my experience in writing code in multiple languages: even when using braces you, the coder, still effectively require indentation to visually parse blocks. Yes, copying and pasting code is a touch harder, and most text editors are too lazy to parse for indents and dedents, but the first is mitigated by applying basic DRY principles, the second by installing a python-aware plugin.

The INI example is in response to "Don't make your users created multilayered objects". Personally, I cannot stand TOML, but there's no accounting for taste.

I think the significant whitespace is a pragmatism thing. If you're already doing it, do it consistently, if you're already doing it consistently do you really need brackets? The answer is no, and the added bonus is you (and everybody else) is forced to do the whitespace consistently. I'll take a consistently formatted codebase over inconsistencies any day!

XML was a fact of life in the 90s - inescapable.

Things can change. Push the world forward. Think of little things you can do that make the world of development the world you want to be in.

YAML can go off and die in a fire... especially because it cannot transfer the data type, which JSON can: you have either an integer, a float or a string. Also some libraries want the values escaped, some not, some barf on non-alphanumeric keys... JSON is pretty much standardized across the board.

I use YAML all the time (for config) and the things you mention have caused no more than one minute's frustration in my life. JSON is great for serialisation, YAML for little config files that need frequent hand-editing during development.

Yaml is terrible. The fact that there are so many optional and different ways to format things and the fact that it has significant white space means it's horrible to hand edit. I'd much rather hand edit json. At least it won't care if I accidentally use a tab instead of two spaces.

But of course toml is superior to both because it has comments and no significant white space and the comma at the end of lists is optional.

> you have either an integer, a float or a string.

JSON doesn't have "integers" and "floats", it has "numbers" which are are expressed in decimal scientific notation. There's no guarantee an implementation will let you distinguish what was parsed, and the numerical precision and range of interoperable JSON is undefined.

The bottom line is JSON is a risky proposition for financial or scientific data exchange.

And before you say JSON numbers are de-facto IEEE754 doubles, bare in mind that most JSON implementations can't roundtrip them properly.[0] A symptom of everybody wanting to write a toy implementation.

[0] https://rawgit.com/miloyip/nativejson-benchmark/master/sampl...

Here are some examples: https://github.com/cblp/yaml-sucks

TBH, common JSON implementations have their problems too. Integer size and integer/float (de-)serialization tend to be somewhat interesting at times. I've even seen implementations serializing JavaScript objects as JSON (e.g., {foo: 2} instead of {"foo": 2})

There is a damned good reason JSON does not allow comments. It's not an accident.

So can you fill the rest of us in on the reason then?

You can blame Crockford for that: [1]

TLDR: Basically, in a typical Crockford move, he saw people were using them in a specific way he did not like (to store parsing parameters), so he removed them entirely. I say "typical Crockford" because some of his JS linting rules are gratuitous overkill in my opinion. He also suggests that if you want comments, you should pipe the config file through a minifier that removes them before parsing.

Doesn't seem like that much of a good reason to me, but whatever.

1. https://plus.google.com/+DouglasCrockfordEsq/posts/RK8qyGVaG...

I think he wanted it to be something different than js, hence the focus on strictly data exchange.

Why not use js for config instead of json? It's your app and your config so if you want it to look like json + comments + trailing comma you can. With so many options for config files like yaml, xml, heck even sqlite it does seem a bit silly how much json is used. Herd mentality.

Yeah...that's frustrating. For a Chrome Extension manifest JSON file I was recently editing, you have to enter a description field that I found out is limited to around 100 characters after a failed upload. I wanted to add a comment above this field so myself and anyone else editing the file was aware of this in the future (a good use of comments in my opinion). I'm not going go through the hassle of a build step to do this. Programming languages allow comments for a reason and I don't see what's so different about JSON.

If the consuming program allows it, you can fake a comment by storing it as a JSON property value:

  { "myComment": "This is a comment!", "realValue": 1 }

That's what I did actually. I don't like it though. A comment is really saying "this is a note for the reader that isn't used at runtime". Putting a comment in as a value goes against that and it uses up memory when the file is read in.

On the flip side, I've always found it useful when debugging at a REPL to be able to read various kinds of metadata about objects, including documentation. Clojure is one example of this, but I wouldn't mind seeing it elsewhere as well.

https://clojure.org/reference/metadata

Hmm, so I'm thinking about cases where you have 10K objects and you wouldn't want the metadata duplicated and attached to all of those. Would that happen in Clojure?

Comments also are a bit tricky to preserve when programatically modifying data structures, so a destructive minifier approach makes sense. Although it's very Javascript, "let's make another utility you now need".

Crockford probably didn't think it would take off like it did, but with hindsight comments would have been the pragmatic choice IMO.

It's an excelent reason in my opinion.

They tend not to survive roundtripping well, for example. JSON describes data; comments are metadata. To do them well you'd have to bring them into JSON infoset, such as it is.

(ETA: JSON already has problems with canonicalization. Adding comments makes this worse. Are they in or out of the equivalence over JSON terms?)

Not liking comment macros is not a "damned good reason," it's just a reason. People could still do that in JSON anyway the same way they hack in comments - just add them as strings.

gotta love the hn community, downvoting things that are correct but hurt them feels

no, we downvote things that state an opinion as fact without even an attempt at explaining why, especially when done in a tone that is aggressive and disrespectful.

It's not an opinion however. JSON is a standard. Kinda worries me professionals use it without having a clue.

That JSON has a "good reason" for disallowing comments is an opinion, it could be a popular, well-known and established opinion or it could be completely uninformed. To know the difference one must explain it.

Also standards change, and professionals use their tools in ways the original creators did not imagine a lot, that doesn't make them clueless. Heck, even JSON is a result of professionals misusing a programming language syntax for a serialization protocol.

Your opinion that all opinions must be explained up front was not explained up front.

The reason why something did or didn't make it into a standard are definitely opinions. All sneak had to do was to provide a link to the "damned good reason."