[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.

[captainmuon]

TOML is basically INI. It adds nested sections, but it is not so obvious how to use them. And the data model is more complicated, with sections first, and in each section a key-value map.

YAML has a data model like JSON, but it is disqualified for me by the syntax ambiguities.

The easiest thing is if people could just write JS (or Python) object literals, but restricted to plain old data, and without the ability to call functions etc.. JSON5 gives exactly that.

[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.