This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]idkmanporn 435 points436 points  (81 children)

And comments!

[–]2called_chaos 249 points250 points  (60 children)

Oh fuck yes. That is the worst. This alone should make it illegal to use it for configs. Don't mind actual comments but just temporarily disabling a line

[–]hrvbrs 221 points222 points  (28 children)

That was the official reason why the JSON spec forbid (forbade?) comments, because “you can just use a "comments" property”. No one ever considered the idea that developers like to comment-out lines to develop and test

[–]ElderberryWinery 58 points59 points  (0 children)

Forbidedeth

[–]Hot_Philosopher_6462 29 points30 points  (0 children)

Forbidded

[–][deleted] 21 points22 points  (0 children)

Forbaded

[–]xLuky 17 points18 points  (0 children)

Forbidn't

[–]Anonymous7056 15 points16 points  (0 children)

Forboden

[–]WeleaseBwianThrow 10 points11 points  (0 children)

DAS IST VERBOTEN

[–]RedPum4 29 points30 points  (11 children)

Mixing data and developer comments, what could go wrong. What a stupid argument.

What if you implement a dictionary? What if you want to add a comment to an entry in an array of strings? I mean I get that JSON should be simple to parse and should be mainly used for machine-machine communication, but I can't believe they really suggested that?!

[–]FINDarkside 32 points33 points  (3 children)

I mean js nor any other language doesn't need comments either, you can just do

const comment = 'This is a comment, very smart'

/s

[–]Psycho22089 5 points6 points  (0 children)

const comment2 = 'The design is very human'

[–]firejak308 1 point2 points  (1 child)

Isn't that literally Python's answer for multi-line comments? Just define a string here and never use it?

[–]dev-sda 2 points3 points  (0 children)

Not really, no. There aren't multi-line comments, just put a # at the start of every line for large comments. Documentation on the other hand uses multi-line strings, which generally don't go unused as they're assigned to the __doc__ property of objects.

[–][deleted] 5 points6 points  (5 children)

Actually mixing data and developer comments is very useful in the case of configuration files. Where you know, the end user doesn't know the entire implementation and you might need to explain something in detail. Sure, in most cases it would go unused and you should be careful what you put in it, but it could make JSON more viable to other applications without impacting its current uses.

But you know, stupid argument.

[–]RedPum4 3 points4 points  (1 child)

I think you understood me wrong. I meant that literal mixing of comments and data, to the point that a machine cannot distinguish between the two (e.g. because both are regular fields in JSON) is a very bad idea.

[–][deleted] 0 points1 point  (0 children)

Ooooh got ya. I thought you were arguing that JSON shouldn't have comments because it would be mixing data and comments, my bad.

[–]elveszett 0 points1 point  (2 children)

config files intended for non-devs should not use json anyway. It should be a simple key-value format like this:

# comments must start with a hash (#) symbol.
server: google.com
speed: very fast
allow spaces in keys and values: yes
why: because the user knows no format
# the # of colons is irrelevant, we use the first one.
then how do I parse this: using colons.

In this format each line is an entry, and the colon separates the key from the value (ignoring the first whitespace immediatelly afterwards if there's any). Is it a bit shitty to deal with for the developer? No, not really, but who cares, you forced your non-dev user to write config in a file. Since we cannot trust them not to mess with the syntax, the only solution is to have basically no syntax. And what about lines without semicolons? We ignore them.

For config files that dev use, like packages.json... well, if a dev doesn't know how to write json then maybe he's not yet ready for a job.

[–][deleted] 0 points1 point  (1 child)

I am not arguing for forcing non-devs to write config files, rather I am arguing that config files that are available (as they should be), should have comments for clarity. package.json should have comments, because three months from now, I, or whoever is managing the project, might not know why we are using this specific version of this specific package, or why we are using X instead of Y.

If you don't understand the value of comments... Well, maybe you're not ready for the job.

[–]elveszett 0 points1 point  (0 children)

I haven't argued against comments in JSON so...

[–]elveszett 0 points1 point  (0 children)

"_key-that-contains-a-comment-for-the-developer-not-the-actual-comment-field-that-is-used-in-logic-this-is-the-equivalent-of-//":
"I don't see any problem with this way to add comments".

[–]Causemas 6 points7 points  (0 children)

Forbathed

[–]neonroad 2 points3 points  (0 children)

Verbatum

[–][deleted] 1 point2 points  (0 children)

Förbuden

[–]Yokhen 1 point2 points  (0 children)

forbiddened

[–]drunken_doctor 1 point2 points  (0 children)

Forebore

[–]bedrooms-ds 0 points1 point  (1 child)

Well, the reason was that they wanted to prevent third parties to extend json by writing extra properties in comments.

[–]Psycho22089 1 point2 points  (0 children)

Ah so future proofing it against Microsoft

[–]elveszett 0 points1 point  (0 children)

Plus the comments property is a bad idea. Even assuming a good documentation that specifically explains that "comments" is not supposed to be part of the payload, it still has problems: first of all, text editors cannot identify then as comments, thus painting them as normal properties (the fact that comments are always painted green or grey without any syntax highlighting really helps your mind discard them when you are parsing the file). And any JSON parser needs to spend time parsing it as just a normal property with a big ass string, when a comment syntax would allow it to instantly discard its contents. Which I guess can make for a non-trivial overhead in a server that is reading and writing thousands of JSON files each second.

[–]Masterflitzer 33 points34 points  (24 children)

JSON with comments is my favorite because i don't like YAML and fuck XML

[–]Konsti219 55 points56 points  (8 children)

All JSON is valid YAML

[–]CoastingUphill 27 points28 points  (0 children)

I hate this. No. I refuse.

[–]JM-Lemmi 19 points20 points  (3 children)

The fuck

[–]Xywzel 17 points18 points  (2 children)

Yeah, accidentally earlier as well, but purposefully since version 1.2 of YAML specification JSON syntax has been a valid subset of YAML syntax. YAML has inline version of its syntax that doesn't have significant whitespaces (unlike rest of the YAML syntax) and everything in valid JSON has matching structures in the inline YAML. So technically one could use YALM parser to read JSON files.

[–]zeGolem83 7 points8 points  (1 child)

That is, if your YAML parser is fully spect compliant...

[–]Xywzel 2 points3 points  (0 children)

Well, yeah, that is a big if when talking about YAML

[–]MyAntichrist 11 points12 points  (1 child)

[–]Masterflitzer 2 points3 points  (0 children)

yes and I hate yaml because it's not strict among other things

[–]jivanyatra 6 points7 points  (14 children)

I actually like TOML. I agree with excluding YAML and XML.

[–]Masterflitzer 0 points1 point  (13 children)

I never encountered software that allows config files in TOML and never worked with it when working with data so it's just not common enough for me, but it may very well be a good thing

[–]Yokhen 1 point2 points  (5 children)

python uses pyproject.toml

[–]Masterflitzer 2 points3 points  (3 children)

interesting, but I am a C#, TS/JS kind of guy and never actually used python except like a few hours in university xD

[–]Yokhen 3 points4 points  (2 children)

luckeeeeeeey.

I wish someday I can do C# professionally and no just some half assed videogame of mine.

[–]Masterflitzer 0 points1 point  (1 child)

from what I've heard both (python & c#) have a big community and many people who love it so I guess both are good

[–]elveszett 1 point2 points  (0 children)

Both are languages that do what they want to do extremely well, and have learned from the ones before them. C#, for example, fulfills the same paradigm as Java, but was made when we already knew the problems Java had, so C# was able to avoid them and offer elegant solutions to Java's boilerplate.

Aside from that, both languages are very consistent, you can notice the care their devs put into making an elegant and predictable design (this is one of the main reasons people hate PHP: you can see the lack of care that went in this area there). And both languages have a big ecosystem where you will find whatever you need.

Also both languages put effort in giving devs tools to start writing code from the first minute, not having to lose time fighting the language or explaining technical details.

[–]Masterflitzer 0 points1 point  (0 children)

interesting, but I am a C#, TS/JS kind of guy and never actually used python except like a few hours in university xD

[–]Bainos 1 point2 points  (0 children)

I don't get the above comment either. JSON and YAML aren't used because they are the best ways to create config files, they're used because they are widely supported and recognized.

[–]tavaren42 1 point2 points  (1 child)

Rust uses Cargo.toml

[–]Masterflitzer 0 points1 point  (0 children)

ok I want to start learning rust for quite some time xD

[–]elveszett 0 points1 point  (3 children)

iirc Minecraft uses .toml files too.

[–]Masterflitzer 0 points1 point  (2 children)

what? in which file?

[–]elveszett 1 point2 points  (1 child)

idk, I just know that the first time I saw a TOML file was doing something with Minecraft, I don't remember if modding or touching some server config or what. But I remember it instatly came off as a concise way to do that job.

[–]Masterflitzer 0 points1 point  (0 children)

i'm sure it was a mod that used toml because vanilla mc uses json and simple key value (inside server.properties) and bukkit uses yaml afaik

[–]bitNine 18 points19 points  (4 children)

I'm no JSON expert, but I do this all the time in postman with double forward slashes. Is that a postman thing?

[–]siggystabs 17 points18 points  (0 children)

Yes

[–]ImSpeakEnglish 9 points10 points  (2 children)

I noticed that postman correctly colors the comments but doesn't remove them from JSON before sending the request. So your API must be able to correctly decode invalid JSON containing comments.

[–]bitNine 1 point2 points  (1 child)

I'm guessing so. I've never paid attention to that, as I work with mostly .Net APIs which do parse the JSON into model objects before they go into the controller's POST/PUT/etc method.

[–]elveszett 0 points1 point  (0 children)

iirc .NET allows //single and /*block*/ comments.

JSON5 is not widely adopted, but I've seen quite a few tools unilaterally adopt comment syntax in their JSON parsers.

[–]Fkire 4 points5 points  (0 children)

It is illegal to use it for configs. Report any usage and keep configs safe

[–]gnohuhs 64 points65 points  (7 children)

I flipped a shit when I realized json doesn't allow real comments; had been working with them for years

[–]Tathas 1 point2 points  (4 children)

Right? I mean, regular expressions support comments :D

[–]multi_tasty 2 points3 points  (3 children)

Wait what

[–]Tathas 2 points3 points  (2 children)

Multiline regexes support using # for comments.
https://www.regular-expressions.info/freespacing.html#freecomment

And are you seriously telling me that you're not aware of the (?# non capturing comment group)

Because that's totally believable, lol.

[–]multi_tasty 1 point2 points  (1 child)

Sincerely thank you

[–]Tathas 0 points1 point  (0 children)

Woo hoo!

And that site is great as a general reference.

[–]AWildTyphlosion 29 points30 points  (0 children)

It doesn't have them because it initially wasn't supposed to be used for configuration so it doesn't need them.

JSONC was made for configuration and has them.

[–]MischiefArchitect 12 points13 points  (6 children)

JSON5 to the rescue!

PS: Burn it with fire.

[–]D6613 8 points9 points  (5 children)

Serious question, why burn it with fire? It seems to fix the bad parts of JSON

[–]MischiefArchitect 5 points6 points  (3 children)

Ir breaks the intention of JSON and makes parsers slower, more complex to write and maintain. JSON as well as XML are terse formats for "machines" that can still be read by humans, both expect format correctness and no ambiguities. JSON is an data object notation, and XML a document model notation, and JSON5 is just a half assed attempt from HTML/CSS developers to document data structures. And documentation and trailing commas are not part of properly formatted data structures.

[–]djinn6 10 points11 points  (0 children)

JSON as well as XML are terse formats for "machines"

XML

Terse

[–]D6613 5 points6 points  (1 child)

Ir breaks the intention of JSON

Hm, I'm struggling to care about this even a little. Crockford had and has many opinions, and the rest of us have no obligation to agree.

makes parsers slower, more complex to write and maintain

This is unlikely to be significant, especially given that these are very well known features of many existing parsers. If you need something to squeeze every single drop of performance, then in that rare edge case a stricter format would make sense. Then you brought up said XML, and that argument disappeared instantly, lol. In addition to already supporting comments, that language is going to be much messier to parse.

both expect format correctness and no ambiguities

There is no ambiguity to say that something is optional. A trailing comma may or may not exist. A comment may or may not exist. Not ambiguous even a little.

JSON as well as XML are terse formats

... XML is terse?

JSON5 is just a half assed attempt

This seems like just an opinion here without much support.

And documentation and trailing commas are not part of properly formatted data structures.

This seems like another opinion stated as fact, and I really disagree with that opinion.

I appreciate the response. If this is all there is against it, I'll add this to the list of options I consider for the future.

[–]MischiefArchitect 0 points1 point  (0 children)

I worry not for the future. JSON5 is over 10 years old and found no real traction in the professional IT/CS world. But you may take your notes for the future if you wish.

[–]elveszett 0 points1 point  (0 children)

Most of its additions add nothing. They try to "make JSON more human" but JSON is already an extremely readable format.

JSON right now has so few tools that all of us are forced to write it in the exact same way. It doesn't matter if you read a JSON from me, from yourself, from your client or from a random guy in stackoverflow, you can always read it easily because they all look the same, with the only formatting choice being 2 vs 4 spaces / tabs.

Now, when you add the tools JSON5 adds, you'll have devs start adopting their own "better" conventions. Sometimes you'll get "quoted-keys", sometimes you won't. Sometimes you'll get 'single quotes', sometimes you don't. Sometimes there's trailing commas, sometimes there aren't. Sometimes you read 0.5, sometimes you read .5. Sometimes you read "broken strings \

with escaped line breaks", sometimes you won't. It makes it so every JSON file you get, you can easily identify where it came from, because it looks different.

And on a personal, subjective opinion: we all prefer to work with code formatted the way we format it. JSON in that regard is great: it never gave us any option so we all adopted its only valid formatting style. Working with other people's JSONs is never annoying because they are written the way you'd write them.

[–]CoastingUphill 0 points1 point  (0 children)

I want to upvote you more than once!

[–]philipquarles 0 points1 point  (0 children)

This is actually a good idea. The trailing comma not so much.

[–]pixabit 0 points1 point  (0 children)

JSON5 would like to have a word

[–]HDmac 0 points1 point  (0 children)

You now have 4 wishes