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

101–110 of 126 posts

Re: The Order of the JSON

#101

Post by bjoli »

quickthrower2 wrote: post #55
bjoli wrote: post #30

Earlier quoted context omitted.

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.

I do not have any problems writing macros (in fact, I recently finished my guile scheme version of rackets for loops) It is just that the macro I wrote did a lot more work than it had to, and led to weird syntax behaviour. I didn't delimit what I was trying to do. John over in #guile put me on the right track.

Re: The Order of the JSON

#102

Post by beached_whale »

couchand wrote: post #28
beached_whale wrote: post #24

Earlier quoted context omitted.

It's an interesting problem. So if all the parser does it put them into a variant like structure, sure whatever. But when you go to put them into the reified data types you would be wasting a lot of resources to parse JSON to an intermediary data structure and then request the members. I parse them directly to their final classes. So I was left with a choice and both have a cost. Parse the json in-order of the file a…

Is your parser general-purpose? Is it template-based? Is the performance variance due only to the impact on the processor's cache or are there other factors? Is the code open-source, maybe I could just look myself?

It is template based so that each types JSON parser is statically known and to give the compiler more opportunity to optimize. https://github.com/beached/daw_json_link

I haven't had a chance to look at why yet.

Re: The Order of the JSON

#103

Post by Someone »

dtech wrote: post #87
Someone wrote: post #49

Next installment: how flipping an innocuous switch introduced a subtle bug that was silent for years and cost us millions. You can’t just flip that switch, run ”a client to post the JSON to that instance” , see that test “worked just fine” , and call it a day. The POST might just store it, for later processing to wreak havoc (say by ignoring a value that isn’t in the expected place in the JSON), or only rarely seen J…

How do you justify ever changing anything with that attitude? This change made parsing more lenient which is generally considered fine [1] and made the software actually follow the spec, since it specifies object entries are unordered. [1] https://en.wikipedia.org/wiki/Robustness_principle

”This change made parsing more lenient”

How do you know? It makes the outermost layer of the system accept more liberal in what it accepts, but that doesn’t guarantee that the inner layers can handle that more liberal content.

For example, the code may assume that “” always is the first node in the json. If you start sending “” instead, things may go fine until you get two customers who share a car.

”and made the software actually follow the spec”

How do you know? The spec of this piece of software may state it has a JSON-like API that requires the “” to be the first node in every request.

And yes, most of its code may handle that change fine, but it only takes one piece of code to break things.

”How do you justify ever changing anything with that attitude?”

In the case of ”a service running IBM DataPower Gateway which sat on top of WebSphere which sat on top of the COBOL.” where ”Much of the system was so old that it was hard to find anyone who knew how it actually worked, and it’s maintenance had been outsourced ”: very carefully.

This change may have been fine, but you have to check that.

Re: The Order of the JSON

#104

Post by dagw »

ghc wrote: post #96
ken wrote: post #94

Earlier quoted context omitted.

In other words: why GUI configuration systems should allow comments, just like text config files do.

Underrated idea. Never seen this, but I would kill for the ability to add comments to configuration settings or even log changes with commit messages.

I'm pretty sure it was OS X Server (or might have been NeXT) that had a feature where you could save the state of the server config GUI to a text file that you could check into source control and/or back up. Then you could load that file to get the GUI back to its previous state after you screwed something up.

Re: The Order of the JSON

#105

Post by kec »

dagw wrote: post #104
ghc wrote: post #96

Earlier quoted context omitted.

Underrated idea. Never seen this, but I would kill for the ability to add comments to configuration settings or even log changes with commit messages.

I'm pretty sure it was OS X Server (or might have been NeXT) that had a feature where you could save the state of the server config GUI to a text file that you could check into source control and/or back up. Then you could load that file to get the GUI back to its previous state after you screwed something up.

It’s a next/macOS idiom to save user settings in the program’s defaults domain, which is a key value store backed by plist.

Re: The Order of the JSON

#106

Post by al_form2000 »

viraptor wrote: post #77
al_form2000 wrote: post #71

Earlier quoted context omitted.

That's a way. A way that, IMHO, vastly diminishes its expressive power on the reader's side, which I do not consider a very good thing. Most solutions to the issue are of this nature. Consider serialized JSON already has a natural ordering, which is thrown away for some reason (probably parsing convenience).

> which is thrown away for some reason (probably parsing convenience). It's got nothing to do with parsing. The json comes from JavaScript syntax, where objects represent unordered mapping. Json naturally does the same. If you want expressive power for reading, json is very poor in comparison to pretty much everything else. Just use it for simple serialisation.

Granted, it came from there, but that was back in the days of map=eval(json) and they're gone. There is nothing in json the format (as opposed to json the language construct) to impose the unordered behavior.(Or, for that matters, the 'no comments' bit).

Re: The Order of the JSON

#107

Post by Ididntdothis »

Frost1x wrote: post #78
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.

All problems are easy when you already have the solution or pieces to build the solution. Real world problems vary wildly and you may find someone who can solve one problem trivially while they struggle on something else that seems simple. This condescending perspective on problem solving is part of the problem with this entire industry and ultimately turns people into tools for disposal by businesses.

I didn’t want to be condescending although my comment sounds like that. Usually I give people the benefit of doubt but I just see a lot of people who are really not interested in the job. This seems to happen a lot when a lot of stuff is outsourced so no one is owning anything. People who want to solve problems usually leave and you are left with paper pushers who schedule a lot of meetings and offshore developers who don’t know anything about the history of the project.

Re: The Order of the JSON

#108

Post by nlawalker »

dec0dedab0de wrote: post #91
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 think stuff likes this is the real price of not hiring really good people. I think stuff like this is why decent developers don't become "really good" when working in these environments. If you have a culture of letting people figure things out, and forgiving mistakes, then you'll end up with better engineers. On the other hand if you have a culture of protecting "territory", and blame then you'll get 6 months for…

I think it's less about forgiving mistakes than it is about having the ability to recognize the nature and scale of problems and distinguish between appropriate and inappropriate potential solutions. That ability gets lost in layers of management, and the people who are tasked with rewarding the folks that actually create the solutions often don't have it.

Re: The Order of the JSON

#109

Post by diskotek »

cntlzw wrote: post #80
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…

Justgoogled DataPower, out of curiosity, and I found XML Accelerator XA35. I did not know there is HARDWARE for XML PROCESSING! Blows my mind.

Yep, back in the SOAP days we used to have a lot of XML flying around that would need to be converted into one format or another via XSLT. You can certainly run XSLT on a piece of XML in your own code, but having a dedicated piece of hardware do it for you with a slick GUI was always an easy sell for IBM to management.

Re: The Order of the JSON

#110

Post by adrianmsmith »

al_form2000 wrote: post #106
viraptor wrote: post #77

Earlier quoted context omitted.

> which is thrown away for some reason (probably parsing convenience). It's got nothing to do with parsing. The json comes from JavaScript syntax, where objects represent unordered mapping. Json naturally does the same. If you want expressive power for reading, json is very poor in comparison to pretty much everything else. Just use it for simple serialisation.

Granted, it came from there, but that was back in the days of map=eval(json) and they're gone. There is nothing in json the format (as opposed to json the language construct) to impose the unordered behavior.(Or, for that matters, the 'no comments' bit).

> There is nothing in json the format [..] to impose the unordered behavior

That's not true. The spec at http://www.json.org/ says "An object is an unordered set of name/value pairs".

Post reply on HN