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

171–180 of 180 posts

Re: Comments in JSON

#171

Post by IanCal »

dnautics wrote: post #165
IanCal wrote: post #157

Earlier quoted context omitted.

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?

I would agree it's very hackey and probably not a good idea since the spec is liable to change. But I wouldn't be sad if the spec were changed to allow for this, or to allow for comments.

> I would agree it's very hackey and probably not a good idea since the spec is liable to change

Well it's not really about the spec changing, the spec doesn't have a defined behaviour for duplicate keys.

> But I wouldn't be sad if the spec were changed to allow for this, or to allow for comments.

I don't think duplicate keys should be allowed, but I've no strong feelings on comments. I don't think there's any real need for them though.

Re: Comments in JSON

#172

Post by TeMPOraL »

defen wrote: post #164
TeMPOraL wrote: post #160

Earlier quoted context omitted.

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

I understand all this. Like many people, I've written programs in C++ templates. But I think we're talking past each other because you want to make a pedantic point. I'm using the words as they are generally understood, not in a technical computer science way. I'm talking about first-level stuff, not metaprogramming. Let me give you some questions to ponder: - Is the text of Hamlet code? - Was it code as soon as Shak…

> But I think we're talking past each other because you want to make a pedantic point.

I guess that's true.

The flavour of "code vs. data" discussion in this thread was one of representation formats. You could argue that when looking at works of art from past centuries one should immediately say "data!" [0]. But in case of JSON, a format suspiciously almost identical to Lisp in structure, one needs to be careful in saying "it's for data, not for code".

Actually, I'm not sure what kind of point I'm trying to make, as the more I think of it, the more examples of things that are borderline code/data come to my mind. Cooking recipes is the obvious candidate, but think about e.g. music notation - it clearly feels more like "code" than "data".

I feel that you could define a kind of difference between "code" and "data" other than in intent, something that could put bitmaps into the "data" category, and a typical function into "code" category, but I can't really articulate it. Maybe there's some mathematical way to describe it, but it's definitely a blurry criterion. But when we're discussing technology, I think it's harmful to pretend that there's a real difference. Between configuration files looking like half-baked Lisp listings and "declarative style" C++ that looks like datasets with superfluous curly braces, I think it's wrong to even try to draw a line.

[0] - there's a caveat though. "How to Read a Book" by Mortimer Adler[1] discussess briefly how the task of a poet is to carefully chose words that evoke particular emotional reactions in readers. It very much sounds like scripting the emotional side of the human brain.

[1] - http://en.wikipedia.org/wiki/How_to_Read_a_Book

Re: Comments in JSON

#173

Post by TeMPOraL »

DominikR wrote: post #102
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…

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.

> still JSON was designed as data format

While I don't think that comments belong in JSON, I don't agree JSON is designed as "data and not code" format. Trees of tokens are actually the natural format for writing code (also known as Abstract Syntax Trees, AST) and the data/code distinction is really, really blury when those two meet together, so it's only to be expected that people will end up coding in JSON (what are the 'build definition' files for various build tools / package managers, if not very simple programs)?

Re: Comments in JSON

#174

Post by TeMPOraL »

nonchalance wrote: post #170
lispm wrote: post #169

Earlier quoted context omitted.

Lisp programmers write code so that data is code.

Lisp: "All code is data" That's not the question. "All data is code" is not the same statement. In a different context: "All apples are fruit" may be true but that doesn't imply "all fruit are apples"

Lisp programmers think "data is code and code is data, both are the same thing and they're interchangeable". As it happens to actually be. I point to GEB [0] for more detailed discussion of this, but let me give you a few examples which point out that the distinction between code and data is mostly meaningless.

- Ant build descriptions that look suprisingly like executable Lisp code if you replace " ... " with "(tag ...)".

- Musical notation which is obviously code for humans playing instruments (it even has loops, I think, AFAIR from my music lessons; don't know about conditionals; if it has them, maybe it's Turing-complete? (ETA it would seem it is[3])).

- Windows Metafile format for bitmap and vector graphics which is basically a serialized list of WinAPI calls [1].

- "fa;sldjfsaldf" - the "not code, just data" example from [2] that happens to be "a Teco program that creates a new buffer, copies the old buffer and the time of day into it, searches and then selectively deletes". Oh, and it's also "a brainfuck program that does nothing, and a vi program to jump to the second "a" forwards and replace it with the string "ldjfsaldf"".

[0] - https://en.wikipedia.org/wiki/G%C3%B6del,_Escher,_Bach

[1] - http://en.wikipedia.org/wiki/Windows_Metafile

[2] - http://www.c2.com/cgi-bin/wiki?DataAndCodeAreNotTheSameThing

[3] - http://programmers.stackexchange.com/questions/136085/is-mus...

Re: Comments in JSON

#175

Post by dragonwriter »

TeMPOraL wrote: post #174
nonchalance wrote: post #170

Earlier quoted context omitted.

Lisp: "All code is data" That's not the question. "All data is code" is not the same statement. In a different context: "All apples are fruit" may be true but that doesn't imply "all fruit are apples"

Lisp programmers think "data is code and code is data, both are the same thing and they're interchangeable". As it happens to actually be. I point to GEB [0] for more detailed discussion of this, but let me give you a few examples which point out that the distinction between code and data is mostly meaningless. - Ant build descriptions that look suprisingly like executable Lisp code if you replace " ... " with "(tag…

> Musical notation which is obviously code for humans playing instruments (it even has loops, I think, AFAIR from my music lessons; don't know about conditionals; if it has them, maybe it's Turing-complete?).

The are conditionals in standard music notation, at least ones that involve "executing different code" based on the value of a loop counter.

Re: Comments in JSON

#176

Post by dnautics »

IanCal wrote: post #171
dnautics wrote: post #165

Earlier quoted context omitted.

I would agree it's very hackey and probably not a good idea since the spec is liable to change. But I wouldn't be sad if the spec were changed to allow for this, or to allow for comments.

> I would agree it's very hackey and probably not a good idea since the spec is liable to change Well it's not really about the spec changing, the spec doesn't have a defined behaviour for duplicate keys. > But I wouldn't be sad if the spec were changed to allow for this, or to allow for comments. I don't think duplicate keys should be allowed, but I've no strong feelings on comments. I don't think there's any real n…

I'm biased, back in the BeOS -> Haiku days, I was wanting some sort of configuration textfile that would neatly be able to be parsed into a BArchive object (and presumably transmitted into a BMessage). XML was all the rage at the time, so I wrote for myself a sort of XML-ish format, but I never contributed it to the tree. I learned the problems with XMLs (should it be an attribute or an innerText?). I wanted something with a bracket notation, but JSON had not been discovered by crockford yet, if it had been I would have gotten more involved and tried to have it be adopted.

Re: Comments in JSON

#178

Post by dehora »

krapp wrote: post #112
ygra wrote: post #61

Earlier quoted context omitted.

And JSON was often “parsed” with eval().

That's not really a problem with JSON though is it? Anything you run through eval() is a disaster in the making. Maybe the problem is that people are trying to make data formats too powerful, and too many things seem to be creeping towards Turing completeness that don't need to be. I think parsers for JSON and Yaml, INI etc should be designed in such a way as to make it impossible to assign anything like an object, c…

It is a problem with JSON in the sense that it's a JavaScript subset, 'in practice' - modulo the Unicode support that goes beyond JavaScript. So it's to be expected that eval() will be used as a convenience by developers, ignoring the security implication that comes will eval() hoisting full JavaScript.

The way to have avoided the issue would have been for JSON to have a grammar that broke eval(). But one could argue the ability to pass JSON into eval() to get JavaScript is one of the reasons JSON became popular to begin with.

Re: Comments in JSON

#179

Post by dehora »

wmil wrote: post #46
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 neat, but library developers have a history of writing unsafe YAML parsers. There's the famous Rails vulnerability due to YAML. Python needed to add 'yaml.safe_load'. YAML is a little too rich. It's always one poorly thought out convenience feature away from disaster.

Agreed.

YAML is easy to type, even with the whitespace. So is INI. And as verbose as XML is, it's easier, ime, to type than JSON. Of those four, JSON is the hardest to write by hand; certainly it's the one I make most mistakes with, to extent I have a particular technique for writing it out (prefixing the commas). As a result JSON as a config file format is tedious, verbose, and error prone; its sweet spot is a machine interchange format that a human can debug/read if needed.

Re: Comments in JSON

#180

Post by IanCal »

TeMPOraL wrote: post #159
IanCal wrote: post #129

Earlier quoted context omitted.

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.

So any indented text file would be considered code?
Post reply on HN