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

101–110 of 180 posts

Re: Comments in JSON

#101

Post by nmcfarl »

nonchalance wrote: post #93
wissler wrote: post #89

Earlier quoted context omitted.

"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…

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

> 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. The later sure look like comments stored externally to the documents, from my perspective.

In general I do not think data is self describing, and thus must be commented on in some form to describe it.

Re: Comments in JSON

#102

Post by DominikR »

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…

A fork can be a spoon for you, if you choose to use it that way. Nobody is telling you what you are supposed to use it for, but still JSON was designed as data format.

If you don't like the format or feel that JSON is too restrictive/bad feel free to extend it or create your own format from scratch.

Re: Comments in JSON

#103

Post by breck »

NathanKP wrote: post #80
breck wrote: post #54

Earlier quoted context omitted.

While on the topic of encodings (I'm a huge encodings geek), let me plug a new one we recently discovered called Space ( https://github.com/nudgepad/space ). It is dead simple and has the nice feature that it is extraordinarily easy for both humans and machines to read and write.

It is definitely very minimalist. Personally I have issues parsing it visually though, because the indentation of only one space makes it hard to differentiate inner data structures particularly on a large screen with small fonts. Additionally the lack of a division character other than space between the key and the value makes reading each key value pair much harder because the key and value tend to run together vis…

Thanks for the feedback. I totally agree with you.

Adding easy syntax highlighting is my next step to address this problem.

Re: Comments in JSON

#104

Post by dnautics »

MatthewPhillips wrote: post #94
kstenerud wrote: post #86

Instead of using tricks that rely on parser implementation behaviors, why not just put an actual comment field in the object? { "myvalue_comment": "This is a comment", "myvalue": 42 }

That example is fine, but you wouldn't want a long comment getting loaded into memory because the parser doesn't know any better.

for that matter, just do:

{

  "comment":"this is a comment";
  "value": 45;

  "comment":"this is also a comment";
  "value2": 64;

  "comment":"we like overloading the comment field";
  "stringval":"but these stay the same";

}

Re: Comments in JSON

#105

Post by jdp »

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…

JSON isn't a configuration language, it's just another data encoding format with the added benefit of being readable by humans. That and its ubiquity make it an appealing choice for stuff like ad-hoc configuration at first glance, but it's not the best choice. If you want a config language for shared human and machine consumption, use one designed for that purpose. JSON is pretty much just an encoding that is easy for humans to inspect and debug.

Re: Comments in JSON

#106

Post by adamtj »

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. "Look at me, I'm daring and _not using XML_!" Using JSON is crap design, but good engineering means sometimes picking something crappy and not wasting effort on things that don't matter in the end.

If your configuration files become both complicated and important enough that you need comments, then you should stop using JSON. If your duck tape job starts needing additional reinforcement, then you should probably just get rid of the duct tape and do it right.

If one of your requirements is a sufficiently trendy yet commentable config language, look into YAML. Also, gaffer tape. The white kind is easier to write on.

Re: Comments in JSON

#107

Post by njharman »

nonchalance wrote: post #93
wissler wrote: post #89

Earlier quoted context omitted.

"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…

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

Don't Lisp much do you?

Code is data and vice versa. Look up what the acronym JSON means sometime.

Re: Comments in JSON

#108

Post by ryanpetrich »

jerf wrote: post #68
jaredmcateer wrote: post #29

Earlier quoted context omitted.

Yes the JSON spec was designed with interoperability in mind, I don't believe Crockford claims to have invented JSON, merely discovered it. That said if you want your Static JSON objects to have comments, just pipe the JSON object through a minifier to strip comments before parsing.

He both invented and discovered it. Yes, the object literal syntax existed, but he also carefully (and IMHO correctly) specified a strict subset as well, for these interoperability reasons. For instance, Javascript is happy with {a: 1}, but that is not legal JSON. It's a very well done standard.

JSON is not actually a strict subset. Certain characters when left unescaped in a JSON string make for invalid JavaScript: http://timelessrepo.com/json-isnt-a-javascript-subset

Re: Comments in JSON

#109

Post by dragonwriter »

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 could use JSON as code, but that's somewhat silly, because there's already a superset of JSON designed for that use.

Re: Comments in JSON

#110

Post by coldtea »

pdeuchler wrote: post #97
wissler wrote: post #89

Earlier quoted context omitted.

"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…

So is all opinionated design "stupid"? I do not presume to know who you are, or what you have accomplished, but there are few people with the professional and academic background that qualify to be able to call Douglas Crockford "stupid".

>So is all opinionated design "stupid"?

He never said that.

>I do not presume to know who you are, or what you have accomplished, but there are few people with the professional and academic background that qualify to be able to call Douglas Crockford "stupid".

Why, who do you think Douglas Crockford is and what is his "academic background"? He doesn't even have a related degree. Most of his JS fame he ows to his book.

Post reply on HN