The reason never made much sense, anything can be abused, and the comment use case is easily way more important, and your suggestion doesn't help with eg syntax highlighting tools for your config that will treat comments as syntax errors, and also lose the ability to roundtrip, so your app can't edit user configs

That doesn't make it a good reason. People are placing those directives into json docs anyway, but instead they're relying on nobody causing a namespace collision with their special key whos associated value has the directives of interest.

FWIW, I'm well aware of Crockford's rationale, I think it's some of the dumbest rationalization I've heard, and time has shown that it was a giant mistake.

Trying to prevent programmers from doing something "because they may 'misuse' comments" is asinine to the extreme. This is not like removing a footgun, it's trying to dictate how you think programming should be done. This is particularly hilarious because I've instead seen tons of horribly hacky workarounds for JSON's lack of comments, e.g. "fake" object entries like "__previousKey_comment": "this is a comment for previous key", or even worse, putting two entries with the same key since the second key should "win", and thus making the first entry the comment.

As for his second point, "Suppose you are using JSON to keep configuration files, which you would like to annotate. Go ahead and insert all the comments you like. Then pipe it through JSMin before handing it to your JSON parser." - just look at the everlasting shit show that is package.json since it can't support comments, because lots of NPM tools actually write to package.json, so there is no guarantee that other tools will be able to read package.json if it includes comments.

I think the thing that I hate most about Crockford's rationalization of not having comments is that you have to have your head stuck 10 feet in the sand to pretend that somehow the lack of comments is a good thing with the benefit of hindsight. I guess I could understand if Crockford's position was "Yeah, originally I thought it was better to keep them out because I was concerned about misuse, but now in retrospect to see the much larger problems it causes, and I realize it was a mistake." But instead he just keeps pushing his original crappy opinion on this topic.

So instead of comments with parsing directives, people use underscore prefixed keys to keep metadata and comments, that's not a win at all

We should call this "The Crockford Fallacy". Destroying something valuable in fear of a perceived threat.

One way to bifurcate the world is that there are people who tend to restrict options to prevent misuse vs. people who tend to enable options to the positive uses easier. I fall in the latter camp. Preventing errors by restricting options also prevents positive uses that make life better.

We get to choose what approach we take. I prefer the "give them the rope they might need" philosophy. If they hang themselves, oh well.

Software developers very much so care about best practices.

All that needed to be said was, "Using comment programmatically is bad practice. Don't do it."

> I removed comments from JSON because I saw people were using them to hold parsing directives

there's always someone putting actual logic in comments, and when I rule the world, those people are all going to be put on an island by themselves and they're going to have to deal with each other.

It might be abused and you can just pipe it through a preprocessor are not very good reasons.

Abuse of comments is not an academic, theoretical consideration.

https://www2.jwz.org/doc/cddb.html

(Unfortunately, because jwz blocks HN referrals, you can't click on this link, but will need to copy it into the address bar)

And that is fine reasoning, the workaround is not for me… but the larger issue is an inventor kneecapping something by stating how you should use it.

It’s not like there isn’t another side to this argument.

That's a terrible reasoning for requiring an extra toolchain.

There's also HJSON, which stands for Human JSON.

https://hjson.github.io/

It has implementations in JavaScript, C#, C++, Go, Java, Lua, PHP, Python, Rust.

If we consider sigfigs, then isn't 100 and 100. two different numbers given one has a single significant digit and the other has 3? For 101 and 101. it doesn't matter because both have 3 significant digits. Then again, one may argue that it is better to write 1e2 and 1.00e2 instead of 100 and 100.. It also avoids the weirdness of the double period if the number with a dot ends a sentence.

On a personal level, I also don't like ending a number with a . because my brain immediately parses it as a sentence ender and it interrupts my reading flow.

It has nothing to do with laziness in typing.

It's just not wanting to keep track of more rules. If you've only ever used languages where a leading decimal point is allowed, it's a pain point to suddenly have to remember that it isn't here, and for no obviously intuitive reason.

It's about wanting to avoid unnecessary conceptual friction. Not lazy keyboard usage.

(Heck, your second example uses an extra keystroke. And it's perfectly readable to me, based on the languages I use.)

I never understood leading dot until I understood that native speakers indeed say ".3" (point three).

Trailing makes it a floating point type instead of an integer

It’s not about readability, it’s being realistic about other humans and making software robust in the presence of common, trivial, unambiguous “errors”.

Reference: Postel’s Law

https://www.laws-of-software.com/laws/postel/

Well what's more readable, .8675309 that is understood to have an implicit zero, or the parser giving up and unexpectedly making it a string? Maybe it's not your preference but I can't see any problem with making this more robust. The trailing one is strange to me but leaving off a leading zero isn't unusual at all for written numbers in my experience.

as a student experimenting with millions of records of data, its pretty nice!

I agree, if one of those myriad alternatives is to be used, at least specify that clearly.

I agree 100%. It is such a pain to write tools that have to account for all these exceptions.

The problem of yaml is that it allows too much. It allows unquoted strings, and those can be interpreted by the parser as numbers, timestamps, booleans, etc. This is a source of many fooguns.

Use of indentation to denote nesting can sometimes be an anti-feature, too, because while using that the format does not provide a way to make certain that the entire stream has been read (parens balanced). This may lead to problems or even exploits.

Pure JSON is so painful for human consumption though, I willingly choose yaml if it's the only alternative.

JSON5 may indeed be a sweet spot between human-friendliness and lack of nasty surprises.

Whilst YAML is an option, if the choice is between having the unnecessary extra features of JSON5 or YAML, JSON5 seems like the clear winner.

Allowing multiple types of quotes may be an unnecessary feature but it is a clear lesser evil compared to the mountain of footguns that YAML brings with it.

Agreed. The workaround (arrays of strings) isn't great as it means an extra transformation has to be done between the reader and the usage. I would go so far as to say this is more important than comments.

Why not just a parser? Should be easy enough.

Except that JSON is a valid JavaScript object, and JSON5 is not.

I think JSONC is the term for json with comments and trailing commas

Lots of things are useful. I think json has been succesful largely because it preferred minimalism over usefulness.

The project description describes it as json plus syntax from emcascript 5.1 (commonly called ES5) [the official name of javascript is emcascript]. I imagine that is where the name comes from.

Although it doesn't really make sense since most of the stuff they add predates ES5.

Ha. There is no way that’s what it means unless you read that somewhere.

I agree with the others that ES5 is likely where it came from, but my mind also jumped to The Jackson 5.

I assumed it was a play on HTML5 ¯\_(ツ)_/¯

This. I hate how all these serialization/config formats come out of dynamically typed languages. Static typing is a must. Then so many classes of errors go away.

Fair, YAML has a lot of usability warts, and those suck too. Although personally I really do hate how tough it is to tell apart arrays and objects, at least with the most common YAML array/object style.

A reimplementation of jq in golang supports reading yaml and, of course, emits json: https://github.com/itchyny/gojq#:~:text=supports%20reading%2...

That one is likely more relevant than yq since folks in the json ecosystem are far more likely to be familiar with jq's syntax and thus using gojq is "one stop shopping," not to mention that its error handling is light-years beyond jqlang's copy

I'm confused about your point about YAML being "strict superset of JSON" leading to being able to convert YAML to JSON.

If YAML is a strict superset, wouldn't that mean that YAML must have at least one feature that is not part of JSON? Wouldn't that make it impossible to define all YAML files as valid JSON?

For sure, but most YAML you actually encounter does not use much in the way of JSON syntax, it looks a lot more like this: https://devblogs.microsoft.com/devops/wp-content/uploads/sit...

Where arrays and objects just look too similar (IMO), white space is significant, most strings are unquoted, etc. And personally I find it quite difficult to really understand what’s going on there, at a glance, compared to JSON (or JSON5).

Don’t have any experience with them.

same is true of YAML as a JSON superset

Is there an example of what it looks like in practice? The Wikipedia link above doesn't have it, its citation http://edn-format.org/ seems like it doesn't exist anymore, and this github page doesn't show a sample either.

> Perhaps EDN can also be improved

How might you improve EDN?

I find toml impossible to both read and write in all but the simplest cases.

> trivially parseable by JavaScript going back to when people just evaluated it

Comments and all, ironically.

I mean sure, "and all" would frequently include script injections etc, but you can't argue it wasn't more feature rich!

Why not use JSONC then?

Ever since YAML 1.2, released in 2009(!), your YAML example would parse your input as “is yaml robust” for the key, and “no” for the value.

The problem with XML was people were using it for every possible thing they could think of and 90% of those ideas were garbage.

That's a reasonable approach, however I would argue it's incomplete without acknowledging the historical context. How could the specification explicitly acknowledge this as technical debt from the original design rather than letting readers assume it was an intentional architectural choice? Such context informs implementers about the constraints they're working with.

It's not made explicit in the documentation, but TOML is very nearly a superset of JSON - just using `=` to separate key-value pairs instead of `:`, and requiring top-level names to be given explicitly, and requiring the "inline" bits to be on a single line. In TOML, your example can equivalently be:

    a = { b = [ { x = 1 } ], y = 2 }

(And yes, that can be the entire document; you can have an inline table before the first table header.)

Of course, this doesn't help if you want the top level to be an "array" rather than an "object" (in JSON parlance), or if you want the entire document to represent a single primitive value. But these uses are discouraged at best anyway.

But really the goal of TOML is to highlight the location of important parts of the deserialized tree structure (hence the ability to use arbitrary long dotted paths in table headers) rather than the structure itself. It's IMO a beautiful implementation of the idea "flat is better than nested" from the Zen of Python, and it neatly sidesteps an issue I asked about many years ago on Stack Overflow (https://stackoverflow.com/questions/4372229 - the question was rightfully closed, as this sort of discussion doesn't fit the Q&A format; but it made sense to ask at the time).

I don't know if a direct comparison of TOML to YAML is fair. Among other differences, the standard way to parse YAML in Python involves a third-party library that brings in a ~2.5 MB compiled C library. Every TOML implementation I encountered - including the one that made it into the standard library - is pure Python.

Your TOML is rather convoluted, a more normal way to write it would be:

  [a]
  b = [{x = 1}]
  y = 2

Or alternatively:

  a.b = [{x = 1}]
  a.y = 2

Some parsers allow newlines in TOML inline tables, so you can do:

  a = {
    b = [{x = 1}],
    y = 2,
  }

That's supposed to be in the next TOML standard, but that seems indefinitely stalled as the (only) maintainer has seemingly lost interest and there hasn't been any movement for a long time.

This is also the reason I prefer XML to JSON when things really got complex. XML is verbose but it is very readable on long form. I wish Rust actually used JSON or XML as Cargo file format.

> not possible to apply in all situations (array in map in array).

Yes, that's largely why inline tables and arrays exist:

   >>> tomllib.loads("""
   ... [[outer]]
   ... first = [1, 2, 3]
   ... second = [4, 5, 6]
   ... 
   ... [[outer]]
   ... third = [7, 8, 9]
   ... fourth = [10, 11, 12]
   ... """)
   {'outer': [{'first': [1, 2, 3], 'second': [4, 5, 6]}, {'third': [7, 8, 9], 'fourth': [10, 11, 12]}]}