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

101–110 of 173 posts

Re: FracturedJson

#101

Post by Y-bar »

merelysounds wrote: post #96
Y-bar wrote: post #27

Earlier quoted context omitted.

We stopped having this problem over ten years ago when spec 1.1 was implemented. Why are people still harking on about it?

A new spec version doesn’t mean we stop having the problem. E.g. kubernetes wrote about solving this only five months ago[1] and by moving from yaml to kyaml, a yaml subset. [1]: https://kubernetes.io/blog/2025/07/28/kubernetes-v1-34-sneak...

The 1.1 spec was released about _twenty_ years ago, I explicitly used the word _implemented_ for a reason. As in: Our Yaml lib vendor had begun officially supporting that version more than ten years ago.

Re: FracturedJson

#103

Post by Etheryte »

Y-bar wrote: post #93
Etheryte wrote: post #39

Earlier quoted context omitted.

Because there's a metric ton of software out there that was built once upon a time and then that bit was never updated. I've seen this issue out in the wild across more industries than I can count.

I’m not here clanking down on Java for lacking Lambda features, the problem is that I did not update my Java environment past the 2014 version, not a problem with Java.

I think this mixes up two separate things. If you're working with Java, it's conceivable that you could probably update with some effort. If you're an aerospace engineer using software that was certified decades ago for an exorbitant amount of money, it's never going to happen. Swap for nearly any industry of your liking, since most of the world runs on legacy software by definition. A very large number of people running into issues like these are not in a position where they could solve the problem even if they wanted to.

Re: FracturedJson

#104

Post by Sohcahtoa82 »

frizlab wrote: post #8
damnitbuilds wrote: post #2

Nice. And BTW, thanks for supporting comments - the reason given for keeping comments out of standard Json is silly ( "they would be used for parsing directives" ).

Unrelated: why spaces inside the parentheses? It’s not the first time I see this, but this is incorrect!

Probably someone who writes C/C++ and formats their code that way

    if ( x == ( y + z ) * w ) {
Personally, I find it hard to read.

Re: FracturedJson

#105

Post by _pdp_ »

barishnamazov wrote: post #5

This is pretty cool, but I hope it isn't used for human-readable config files. TOML/YAML are better options for that. Git diff also can be tricky with realignment, etc. I can see potential usefulness of this is in debug mode APIs, where somehow comments are sent as well and are rendered nicely. Especially useful in game dev jsons.

Yaml works really well with LLMs (not to generate but to consume). So yes, we use it all the time in our service.

Re: FracturedJson

#106

Post by eric-p7 »

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…

Reminds me of Lite3 that was posted here not long ago:

https://github.com/fastserial/lite3

Re: FracturedJson

#108

Post by jesse__ »

I love doing this type of formatting with source code. It'll be nice when people start writing linters that format code like this
Post reply on HN