Hacker News Reader

Comment by CWIZO | Hacker News Reader

> Coming from this direction, the addition of commas feels like an evil plan to have more syntax errors, with no obvious benefit

It helps to learn your history before you criticise something and claim it is useless.

JSON is the way it is mainly because it is just JavaScript and that meant that every browser in the world already supported it before JSON was even invented. It is THE reason why it is as popular as it is.

View on HN

It was just a matter of:

    var myObject = eval(httpResponseBody)

Of course, this is vulnerable to all kinds of issues so we got JSON parser, and later JSON became part of the Web API.

I remember the infinite loops stuffed into JSON results to prevent this sort of thing.

If it is "just JavaScript", why the lack of comments ?

Comments were intentionally excluded to prevent the use of parsing directives.

(Sadly, Crockford's post about this reasoning was on Google Plus and is no longer online.)

{comment : "your comments here!"}

{copyright comment : "JSON doesn't require/enforce specific comments is a good thing" }

{comments : "JSON parser is not an 'comment' editor! }

Don't know whtat the google plus article covered, but Crockfor's comments : https://www.linkedin.com/posts/douglas-crockford-724600109_j...

I think the spirit is forbidding creative developers from using the comments to include active content. I know people who if struggling with datetime encoding, would add a "// DATEFMT: YYYY-D-M" comment and be on their merry way, making it incompatible with all other JSON parsers.

What might be nice is to add a prefix to key name that indicates 'this is a 'internal document reference', skip this unless quests to parser to not ignore. Would allow for describing encoding method(s) used. date format comments being very helpful. Technically, can do by just dropping by key name.

Why comment on a format vs. adding an associated "key""format" with format information. aka date : 25.02.04 date-fmt : YY.DD.MM

Jokingly, why does Javascript have the semi-colon “;”

There are a few minor, uncommon edge cases, probably only encountered by minimisers, where automatic semicolon insertion may cause unintentional behaviour, so semicolons are required. One of the specs; https://262.ecma-international.org/7.0/#sec-rules-of-automat... (link from an earlier comment of like) spells it out in detail.

While these edge cases are fairly rare in everyday JS codebases, Typescript adds some, e.g. inline type casts for function calls:

    const foo = someFn()
    (foo as Bar).doSomething()

I really with the semicolon weren't optional. Its "I'll take my best guess" parsing is maddening.

One that keeps killing me is:

    return
        (complicated-multi-line-computation)

Since it can put a semicolon at the end of the first line, it does. Which means the return value is undefined, and the rest of it is just some code that it never actually reaches. A linter will fix that, but I find the usual fix a bit ugly:

    return (
        (complicated multi line computation)
    )

The author knows that. Fourth paragraph.

If the author knows that, why even bother with writing a whole "what should have been" article? It could not have been any oher way.

Yet another example/demo of "Use the source!"

There is nothing in the JSON spec that prohibits pre/post non-json parsing search / replace 'end of line' marker with one or more commas.

JSON spec just tells one what the JSON parser expects, not what the end user needs/wants. (GPT-JSON not withstanding)

> > ... feels like an evil plan to have more syntax errors, with no obvious benefit

> ... before you criticise something and claim it is useless.

These 2 statements feel quite far apart.

Relying on the inherent JavaScript compatibility hack has caused as many problems as it has solved. Plus, the additional of trailing commas made a mess of things once more, forcing developers to let go of the direct compatibility with many versions of JavaScript engines and redirecting them to specialised JSON APIs instead.

The easy solution would be to go the JavaScript route and make commas optional, like JavaScript does with semicolons. You could even introduce vague and easily forgotten rules about commas being inserted between oneliner dictionaries.

I think the question "why" is easily answered, but "why should it still" is more difficult.

The easy solution is horrible solution. Pretty much all the projects set semicolons as mandatory for a reason.

Making things optional means you'd end up with the csv standard mess on json, let's not!

Reply on news.ycombinator.com