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

FracturedJson

github.com

Post reply on HN
Print view View original

71–80 of 173 posts

Re: FracturedJson

#71

Post by ramraj07 »

whoamii wrote: post #65

Love the spirit, but the attack-plans example IMO looks worse with this formatting. I don’t love the horizontal scrolling through properties of an object.

I dont know if you spend a fraction of your life scrolling vertically through megabyte sizes json files, but if something can reduce the height of the file thats welcome. We dont need to read every single line fro left to right, we just need to quickly browse through the entire file. If a line in this format is longer than fits the screen, its likely we dont need to know whats in the cut off right corner anyway.

Re: FracturedJson

#73

Post by wizzwizz4 »

boxed wrote: post #45
simonw wrote: post #44

Earlier quoted context omitted.

Depends on how comprehensive the test suite is. And OK it's not equivalent to a formal proof, but passing 1,000+ tests that cover every aspect of the specification is pretty close from a practical perspective, especially for a visual formatting tool.

With mutation testing you can guarantee that all the behavior in the code is tested.

You can guarantee that all the cases in the code are tested. That doesn't necessarily mean that all the behaviour is tested. If two implementations use very different approaches, which happen to have different behaviour on the Mersenne primes (for deep mathematical reasons), but one of them special-cases byte values using a lookup table generated from the other, you wouldn't expect mutation testing to catch the discrepancy. Each implementation is still the local optimum as far as passing tests is concerned, and the mutation test harness wouldn't know that "disable the small integer cache" is the kind of mutation that shouldn't affect whether tests pass.

There are only 8 32-bit Mersenne primes, 4 of which are byte-valued. Fuzzing might catch the bug, if it happened to hit one of the four other 32-bit Mersenne primes (which, in many fuzzers, is more likely than a uniform distribution would suggest), but I'm sure you can imagine situations where it wouldn't.

Re: FracturedJson

#75

Post by CamouflagedKiwi »

miguelbemartin wrote: post #70

Is JSON a format that needs improvement for human readability? I think there are much better ways to present data to users, and JSON is a format that should be used to transfer data from system to system.

I think yes? I fairly often find that I have something in JSON, which probably is from some system to system comms, and I'm trying to read it. Once it's not trivially small I often pipe it through jq or python -m json.tool or whatever, I like the idea of something that just does a better job of that.

Re: FracturedJson

#76

Post by btown »

miguelbemartin wrote: post #70

Is JSON a format that needs improvement for human readability? I think there are much better ways to present data to users, and JSON is a format that should be used to transfer data from system to system.

If you're reaching for a tool like this, it's because you don't have a well-defined schema and corresponding dedicated visualization; you're looking at some arbitrary internal or insufficiently-documented transfer-level data with nested structure, perhaps in the midst of a debug breakpoint, and need a quick and concise visualization without the ability (or time) to add substantial code into the running runtime. Especially if you're working on integration code with third parties, it's common to come across this situation daily.

Re: FracturedJson

#77

Post by esrauch »

kstenerud wrote: post #48

This is great! The more human-readable, the better! I've also been working in the other direction, making JSON more machine-readable: https://github.com/kstenerud/bonjson/ It has EXACTLY the same capabilities and limitations as JSON, so it works as a drop-in replacement that's 35x faster for a machine to read and write. No extra types. No extra features. Anything JSON can do, it can do. Anything JSON can't do, it can…

This is very interesting, though the limitations for 'security' reasons seem somewhat surprising to me compared to the claim "Anything JSON can do, it can do. Anything JSON can't do, it can't do.".

Simplest example, "a\u0000b" is a perfectly valid and in-bounds JSON string that valid JSON data sets may have in it. Doesn't it end up falling short of 'Anything JSON can do, it can do" to refuse to serialize that string?

Re: FracturedJson

#78

Post by CamouflagedKiwi »

I really like this, I think I'd find it useful fairly often and I like the idea of just making something that I use irregularly but not that rarely a bit better.

But then I found it's in C#. And apparently the CLI app isn't even published any more (apparently nobody wanted it? Surprises me but ok). Anyway, I don't think I want this enough to install .NET to get it, so that's that. But I'd have liked a version in Go or Rust or whatever.

Re: FracturedJson

#79

Post by kerblang »

I made a silly groovy script called "mommyjson" that doesn't try to preserve JSON formatting but just focuses on giving you the parentage (thus the name) including array indexes, object names, etc., all on the same line, so that when you find something, you know exactly where it is semantically. Not gonna claim that everybody should use it or that it cures insomnia cancer & hangnails, but feel free to borrow it:

https://github.com/zaboople/bin/blob/master/mommyjson.groovy

(btw I would happily upvote a python port, since groovy is not so popular)

Re: FracturedJson

#80

Post by kreco »

kstenerud wrote: post #68
kreco wrote: post #63

Earlier quoted context omitted.

Can you tell me what was the context that lead you to create this? Unrelated JSON experience: I worked on a serializer which save/load json files as well as binary file (using a common interface). From my own use case I found JSON to be restrictive for no benefit (because I don't use it in a Javascript ecosystem) So I change the json format into something way more lax (optional comma, optional colon, optional quotes,…

Basically, for better or worse JSON is here to stay. It exists in all standard libraries. Swift's codec system revolves around it (it only handles types that are compatible with JSON). It sucks, but we're stuck with JSON. So the idea here is to make it suck a little less by stopping all this insane text processing for data that never ever meets a human directly. The progression I envisage is: 1. Dev reaches for JSON…

Thanks for the details!
Post reply on HN