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

The Order of the JSON

blog.almaer.com

Post reply on HN
Print view View original

51–60 of 126 posts

Re: The Order of the JSON

#51

Post by hobofan »

cypressious wrote: post #45

I have written an app for the menu of my university's canteen. The JSON API that I used returned the meals as fields of a document where the order of the fields was the actual display order. It took me a while to even find an implementation of a JSON parser that keeps the order of the fields.

I would assume that any decent JSON parser has at least the option to keep the order of the fields. Especially for CLI tools that automatically add fields to a JSON file thats usually edited by a user e.g. package.json, I feel that it's absolutely crucial.

Re: The Order of the JSON

#52

Post by deathanatos »

Ididntdothis wrote: post #5

This sounds very familiar. A lot of companies are full of people who have no curiosity and no ability to think for themselves. I have seen it multiple times where someone claimed a change is impossible or takes insane effort. Then you have someone competent look at it and you have a solution in an hour. I think stuff likes this is the real price of not hiring really good people.

I worked with one of these once. Incredibly frustrating. You could propose a change that would have massive impact on the maintainability and readability of the codebase. "But how can you know if it will work?" Like, we tested it. We used our brains to evaluate potential likely side-effects and vetted the relevant portions of the code. We ran in it development environments for a month. I am not some junior dev trying to fix the world, I am arguing what I believe to be a pragmatic, narrowly-targeted, risk-balanced change with positive expected outcome. But that wouldn't satisfy him, it had to be completely risk-free.

(And if things did go wrong, we had pretty much the ultimate backup plan: revert!)

It gradually dawned on me that his own code (which I thought was generally low quality) did generally reflect his values here: it was write-once. Any subsequent change just layer on and patched around.

> I think stuff likes this is the real price of not hiring really good people.

Yup. And I still am not sure I'm good enough to tell them apart in hiring without asking questions that the candidate will just tell you what you want to hear.

Re: The Order of the JSON

#53

Post by diroussel »

jrochkind1 wrote: post #12

How were they going to charge him for 9 FTEs for 6 months to uncheck a checkbox?

Be cause the checkbox only removed the validation error. Who know what other errors will be encountered when the cobol can't read the incoming messages, which might or might not be in the right order?

Re: The Order of the JSON

#54

Post by al_form2000 »

"Why would you care what order we were sending the name value pairs for this?" The article makes it sound like it's somehow IBM's fault. However, questions about preserving order in hashes/associative arrays/maps/whatchamacallit span at least thirty years. Some applications of the format even demand it (e.g. ansible uses YAML - a superset of JSON - or even straight JSON for it playbooks; emitting them out of order is not an option).

Every time the issue surfaces it elicits a large amount of eye rolling among the cognoscenti. However, I'm a firm believer in the idea that recurring demands from the user base need to be addressed, rather then mocked. The coding community appears to me notably tone deaf on this.

'Course anybody can use to send a JSON map in the desired order, except the parser on the other hand will blissfully disregard it. Or you can devise any ordered solution on both ends, which will leave you outside of the accepted standard and open you up to the situation described in the article (where the requirement may well have been frivolous).

I can remember very few - if any - instances of somebody implying that the standard should somehow make room for this kind of scenarios. The standard reply was "use a different format" or "change the requirement". (Somehow remembers me of people asking what can one do to have whitespace-preserving XML, and at least one amusing story about that)

Re: The Order of the JSON

#55

Post by quickthrower2 »

bjoli wrote: post #30
Ididntdothis wrote: post #5

This sounds very familiar. A lot of companies are full of people who have no curiosity and no ability to think for themselves. I have seen it multiple times where someone claimed a change is impossible or takes insane effort. Then you have someone competent look at it and you have a solution in an hour. I think stuff likes this is the real price of not hiring really good people.

I had the same thing happen to me lately, but I was at the stupid end. I am not a programmer by profession, so it matters very little to me, but I had been struggling to produce a correct solution to a seemingly simple problem (writing a macro to allow definitions in expression context in r6rs scheme). My solution worked but had the side-effect rewriting obviously bad syntax into correct one and not in a good way. I…

You had trouble writing a scheme macro? I think most pro software developers would struggle to! I don’t think this is dumb.

Re: The Order of the JSON

#56

Post by al_form2000 »

shortercode wrote: post #35
lilyball wrote: post #27

The tweet at the top of the article says > This so far out of the spec it makes my ankles hurt. This is not in fact out of spec. The JSON spec does not define semantics here but instead quite explicitly leaves it up to the JSON processor and data interchange spec for what to do about ordering of objects.

If the objects are not guaranteed to be in order, I would always consider them unordered. You could if both the producer and consumer are ordered, but as the OP noted this can cause problems later on and for no good reason. I'd use an array of key-value tuples if I wanted it to be ordered.

Uh, "no good reason" in this case means "I unchecked the box and nothing bad happened right away" which amounts to shallow analysis, to put it gently.

Re: The Order of the JSON

#57

Post by moby_click »

blattimwind wrote: post #47
jwilliams wrote: post #46

(I've used both DataPower and COBOL - I've got a healthy respect for robust, long-lived legacy systems). I must admit I was scratching my head on this. The JSON spec might not specify order, but the serialized JSON is ordered by nature. JWT needs it for example (and I'd assume many signature models). Or you might have a caching layer that needs it. Maybe unchecking this causes the legacy backend to get hammered? Ther…

> JWT needs it for example (and I'd assume many signature models) You almost never need canonical representations for signing things. I would even say that if you need a canonical representation to sign your things, then that is a design smell of your cryptographic protocol.

You don't _need_ canonical representations for signing, but then you can't let go of the representation used for computing the signature. What is the argument against a requirement to only sign canonical data?

Re: The Order of the JSON

#58

Post by viraptor »

al_form2000 wrote: post #54

"Why would you care what order we were sending the name value pairs for this?" The article makes it sound like it's somehow IBM's fault. However, questions about preserving order in hashes/associative arrays/maps/whatchamacallit span at least thirty years. Some applications of the format even demand it (e.g. ansible uses YAML - a superset of JSON - or even straight JSON for it playbooks; emitting them out of order is…

Json has a perfectly fine order preserving key-value map:

    [["Key1", "value1"], ["key2", ...
You just need to deserialise it into a specific collection on the receiver. It's within standards and there are no weird parser issues.

Re: The Order of the JSON

#59

Post by [deleted] »

Ididntdothis wrote: post #5

This sounds very familiar. A lot of companies are full of people who have no curiosity and no ability to think for themselves. I have seen it multiple times where someone claimed a change is impossible or takes insane effort. Then you have someone competent look at it and you have a solution in an hour. I think stuff likes this is the real price of not hiring really good people.

[deleted]
Post reply on HN