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

151–160 of 180 posts

Re: Comments in JSON

#151

Post by greenlakejake »

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.

"Data is not code"

Lisp programmers disagree.

Re: Comments in JSON

#152

Post by znmeb »

This is a celebration of programmers' ability to generate unmaintainable code by exploiting implementation dependencies. People get fired for pulling this horseshit every day!

Re: Comments in JSON

#153

Post by defen »

TeMPOraL wrote: post #150
defen wrote: post #130

Earlier quoted context omitted.

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

> unless you are willing to concede that any document format is code Because it is. Data vs. code distinction is arbitrary. The following sequence of characters: "echo 'foobar';" can be interpreted as describing a string, a series of tokens, a piece of code, a piece of music or a small icon, whatever interpretation you choose.

Yes, I understand that "code is data". This does not mean that data, in general, is code; unless you are willing to make the words completely meaningless. "Code" requires some notion of an execution platform/environment, which does not exist for arbitrary data. Here is a string: "the quick brown fox jumps over the lazy dog". Or how about "\u0000\u0000". That is not code, as generally understood.

Re: Comments in JSON

#154

Post by dragonwriter »

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.

> Data is not code

All code is data, but not all data is code.

Re: Comments in JSON

#156

Post by jfoutz »

IanCal wrote: post #64
jfoutz wrote: post #40

Earlier quoted context omitted.

There is an intrinsic order in the text though. it's up to the parser to keep clobbering a value every time a new value comes in for a given key. This seems like a bad idea. It seems heavily reliant on edge case behavior. But hey, might work well for the original author.

> it's up to the parser to keep clobbering a value every time a new value comes in for a given k Nope, parsers are perfectly in their rights to do whatever they want with multiple keys. They could read them backwards, sort them, whatever. The behaviour in the instance of multiple keys is undefined. > This seems like a bad idea. It is an astonishingly bad idea. I'm concerned by it being so high on the page. > But hey,…

I'm not so sure. I think, JSON falls back to the ecma script standard for specific details. The object initializer semantics seem to force a left to right evaluation order, in the ecma spec around page 65. I'll admit my claim was unfounded when i made it, and I only went to the spec to avoid being wrong :) If I were to implement a JSON parser, I would now feel obligated to eval in order, due to my reading of the spec.

However, I think we wholeheartedly agree, don't rely on this behavior. It is an outright strict mode error.

Re: Comments in JSON

#157

Post by IanCal »

dnautics wrote: post #148
IanCal wrote: post #136

Earlier quoted context omitted.

Then the parser might fail, and rightly so. A comment lower down shows it failing in a simple parser in go: https://news.ycombinator.com/item?id=6147478 Keys SHOULD be unique.

SHOULD != SHALL And, no, this scheme doesn't break the go parser because there isn't a typeshift between the "comment" fields, they are all strings. http://play.golang.org/p/bxcIIyAeph

Ah fair enough on the break, I was wrong there.

But if the spec says that keys SHOULD be unique, what's the behaviour when they aren't?

Re: Comments in JSON

#158

Post by krapp »

defen wrote: post #130
wissler wrote: post #98

Earlier quoted context omitted.

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

Maybe a more useful resolution to this would be to state that while all code is data, no data should be code?

You could, if you were crazy enough, write perfectly valid JSON that passed the values to eval() or a parser or what have you. And while there are encodings in JSON that don't work in javascript (i've broken JS innumerable times trying to get that to work) JS does of course allow you to add closures as an object, or an array, whatever you like, and some forms of valid JSON (if not all) are also valid javascript. So you could indeed use JSON to compute things if you wanted to.

Re: Comments in JSON

#159

Post by TeMPOraL »

IanCal wrote: post #129
wissler wrote: post #98

Earlier quoted context omitted.

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

> Is it executable? Is it turing complete?

It represents groups of more-less arbitrary tokens as trees, therefore it's a natural format for code representation as it's equivalent to an AST, therefore it's trivial to attach a basic execution context with if and lambda defined, and now it's executable and turing-complete.

Re: Comments in JSON

#160

Post by TeMPOraL »

defen wrote: post #153
TeMPOraL wrote: post #150

Earlier quoted context omitted.

> unless you are willing to concede that any document format is code Because it is. Data vs. code distinction is arbitrary. The following sequence of characters: "echo 'foobar';" can be interpreted as describing a string, a series of tokens, a piece of code, a piece of music or a small icon, whatever interpretation you choose.

Yes, I understand that "code is data". This does not mean that data, in general, is code; unless you are willing to make the words completely meaningless. "Code" requires some notion of an execution platform/environment, which does not exist for arbitrary data. Here is a string: "the quick brown fox jumps over the lazy dog". Or how about "\u0000\u0000". That is not code, as generally understood.

> "Code" requires some notion of an execution platform/environment, which does not exist for arbitrary data.

Arbitrary data don't exist without some notion of an execution (or interpretation) platform.

We tend to use "code" as a word for "commands telling some execution process what to do" and "data" as a word for "information that is meant to be transformed" but in reality this distinction is meaningless; both are fundamentally the same thing, and even our "code" vs. "data" words have blurry borders. It's very apparent when you start reading configuration files. For example, aren't Ant "configuration files" essentially programs[0]?

We all know what we usually mean in context by saying what is "code" vs. what is "data", but one has to remember, that in fact they are the same - minding it leads to insights like metaprogramming. Forgetting about it leads to dumb languages and nasty problems, and is generally not wise.

[0] - the answer is: yes, they are, see http://www.defmacro.org/ramblings/lisp.html for more.

ETA:

Questions to ponder:

- are regular expressions code, or data?

- is source written in Prolog code, or data?

Also I recommend watching http://www.youtube.com/watch?v=3kEfedtQVOY to learn how what would be data, as defined by formal grammars of some real-world protocols, can - by means of sloppy grammars and bad parser implementation - cross the threshold of Turing-completeness and become code.

Post reply on HN