Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Unintuitive JSON Parsing

nullprogram.com

Post reply on HN
Print view View original

71–77 of 77 posts

Re: Unintuitive JSON Parsing

#71

Post by averros »

JSON is abomination (and I know what I'm talking about, having implemented hi-perf streaming JSON parser for a well-known database). JSON deserves to be exterminated with extreme prejudice.

Where do I start? Like, the author of JSON never heard of integers longer than 53 bits? Or about infinite and NaN values for floating points? Than +0. and -0. are NOT THE SAME? Or about the need to have a canonical order of fields in a map? Oh, and don't forget lack of anything resembling timestamps. The error recovery is full of ambiguities, not easily resolved.

But the real horror of JSON is decimal representation mandated for binary fractions. It's a data exchange format which BY DESIGN silently mangles data.

Re: Unintuitive JSON Parsing

#72

Post by magicalhippo »

peterwwillis wrote: post #65
magicalhippo wrote: post #46

Earlier quoted context omitted.

I've been programming for 30 years, across many different languages from assembler and up. I've yet to use octals for any code. What am I missing out on? Why are they included in modern languages like JS?

If you ever want to count in base-8 (or a subset), or have an abbreviated form of binary, or pack decimal in a way that's easier to reason, or divide a number in half (down to 1) without getting fractions, or represent file permissions (a grouping of four octals). Is JS a modern language? It was made 24 years ago as a prototype for a scripting language loosely mimicing Java. Presumably octals would have been still us…

> If you ever want to count in base-8 (or a subset)

So far I haven't ever had that need it seems.

> have an abbreviated form of binary

Yeah ok, but why octal over hex? After all, hex maps better to the underlying storage.

> pack decimal in a way that's easier to reason

How'd that work? I know about BCD but I don't see how octal improves the situation, being base-8.

> divide a number in half (down to 1) without getting fractions

Huh?

> represent file permissions (a grouping of four octals)

Ok, I get that for C and such, but how often do you do that in JS?

> Is JS a modern language?

Compared to C, where octal support is understandable, I'd say yes.

Re: Unintuitive JSON Parsing

#73

Post by y4mi »

esfandia wrote: post #52
ufo wrote: post #18

Earlier quoted context omitted.

Usually, if there is a token that is a prefix of another the longer token wins. For example, in Javascript --x is parsed as the decrement operator instead of as two unary "-" operators.

With that rule, the "leading zero" problem in the article should have been caught properly as well. Why wasn't it? edit: I guess because "01" isn't a valid token.

"--" is also invalid in json, as it doesn't deal with mutations.

The parent was talking about js.

Re: Unintuitive JSON Parsing

#74

Post by imtringued »

gregmac wrote: post #66
microcolonel wrote: post #34

Earlier quoted context omitted.

When your inputs are from real JSON emitters, it is silly to even have error handling other than rejection. Helpful error messages for humans writing JSON is a special use case, not "the main differentiator" marking an "excellent [parser]". Exposing a "helpful" JSON parser to the internet is a bad idea, and probably a waste of electricity, since the error messages will likely go into a black hole. An "excellent" pars…

> When your inputs are from real JSON emitters, it is silly to even have error handling other than rejection. I'm guessing from this that a "real JSON emitter" is one that perfectly implements the JSON spec and has absolutely zero bugs? Does such a thing exist? > Exposing a "helpful" JSON parser to the internet is a bad idea, and probably a waste of electricity, since the error messages will likely go into a black ho…

>I'm guessing from this that a "real JSON emitter" is one that perfectly implements the JSON spec and has absolutely zero bugs? Does such a thing exist?

If the JSON Serializer has a bug then the only option is to fix the bug instead of adding a human that is manually correcting mistakes in the generated JSON output. The only purpose of human friendly errors is because humans are involved and since they aren't we have to unnecessarily add them to make your complaint valid. (Don't tell me you're feeding the human friendly error messages into an ML algorithm. That's just bullshit.) The days of office workers doing pointless busywork of this type are long gone.

Re: Unintuitive JSON Parsing

#75

Post by gregmac »

imtringued wrote: post #74
gregmac wrote: post #66

Earlier quoted context omitted.

> When your inputs are from real JSON emitters, it is silly to even have error handling other than rejection. I'm guessing from this that a "real JSON emitter" is one that perfectly implements the JSON spec and has absolutely zero bugs? Does such a thing exist? > Exposing a "helpful" JSON parser to the internet is a bad idea, and probably a waste of electricity, since the error messages will likely go into a black ho…

>I'm guessing from this that a "real JSON emitter" is one that perfectly implements the JSON spec and has absolutely zero bugs? Does such a thing exist? If the JSON Serializer has a bug then the only option is to fix the bug instead of adding a human that is manually correcting mistakes in the generated JSON output. The only purpose of human friendly errors is because humans are involved and since they aren't we have…

I'm not sure why you're saying humans aren't involved. Humans are writing the code (often with bugs), troubleshooting operations, supporting other humans using the software, and identifying and fixing bugs.

While I agree fixing the bug is the only option, it still has to be identified first. A bug that is based on data can appear to happen "randomly" and if the error is a useless one like the OP or even just "invalid JSON" it can take a long time before isolating the exact cause (especially if it's not obvious which piece of software is even the source of the error), and in that time end users, support and ops people lose trust in the system.

Re: Unintuitive JSON Parsing

#76

Post by microcolonel »

gregmac wrote: post #75
imtringued wrote: post #74

Earlier quoted context omitted.

>I'm guessing from this that a "real JSON emitter" is one that perfectly implements the JSON spec and has absolutely zero bugs? Does such a thing exist? If the JSON Serializer has a bug then the only option is to fix the bug instead of adding a human that is manually correcting mistakes in the generated JSON output. The only purpose of human friendly errors is because humans are involved and since they aren't we have…

I'm not sure why you're saying humans aren't involved. Humans are writing the code (often with bugs), troubleshooting operations, supporting other humans using the software, and identifying and fixing bugs. While I agree fixing the bug is the only option, it still has to be identified first. A bug that is based on data can appear to happen "randomly" and if the error is a useless one like the OP or even just "invalid…

If your environment's JSON serializer is fundamentally capable of producing invalid JSON in normal operation, you probably have a lot of other problems to overcome.

Re: Unintuitive JSON Parsing

#77

Post by perl4ever »

microcolonel wrote: post #76
gregmac wrote: post #75

Earlier quoted context omitted.

I'm not sure why you're saying humans aren't involved. Humans are writing the code (often with bugs), troubleshooting operations, supporting other humans using the software, and identifying and fixing bugs. While I agree fixing the bug is the only option, it still has to be identified first. A bug that is based on data can appear to happen "randomly" and if the error is a useless one like the OP or even just "invalid…

If your environment's JSON serializer is fundamentally capable of producing invalid JSON in normal operation, you probably have a lot of other problems to overcome.

Hey look, it's Maurice Wilkes...
Post reply on HN