▲ | aljgz 5 hours ago | |
I see the negativity in some comments, but I have to say: just because we have a format that works we don't have to suffer it's slightly annoying problems for eternity. This is a format that's very well defined, good decisions where to be flexible (quoted keys) and when to be strict (no leading zeroes, no leading plus sign, error when integer parsing can't be precise, defining all corner cases in strings). For almost all of these, I remember cases when something went wrong (or was just annoying) in another format. I admire efforts to fix things. | ||
▲ | p0nce 3 hours ago | parent | next [-] | |
Yes but. How would you express NaN or infinities or even precise floating-point (the reason hex float exist) in this format? That breaks interchange if you cannot save/restore floating-point as in the save. | ||
▲ | throwaway150 5 hours ago | parent | prev [-] | |
I admire the effort to fix things too. But this is exactly how we end up with 15 competing standards (https://xkcd.com/927/), each a little different, and no one can tell which library or package can parse which format any more. I'm also not convinced that the small usability benefits of these alternative formats outweigh the burden of stumbling across them in different projects and then having to remember which parser works with which format. If I had to choose between living with one canonical, well-established format like JSON and a jumble of 15 incompatible formats, I’d choose the single, well-established one every time. |