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

41–50 of 173 posts

Re: FracturedJson

#41

Post by ljm »

DJBunnies wrote: post #28

While I wish JSON formally supported comments, it seems more sensible (compatible) to just nest them inside of a keyed list or object as strings. { foo: "bar", ans: 42, comments: { ans: "Douglas Adams" } }

Personally, I think if your JSON needs comments then it's probably for config or something the user is expected to edit themselves, and at that point you have better options than plain JSON and adding commentary to the actual payload.

If it's purely for machine consumption then I suspect you might be describing a schema and there are also tools for that.

Re: FracturedJson

#42

Post by rafabulsing »

odyssey7 wrote: post #35
simonw wrote: post #17

It looks like there are two maintained implementations of this at the moment - one in C# https://github.com/j-brooke/FracturedJson/wiki/.NET-Library and another in TypeScript/JavaScript https://github.com/j-brooke/FracturedJsonJs . They each have their own test suite. There's an older pure Python version but it's no longer maintained - the author of that recently replaced it with a Python library wrapping the C# code…

This is a good idea, though I don’t think it would guarantee program equivalence beyond the test cases.

Well yeah, but then any discrepancies that are found can be discussed (to decide which of the behaviors is the expected one) and then added as a test for all existing and future implementations.

Re: FracturedJson

#43

Post by pimlottc »

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.

You can (usually) specify the input file name as “-“ (single hyphen) to read from stdin

Re: FracturedJson

#44

Post by simonw »

odyssey7 wrote: post #35
simonw wrote: post #17

It looks like there are two maintained implementations of this at the moment - one in C# https://github.com/j-brooke/FracturedJson/wiki/.NET-Library and another in TypeScript/JavaScript https://github.com/j-brooke/FracturedJsonJs . They each have their own test suite. There's an older pure Python version but it's no longer maintained - the author of that recently replaced it with a Python library wrapping the C# code…

This is a good idea, though I don’t think it would guarantee program equivalence beyond the test cases.

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.

Re: FracturedJson

#45

Post by boxed »

simonw wrote: post #44
odyssey7 wrote: post #35

Earlier quoted context omitted.

This is a good idea, though I don’t think it would guarantee program equivalence beyond the test cases.

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.

Re: FracturedJson

#46

Post by marxisttemp »

airstrike wrote: post #26
actionfromafar wrote: post #21

Earlier quoted context omitted.

Yaml is the worst. Humans and LLMs alike get it wrong. I used to laugh at XML but Yaml made me look at XML wistfully. Yaml - just say Norway

The Norway issue is a bit blown out of proportion seeing as the country should really be a string `"no"` rather than the `no` value

YAML strings should really require delimiters rather than being context-dependent.

Re: FracturedJson

#47

Post by marxisttemp »

thechao wrote: post #14
frizlab wrote: post #9

This is interesting. I’d very much like to see a code formatter do that kind of thing; currently formatters are pretty much inflexible, which makes getting structure out of a formatted code sometimes hard.

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.

Re: FracturedJson

#48

Post by kstenerud »

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't do.

Re: FracturedJson

#49

Post by nurumaik »

vitaelabitur wrote: post #40

I tokenized these and they seem to use around 20% less tokens than the original JSONs. Which makes me think a schema like this might optimize latency and costs in constrained LLM decoding. I know that LLMs are very familiar with JSON, and choosing uncommon schemas just to reduce tokens hurts semantic performance. But a schema that is sufficiently JSON-like probably won't disrupt model path/patterns that much and prev…

Minified json would use even less tokens

Re: FracturedJson

#50

Post by pixl97 »

mystifyingpoi wrote: post #23
Xymist wrote: post #6

Earlier quoted context omitted.

It's a pretty sensible policy, really. Corollary to Hyrum's Law - do not permit your API to have any behaviours, useful or otherwise, which someone might depend on but which aren't part of your design goals. For programmers in particular, who are sodding munchkins and cannot be trusted not to do something clever but unintended just because it solves a problem for them, that means aggressively hamstringing everything.…

> A flathead screwdriver should bend like rubber if someone tries to use it as a prybar. While I admire his design goals, people will just work around it in a pinch by adding a "comment" or "_comment" or "_comment_${random_uuid}", simply because they want to do the job they need. If your screwdriver bends like a rubber when prying, damn it, I'll just put a screw next to it, so it thinks it is used for driving screws…

And we wonder why people are calling for licensed professional software engineers.
Post reply on HN