Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Comments in JSON

fadefade.com

Post reply on HN
Print view View original

121–130 of 180 posts

Re: Comments in JSON

#121

Post by mst »

NathanKP wrote: post #23

This hack, while nice, is still just a work around. I highly recommend that if you can, in as many places as possible use YAML instead of JSON. JSON works great for on the fly communication with frontends that are running JavaScript, or for communication between JavaScript processes like Node.js servers. But for configuration files and other things that need comments YAML is many times better, both for it's clean, Ma…

YAML is excellent for resource files, i.e. human editing complex data.

For -configuration- you want a simpler format; INI is worth considering, as is http://p3rl.org/JSONY which is ingy's implementation of a vision we thrashed out for a more sysadmin-friendly config format.

Re: Comments in JSON

#122

Post by dnautics »

nonchalance wrote: post #115
nmcfarl wrote: post #101

Earlier quoted context omitted.

> There's no need for comments unless you are trying to use it for something other than raw data. Is this a true statement? Even books have margins, and word docs comments. I think it’s not infrequent that pure data calls for metadata to put it into context for future users of that data. And in computing most "pure data" formats have had either comments - or schemas and specifications which outline which the contents…

You can represent annotations (which describe most of your examples) by adding keys: { "data": "some data", "data_comments": "here are my comments" }

or just use the key "comment" more than once, which is sort of a hybrid of the ideas.

Re: Comments in JSON

#123

Post by ianburrell »

NathanKP wrote: post #23

This hack, while nice, is still just a work around. I highly recommend that if you can, in as many places as possible use YAML instead of JSON. JSON works great for on the fly communication with frontends that are running JavaScript, or for communication between JavaScript processes like Node.js servers. But for configuration files and other things that need comments YAML is many times better, both for it's clean, Ma…

In my experience, YAML is better for configuration files and human edited files. JSON is better for data and communication between computers. The features that make YAML easier to write (comments, more flexible format, less quoting) make it more complex and slower to parse.

Also, many of the security holes in YAML come from its use as a serialization format which can represent native classes. I wish the YAML parsers had more explicit support for simple data schemas which would reduce the security risk and be sufficient for most configuration files.

Re: Comments in JSON

#124

Post by tieTYT »

adamtj wrote: post #106

This is misguided. You don't need comments in a JSON config file. Why? Because you don't use JSON for config files that need comments. JSON is like duc(k|t) tape. It's really easy to stick two things together with it. That doesn't mean you always should. It's the simple thing that gets the job done so you can focus on what matters. One shouldn't pick JSON for your config files and then hold it up as good design. "Loo…

Yeah maybe you don't use JSON for config files that need comments, but that's because there's no documented way of how to put comments in JSON. The article solved the problem.

Actually, I'm 100% playing the devils advocate here. I'll even flip-flop to prove it. Regarding the article, I doubt that every JSON parser will let this slide. To me that's an even better reason to avoid this practice.

Re: Comments in JSON

#125

Post by IanCal »

wissler wrote: post #89
LinaLauneBaer wrote: post #11

There is a interview with the inventor of JSON somewhere. In that interview he explained why he did not allow comments in JSON like in XML. He said - if I remember correctly - that it was intentional to not have comments in JSON. The reason way that comments could be misused to add additional information for a parser. For example in XML you could use comments and a special parser could use these comments to create co…

"I removed comments from JSON because I saw people were using them to hold parsing directives, a practice which would have destroyed interoperability." -- Crockford This is horrific design reasoning. It's an authoritarian, presumptuous, "punish everyone in the classroom because one child misbehaves" mentality. Comments would be useful in JSON because comments are useful in code, and JSON is code . For example, I migh…

> It's an authoritarian ...

Which is pretty much what a specification is.

It's one or more people saying "This is how things are if you call them X".

> presumptuous

Presumptuous? It was in response to the feature being abused!

> "punish everyone in the classroom because one child misbehaves" mentality

No more than creating laws is. A significant subset of the population are misusing it in such a way as could cause widespread damage. It is a minor inconvenience to the 'law abiding people' (particularly given than any comments would be removed if read in and spat out by any program). There are workarounds ("field_comment":"some comment") or if that's not enough, use another format. Use one that allows comments, there are many.

> Don't tell me I can do a silly thing like redefine a field, as if it's "neat". It's an abomination that I have to resort to such things

It's also completely unreliable, it's a terrible solution and nobody should use it. I think we're fully in agreement here.

> And guess what: by resorting to such things I can still do precisely what Crockford claims he was trying to prevent. So his rationale is not only insulting to one's intelligence, it's sheer stupidity.

No you can't. The point was to stop people adding pre-processing commands or other such things to json, which would be in random formats and invisible to some parsers (as comments should be), visible and important to others. You don't want to pass a valid piece of JSON through a parser and end up with two different outcomes dependent on something in a comment, do you? Or have to use parser X or Z because Y doesn't understand directive A, but it does understand directive B and C, and while Z understands C, and X knows B, Z doesn't, so I have to use the version from a pull request from DrPotato which I think supports...

What I'm saying is that there is a benefit in simple standards.

Re: Comments in JSON

#126

Post by glhaynes »

adamtj wrote: post #106

This is misguided. You don't need comments in a JSON config file. Why? Because you don't use JSON for config files that need comments. JSON is like duc(k|t) tape. It's really easy to stick two things together with it. That doesn't mean you always should. It's the simple thing that gets the job done so you can focus on what matters. One shouldn't pick JSON for your config files and then hold it up as good design. "Loo…

If crap design like JSON is the right engineering choice sometimes (and I agree that it is), that seems like an argument that adding comments in this crappy way may sometimes be the right engineering choice.

Re: Comments in JSON

#127

Post by IanCal »

tieTYT wrote: post #124
adamtj wrote: post #106

This is misguided. You don't need comments in a JSON config file. Why? Because you don't use JSON for config files that need comments. JSON is like duc(k|t) tape. It's really easy to stick two things together with it. That doesn't mean you always should. It's the simple thing that gets the job done so you can focus on what matters. One shouldn't pick JSON for your config files and then hold it up as good design. "Loo…

Yeah maybe you don't use JSON for config files that need comments, but that's because there's no documented way of how to put comments in JSON. The article solved the problem. Actually, I'm 100% playing the devils advocate here. I'll even flip-flop to prove it. Regarding the article, I doubt that every JSON parser will let this slide. To me that's an even better reason to avoid this practice.

> Regarding the article, I doubt that every JSON parser will let this slide. To me that's an even better reason to avoid this practice.

If someone uses undefined behaviour in config files for the sake of storing a comment, I reserve the right to hunt them down if I have to maintain their code.

Re: Comments in JSON

#128

Post by IanCal »

glhaynes wrote: post #126
adamtj wrote: post #106

This is misguided. You don't need comments in a JSON config file. Why? Because you don't use JSON for config files that need comments. JSON is like duc(k|t) tape. It's really easy to stick two things together with it. That doesn't mean you always should. It's the simple thing that gets the job done so you can focus on what matters. One shouldn't pick JSON for your config files and then hold it up as good design. "Loo…

If crap design like JSON is the right engineering choice sometimes (and I agree that it is), that seems like an argument that adding comments in this crappy way may sometimes be the right engineering choice.

Relying on undefined behaviour in a parser for comments is something I find quite hard to define as "the right engineering choice" in any situation.

Re: Comments in JSON

#129

Post by IanCal »

wissler wrote: post #98
nonchalance wrote: post #93

Earlier quoted context omitted.

> and JSON is code JSON is data. It appears to be JS code, but JSON is data. Data is not code ( http://www.c2.com/cgi-bin/wiki?DataAndCodeAreNotTheSameThing ). That's why the idea of data holding parsing directives is silly. If you want to do that, then embed that in the data (hold a MsgType key in the data records). There's no need for comments unless you are trying to use it for something other than raw data.

Nonsense. This is just more arrogance. JSON is code because I use it as code. It's not your business to tell me it's not code -- you haven't seen how I'm using it . And don't go chirping that I should only do things your way, it's none of your god damned business what I'm using it for. Further, if JSON was really only data, then it's an incredibly stupid way to store data, given that it has a human-readable syntax th…

You can use a screwdriver as a hammer all you want, it's not going to make it a good idea. This isn't a free speech issue.

> Further, if JSON was really only data, then it's an incredibly stupid way to store data, given that it has a human-readable syntax that the computer can only deal with after it's been parsed. As data, it's bloated and inefficient.

So use something else. Also, a computer can only read any file after it's been parsed in some way. I'm not really sure what you're suggesting as an alternative.

> To the extent that JSON is a good format, it's code

Is it executable? Is it turing complete?

Re: Comments in JSON

#130

Post by defen »

wissler wrote: post #98
nonchalance wrote: post #93

Earlier quoted context omitted.

> and JSON is code JSON is data. It appears to be JS code, but JSON is data. Data is not code ( http://www.c2.com/cgi-bin/wiki?DataAndCodeAreNotTheSameThing ). That's why the idea of data holding parsing directives is silly. If you want to do that, then embed that in the data (hold a MsgType key in the data records). There's no need for comments unless you are trying to use it for something other than raw data.

Nonsense. This is just more arrogance. JSON is code because I use it as code. It's not your business to tell me it's not code -- you haven't seen how I'm using it . And don't go chirping that I should only do things your way, it's none of your god damned business what I'm using it for. Further, if JSON was really only data, then it's an incredibly stupid way to store data, given that it has a human-readable syntax th…

> JSON is code because I use it as code

You can't use JSON to compute things, therefore it is not code (unless you are willing to concede that any document format is code).

Post reply on HN