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

61–70 of 173 posts

Re: FracturedJson

#61

Post by pona-a »

marxisttemp wrote: post #47
thechao wrote: post #14

Earlier quoted context omitted.

I just built a C++ formatter that does this (owned by my employee, unfortunately). There's really only two formatting objects: tab-aligned tables, and single line rows. Both objects also support a right-floating column/tab aligned "//" comment. Both objects desugar to a sequence of segments (lines). The result is that you can freely mix expression/assignment blocks & statements. Things like switch-case blocks & macro…

You built it, but your employee owns it? That sounds highly unusual.

Auto corrected employer?

Re: FracturedJson

#62

Post by jtbayly »

marxisttemp wrote: post #47
thechao wrote: post #14

Earlier quoted context omitted.

I just built a C++ formatter that does this (owned by my employee, unfortunately). There's really only two formatting objects: tab-aligned tables, and single line rows. Both objects also support a right-floating column/tab aligned "//" comment. Both objects desugar to a sequence of segments (lines). The result is that you can freely mix expression/assignment blocks & statements. Things like switch-case blocks & macro…

You built it, but your employee owns it? That sounds highly unusual.

Probably a single-letter typo. Makes complete sense if changed to “employer.”

Re: FracturedJson

#63

Post by kreco »

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…

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, multi line string, comments).

I wish we would stop pretending JSON to be a good human-readable format outside of where it make sense and we would have a standard alternative for those non-json-centric case.

I know a lot of format already exists but none really took off so far.

Re: FracturedJson

#64

Post by ruuda »

polshaw wrote: post #4

Is there an option for it to read the contents from a pipe? that's by far my biggest use for the jq app.

RCL (https://github.com/ruuda/rcl) pretty-prints its output by default. Pipe to `rcl e` to pretty-print RCL (which has slightly lighter key-value syntax, good if you only want to inspect it), while `rcl je` produces json output.

It doesn’t align tables like FracturedJson, but it does format values on a single line where possible. The pretty printer is based on the classic A Prettier Printer by Philip Wadler; the algorithm is quite elegant. Any value will be formatted wide if it fits the target width, otherwise tall.

Re: FracturedJson

#65

Post by whoamii »

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.

Re: FracturedJson

#66

Post by esrauch »

odyssey7 wrote: post #58
boxed wrote: post #45

Earlier quoted context omitted.

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

UC Berkeley: “Top-level functional equivalence requires that, for any possible set of inputs x, the two pieces of code produce the same output. … testing, or input-output (I/O) equivalence, is the default correctness metric used by the community. … It is infeasible to guarantee full top-level functional equivalence (i.e., equivalence for any value of x) with testing since this would require testing on a number of inp…

In practice mutation fuzz testers are able to whitebox see where branches are in the underlying code, with a differential fuzz test under that approach its generally able to fuzz over test cases that go over all branches.

So I think under some computer science theory case for arbitrary functions its not possible, but for the actual shape of behavior in question from this library I think its realistic that a decent corpus of 'real' examples and then differential fuzzing would give you more confidence that anyone has in nearly any program's correctness here on real Earth.

Re: FracturedJson

#67

Post by [deleted] »

__MatrixMan__ wrote: post #60

When I want something more readable than json I usually use nushell. The syntax is almost the same and you can just pipe through "from json" and "to json" to convert: https://gist.github.com/MatrixManAtYrService/9d25fddc15b2494... What I like about fractured json is the middle ground between too-sparse pretty printing, and too-compact non-pretty printing, nu doesn't give me that by default. One thing that neither fra…

[deleted]

Re: FracturedJson

#68

Post by kstenerud »

kreco wrote: post #63
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…

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 because it's easy and ubiquitous.

2. Dev switches to BONJSON because it's more efficient and requires no changes to their code other than changing the codec library.

3. Dev switches to a sane format after the complexity of their app reaches a certain level where a substantial code change is warranted.

Re: FracturedJson

#69

Post by kstenerud »

imiric wrote: post #52
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…

That's neat, but I'm much more intrigued by your Concise Encoding project[1]. I see that it only has a single Go reference implementation that hasn't been updated in 3 years. Is the project still relevant? Thanks for sharing your work! [1]: https://concise-encoding.org/

Thanks!

I'm actually having second thoughts with Concise Encoding. It's gotten very big with all the features it has, which makes it less likely to be adopted (people don't like new things).

I've been toying around with a less ambitious format called ORB: https://github.com/kstenerud/orb

It's essentially an extension of BONJSON (so it can read BONJSON documents natively) that adds extra types and features.

I'm still trying to decide what types will actually be of use in the real world... CE's graph type is cool, but if nobody uses it...

Re: FracturedJson

#70

Post by miguelbemartin »

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.
Post reply on HN