[codedokode]

Honestly I don't understand why JSON should be human-readable. It is a data serialization format intended to be read by software.

Just adding comments and multi-line strings doesn't make it human-readable, it is still too bloated and I don't like writing it manually. If you want a human-readable format, try at least to remove unnecessary quotes, brackets and commas and make it look similar to YAML.

JSON is not intended to be used in configs and other user-editable files.

[kryptiskt]

The first two sentences of the text on http://json.org are "JSON (JavaScript Object Notation) is a lightweight data-interchange format. It is easy for humans to read and write."

It's a primary goal of JSON, it's fair to question whether it's successful at it. Personally, I'd much rather write TOML or S expressions. I don't like YAML at all, the whitespace sensitivity drives me nuts.

[inopinatus]

Douglas Crockford usually says he discovered JSON, and subsequently named it and wrote a specification, and I think this precludes suggesting it had design goals, because it wasn't an invention. More broadly, I also think this understanding of JSON's origins absolves the discoverers of its limitations, and opens the door to talking about improvements and variations.

Notwithstanding which, I too would prefer to interchange data via S-expressions.

[Dylan16807]

He made changes that were based on design goals. He simplified a few parts, and removed comments with the explicitly stated goal of avoiding parsing directives.

We can say the underlying idea of taking javascript's object syntax was a discovery, but he refined it between discovery and release.

[inopinatus]

This seems to merely be applying Saint-Exupéry's rule as an editor, which is a matter of baseline competence, and hardly seems worthy of description as a goal of any sort.

[xbar]

I don't follow your discovery/goal-less-ness argument. Why couldn't one of the things present in his discovery be readability?

+1 on those S-expressions.

[inopinatus]

Early versions of JSON supported // comments. As Crockford tells the story, they were removed because folks were using them for pragma, leading to interoperability issues, and because several parser authors working in languages other than Javascript reported surprising levels of complexity when implementing comments.

My point being; aspects that seem like irritating omissions now, may have been editing decisions instrumental in the overall adoption of the standard.

[XorNot]

I don't get how anyone uses TOML. YAML is whitespace sensitive but it's python rules and quite sensible.

TOML is just plain unreadable to me when I have to figure out what I'm looking at: I convert it to YAML to both read and write it when I have to add new lists/maps.

[nullwarp]

You are not alone, I find TOML awful to use and hate when I get forced into it.

Give me YAML or JSON at least they make sense.

[dietrichepp]

> JSON is not intended to be used in configs and other user-editable files.

Yes, but it’s a bit late for that.

It sounds like you’re advocating for a configuration format somewhere in the space between JSON and YAML. Not JSON, because it’s annoying to write by hand, no comments, no trailing commas. Not YAML, because of all those unintuitive edge cases like “no” (unquoted) being a Boolean.

It sounds like the primary disagreement here is where in the design space between JSON and YAML is the right syntax for configuration files.

[auxym]

KDL comes to mind : https://kdl.dev/

[filoeleven]

See edn extensible data notation. https://github.com/edn-format/edn

[arinlen]

> Yes, but it’s a bit late for that.

That just shows poor judgement on behalf of the developer who made that decision, not a failing of the language.

[dietrichepp]

Right… and the fix is to switch from JSON to JSON5.

I don’t see how assigning blame is productive here. People choose the wrong language, wrong library, or wrong tool all the time.

[arinlen]

> Right… and the fix is to switch from JSON to JSON5.

Not really. JSON offers no challenge in editing by hand. All comments I've seen in this thread boil down to people trying to pass off whimsical nice-to-haves as this sort of insurmountable problem.

I mean, I do like a nice git history with small diffs. Not supporting trailing commas is unfortunate as it can cause the trailing line to show up in diffs if you add a comma there. But is this a problem? No, it is not.

Let's be honest here: JSON5 solves no problem worth solving, at the expense of breaking compatibility.

[captainmuon]

> Let's be honest here: JSON5 solves no problem worth solving, at the expense of breaking compatibility.

The problem I have is, I need a configuration language that is human readable, familiar to developers without teaching (anybody who knows JS, or to some extent Python and PHP), is also machine writable, and supports comments. The only language that supports this is JSON+comments (next contenders would be INI (!) and then XML). JSON5 just helps by giving it a name, a consistent implementation, and packages for many languages. I've rolled my own JSON+comments (or "static subset of Python / JS literals") multiple times, and am glad there is a community standard now.

The trailing comma is really an issue, because it works in JS, and it is an arbitrary restriction in JSON. If you learn JSON on the job (and think of it as "JavaScript Object Notation" i.e. JS literals) then you will run into this, and it causes unneccessary frustration.

Since every JSON5 package I know produces valid plain JSON, compatibility is never an issue.

[arinlen]

> The problem I have is, I need a configuration language that is human readable, familiar to developers without teaching (anybody who knows JS, or to some extent Python and PHP), is also machine writable, and supports comments.

I'd say if those were your criterias and you still stuck with a JSON-derived language, your decision-making process was a colossal failure in oversight, given the myriad of options around such as TOML or even YAML.

But let's pretend that adding comments and trailing commas to JSON makes any difference regarding those requirements.

[claytongulick]

Under that argument, why bother improving anything?

At the end of the day, you can do anything you need to do in C.

What's the point of having all these other languages?

[arinlen]

> Under that argument, why bother improving anything?

That's not the problem, is it?

The choice you're faced with is breaking compatibility just to add little to no value.

[Jare]

I read and write json manually almost every day. I haven't bothered to insert json5 in our pipelines for various reasons, but I sure wish it was the default.

The interesting question I think is, why do you think json is so used in that capacity despite not being meant for it? Why YAML, despite being so widespread, hasn't swept json away for those purposes? (let's for a moment ignore that YAML can go REALLY nuts, and think only of the simplest version of it)

[Falkon1313]

I used to think YAML would be great for that sort of thing. Now, having dealt with some large YAML files, I understand at least a couple of reasons why people don't like it for that. Things that are invisible when visually looking at a file, and not really detectable by IDEs or linters or anything (because they would have to assume your intent).

In a small file, semantic indentation is beautiful. In a large file where you have to scroll and scroll to find out where you are, it's a pain. And perhaps importantly - can't be autoformatted. Your IDE doesn't know what indentation level you intended, and without braces/brackets to tell it, it can't detect errors.

There's parsing automagic wackiness if you're not careful (the famous example: country abbreviation NO for Norway becomes FALSE).

The nice feature of references is almost never actually used in practice. An incorrect or circular reference can look fine but badly break things.

Yaml typing is application (and version) dependent so not really useful.

There's more, but basically JSON, though simpler and uglier, prevents all of those. You can, and pretty much have to, use an alternative 'safe YAML' parser, but even that doesn't solve some of the problems.

[NonNefarious]

References are used quite a bit. Look at OpenAPI; they're critical to that effort.

[LtWorf]

> let's for a moment ignore that YAML can go REALLY nuts, and think only of the simplest version of it

But we can't ignore it… we have to validate and make sure it isn't going too nuts. And we will probably fail at that.

[userbinator]

Also, "human-readable" is somewhat of a relative term. I can read a hexdump of many binary protocols as easily as I can English, and over a billion humans can read a language that seems impenetrable to the other several billion on this planet.

[cgrealy]

Because it's really handy to be able to run things like rest requests without any tooling more than curl or postman?

[ajkjk]

> It is a data serialization format intended to be read by software.

This really... doesn't matter. Humans read and write it all the time. If everybody is getting annoyed at it because they're reading it, they have every right to wish it was more human-readable, hence trying to make it so. There's nothing wrong with that.

[sacrosancty]

Programmer readable, not user readable. It's far easier to learn what it means by just looking at an example than by reading some abstract documentation as you would have to with binary data or some home-made format.

[orthoxerox]

What you want is something like Relaxed JSON (http://www.relaxedjson.org/), but it's not valid JS, while JSON5 is.

[bobbylarrybobby]

Yaml is kind of readable, but god help you if you have to write it