Live data from Hacker News

ECMA-404: The JSON Data Interchange Format [pdf]

ecma-international.org

111–120 of 199 posts

Re: ECMA-404: The JSON Data Interchange Format [pdf]

#111

Earlier quoted context omitted.

I really don't think it's fair to say it's a terrible language. It does have some terrible, horrible parts. But it also has some wonderful, awe-inspiring, mind-blowing parts. It's just not a MOR language - you have extreme lows and awesome highs.

"wonderful, awe-inspiring, mind-blowing parts" Honest question: Such as?

closures, prototypical inheritance, the syntax for object/array literals. and I know it's not strictly part of the language, and it's deeply unfashionable to say so, but I'm quite a fan of the DOM, too.

Re: ECMA-404: The JSON Data Interchange Format [pdf]

#112
post #93

Earlier quoted context omitted.

Not really... just add a "comment" key and then ignore it when processing.

That's an ugly workaround, not a solution. It helps breed half-baked "solutions" like the "pipe through jsmin" Crockford himself suggests. Ultimately, it makes JSON unsuitable for configuration files (there are other reasons for that, to be fair, like over-verboseness)

Not necessarily. If you're naming your keys nicely, and using an easily-understandable structure, for simple config files, you shouldn't really need comments.

Re: ECMA-404: The JSON Data Interchange Format [pdf]

#113

Earlier quoted context omitted.

For large code bases, you don't break git blame by adding in new arguments. And it's one less thing to think about when editing your code: always add a comma, never worry about errors because you need to add a comma to the line above.

This is why you prepend the comma before every succeeding item in a list or map.

You've slightly improved the problem by moving it away from the last item on the list, but you've now screwed up the first item. You can no longer insert a first-item using the same format, and instead of a trailing comma bug you can get a starting comma bug.

Re: ECMA-404: The JSON Data Interchange Format [pdf]

#114

Earlier quoted context omitted.

"Pro-evil"? Wow. Is it so hard for people to realise the problem is the potential interpretation of "evil" is very open ended?

I believe that's quite the point. It makes you actually question whether what you're doing could possibly be construed as evil. Ridiculous, yes, and legally troubling, but thought provoking for sure.

I don't know how thought provoking it really is. It's so general, and the range of human opinion is so vast, that it could cover almost anything. For some people, typing up this comment on a fairly power-hungry computer, in an area where most of the electricity comes from burning coal, could be considered evil. Sitting here could be evil. Not sitting here could be evil.

Re: ECMA-404: The JSON Data Interchange Format [pdf]

#115
post #109
post #94

Earlier quoted context omitted.

Why do you manually code json?

because that is what json is for

no, that's not what json for. JSON is for exchange data between machines. We already have data interchange formats for humans, we call those 'languages'.

Re: ECMA-404: The JSON Data Interchange Format [pdf]

#116

Earlier quoted context omitted.

"wonderful, awe-inspiring, mind-blowing parts" Honest question: Such as?

closures, prototypical inheritance, the syntax for object/array literals. and I know it's not strictly part of the language, and it's deeply unfashionable to say so, but I'm quite a fan of the DOM, too.

Closures and literals are pretty basic things for many languages and very well-known.

Prototypical inheritance may have gotten much more exposure via JS, but I'm not overly impressed with it, and I hardly think it makes up for the rest of the language.

Re: ECMA-404: The JSON Data Interchange Format [pdf]

#117

Earlier quoted context omitted.

"Pro-evil"? Wow. Is it so hard for people to realise the problem is the potential interpretation of "evil" is very open ended?

I believe that's quite the point. It makes you actually question whether what you're doing could possibly be construed as evil. Ridiculous, yes, and legally troubling, but thought provoking for sure.

Not really thought provoking at all. Just opens legal issues as anyone can construe anything as evil. It's not like moral relativism is anything special or novel or needed to be brought into a software license.

As others have pointed out, this is just the license on one implementation, not the spec, so it's not really as big a deal.

Re: ECMA-404: The JSON Data Interchange Format [pdf]

#118

Earlier quoted context omitted.

"Pro-evil"? Wow. Is it so hard for people to realise the problem is the potential interpretation of "evil" is very open ended?

No, I think people understand that. They just don't care, and find it amusing that other people do care/must care. Consider it an "anti-'people who take licensing seriously' license" .

Yeah, people trying to comply with laws are just hilarious. Sigh.

Re: ECMA-404: The JSON Data Interchange Format [pdf]

#119
post #73
post #46

Earlier quoted context omitted.

What does trailing comma support get you?

It simplifies generating JSON, since you don't need a special case for the last item, and it simplifies editing it, since you don't need to do something special when adding a new item at the end. I can't see any benefit to not having it, honestly.

> It simplifies generating JSON, since you don't need a special case for the last item

In which language can't you do array.join(",")? You can even do that in Java with one of the myriad of string libraries. I haven't hand-coded joins since (at least) six or seven years.

Post reply on HN