You may as well make this argument against human speech. We need secure transport, not gibberish protocols.

That is the license on just one of dozens, perhaps hundreds of JSON implementations. It has nothing at all to do with standardization of the format.

> that have no problems in sharing their comment on G+ publicly

Specially now that giving in to G+ means showing up on ads.

Alex

I took it as sarcasm. The "for everything" was the tell.

This is what I do, but it basically just has the effect of making the first item special instead of the last. That's usually better in practice, though.

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.

This seems to only move the problem to the first item instead of the last one, not solve it.

The current versions of json.js and json2.js do not have the "evil" license clause. See my other comment:

https://news.ycombinator.com/item?id=6534318

json.org/license

Look at the HTML. The "unicode variant" is rendered differently because the code tells the browser to render it differently, not because it's a different character.

    <span style="font-size:125%"><span class="Unicode">\</span></span>

Join doesn't help to stream to JSON from a database cursor. Unless you buffer the response first which is pretty horrid.

If I could down-vote this lazy, drive-by, language bashing I would. Back up 'so messed up' or keep comments like this to yourself, they don't help the discussion.

I do use a real parser, but it is not possible for JSON-P.

    callback(JSON.parse('{ "key":"value" }'))

~22% of China still uses IE6: http://www.ie6countdown.com/

Developing nations have a tendency to not use the latest and greatest. If reaching them is important for you/your product then you have to keep tracking this stuff.

IE10, IE11 in non-standards mode also don't accept trailing commas. I don't care if you accept trailing commas, but dear god, never emit them.

They don't, it's just convenient to make their point. Pretty much any new technology isn't directly compatible with old technology.

You could have used yaml.

... The irony of yaml being human and version control friendly but including massive amounts of serialization mechanism vs. json being for data exchange and having extremely rudimentary serialization features aside.

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

It's not just a matter of being ridiculous, it's a matter of being unenforceable and impossible to comply with. If I created an open source project that used a "no evil" library then how am I supposed to restrict the actions of my users? How do we even define "evil" (which has no legal definition)?

That last bit is the tough one. Some people define homosexuality as evil, others define it with things like women going to school. DC obviously isn't that extreme, but he's using a term in a legal setting that can be defined by different people in completely different ways. This makes it so no business can use this code, and even things like open source projects should be extremely weary.

What this essentially did was allow Douglas Crockford to claim that he open sourced his code while actually keeping it closed and forcing people to go through him if they actually wanted to legally use it. While I'm sure plenty of people use it regardless, there's nothing preventing DC from simply stepping in and forcing them to stop. If he had used a real open source license that would be impossible, but as it stands all he has to do is walk over and say "I consider that evil" and you need to rip his library out.

This isn't just hypothetical. I had to remove code from an open source project because of this. It's why I wrote JShrink, as an open source replacement for the JSMin libary. https://github.com/tedivm/JShrink

As Richelieu said "Give me six lines written by the most honourable of men, and I will find an excuse in them to hang him."

I pay US taxes and the US government kills people around the world. They also subsidise farmers which puts others around the world at a disadvantage contributing to poorer economic circumstances for them. The US incarcerates a large number of people. If the project benefited me or anyone else paying US taxes, then hasn't it benefited the US government, and hence evil?

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.

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.

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

It is easy to create a json-schema by conversion in current json. How about { scheme: {}, instance: {} } ?

That's pretty ugly in practice.

A better solution is to use YAML for things like configuration files. It's more pleasant for a human than JSON would be even if it supported comments, and there are nice parsing libraries available for every popular language.

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)

Yes, that solution OBVIOUSLY removes the need to spend an extra minute adding comments to the spec.

Also, I hope, trailing commas and binary types.

That's such a terrible response. "Use JSON, but then use another parser first." Sorta defeats the purpose.

The reasoning is also incredibly short-sighted.

That's the syntax equivalent of removing guardrails from a dangerous mountain pass to scare drivers into slowing down.

This is probably going to sound like asking someone to catch sunlight in a teacup, but wouldn't it have been more productive to stress the importance of syntax adherence and consistency rather than remove it altogether? There's really nothing stopping someone from abusing the rest of JSON for silly things so leaving comments out seems a bit redundant.

That's pretty laughable. What exactly prevents people from putting parsing directives in a special object key or list entry at the beginning of the file?

I would say that Javascript is not too bad a language because it has those nice parts. But overall, it's still a language that feels weird given all the bad parts.

I still don't get around how `this` can be so broken.

"wonderful, awe-inspiring, mind-blowing parts"

Honest question: Such as?

You can use CORS [1] on browsers that support it. [2] You really should use it if at all possible given your application's constraints, so you don't have to abuse GET requests and can use a JSON parser.

[1] http://en.m.wikipedia.org/wiki/Cross-origin_resource_sharing

[2] http://caniuse.com/cors

> There could be ActiveX controls and such which can't be ported to Chrome/Firefox without money.

South Korea is a huge example of this. When online banking first came to market, the only way to do it legally in South Korea was through ActiveX controls embedded in Internet Explorer because they had specific encryption requirements in the 1990s versus what IE or other browsers supported natively.

Even as recent as last year [1] it was a big deal in elections, with at least one candidate promising to end the legal requirements and allow banks to enter the modern age of browsers.

[1] http://blogs.wsj.com/korearealtime/2012/11/13/ahn-pledges-to...

Don't they have another browser around for dealing with the rest of the world though? It's not like many modern sites are going to render correctly on IE6 these days...

Yeah. On the other hand, I find YAML much better for this kind of thing. JSON is readable and writable by hand, but it's not terribly nice.

> It comes at somebody's expense.

Bullshit. You are not entitled to any particular piece of software, not a single thing is taken from you when you find a software license intolerable. So something isn't licensed how you like... so what? Negotiate new terms, or move on with your life and use something else.

Bitching that something is 'Do no evil' licensed so that you cannot use it is no better than bitching that something is GPLv3'd so you cannot use it, or something is only licensed under proprietary licenses so you cannot use it.

People getting upset over licenses that render software unenjoyable to themselves is the sort of entitled bullshit that makes me want to seek out the most obnoxious license possible. Somebody should make a AGPLv3/Do no Evil hybrid license and write some mildly useful piece of software to use it for, then refuse to duel-license for any earthly fee. That should make some people squirm.

fair enough; JS introduced me to closures, so I'm a bit biased.

Because their workers do go view Facebook. If that's a market you need to target, you need to make it work with IE6.

(There's also the whole "they get infected with everything under the sun and make the rest of us deal with them", but that's not a visual issue.)

I think JSON being a subset of yaml is one of THE biggest mistakes YAML made, second only to making YAML a serialization format.

In this discussion I have tried to disagree like a gentleman: to be polite and respectful while making a case for something I believe to be true.

In return, you have sworn at me, called my argument "a pathetic dodge" and "entitled to the absurd," and came very close to putting words in my mouth with the North Korean strawman.

That makes it difficult to have a polite discussion, but I do want to clarify one thing.

I didn't say that Crockford was responsible for the economic cost of the old json.js license. Of course he had every right to release his code under any license he chose.

I'm simply saying that there was a cost, compared with the situation that would have existed had the code been originally released with a standard MIT license. People spent time and money that they wouldn't have if that had been the case.

Since "cost" seems to be a loaded word here, let me put it another way. It should be clear that there would have been a benefit to the world if the original json.js, JSMin, etc. had used a standard MIT license, because many more people could have used the code. That benefit was lost because of the "Evil" clause.

And, to his credit, I think Crockford eventually realized this when he re-released the code with a pure public domain dedication.

Let's assume JSON supports comments, and `foo` is a JSON document with comments, what should happen here?

    JSON.stringify(JSON.parse(foo))

Presumably you'd say that it should return a plain JSON object without comments, right? However, with the current implementation this will return a JSON document that is identical to the input, modulo whitespace. This makes it easy to write tools that can, for example, increment the version number in a nodejs package.json file programatically. Doing this in a world where comments exist becomes extremely awkward or at the very least annoying, because either you have to write your own JSON parser that preserves comments, or you have to simply discard the comments when you're writing the file.

If you go with the first option, you'll inevitably run into a scenario where you have a document like this contrived example:

    {
      // this is the first ever version!
      "version": "1.0.0"
    }

And your tool goes off and increments the version number, so you end up with:

    {
      // this is the first ever version!
      "version": "2.0.0"
    }

and now your comment is a lie.

If you go with the second option, you destroy all comments whenever you write data back to the file, so they can be deemed temporary at best.

What benefit do you actually get from having comments in either scenario?

At least you can inspect the document you got with normal tools. Not so if you include comments.

And this may even encourage people into separating the data payload from the metadata, who knows?

How not? Comments with annotations would be ignored, just like a special annotation key. Either way, you'd end up with a parsed document that isn't what the original creator intended.