Live data from Hacker News

JCOF: JSON-like Compact Object Format

github.com

31–40 of 69 posts

Re: JCOF: JSON-like Compact Object Format

#33

Earlier quoted context omitted.

It might on small files but it doesn't on (some) bigger ones. e.g. I dumped a Minecraft region file into JSON giving 85M. `jcof` turns this into 66M. `gzip` on the original json gives 14M for `-1` and 11M for `-9`. `zstd` also gives 11M. But because the Minecraft JSON is highly redundant, I also tried it on 84M of fake social graph data. `jcof` gave 44M, `gzip -9` gave 19M and `zstd` gave 18M. In summary, neat idea,…

JCOF and gzip are not mutex.

See https://news.ycombinator.com/item?id=32111239 where I tested gzip vs jcof vs jcof+gzip (tl;dr: you save 2M at the cost of an extra CPU intensive process)

Re: JCOF: JSON-like Compact Object Format

#34

People keep reinventing JSON trying to beat gzip, and it never beats the simplicity of gzipping JSON...

People keep trying to re-invent a human-readable, parsable, efficient, robust format that can be validated.

But "easy" wins so we keep returning to CSV and JSON. ^_^

Re: JCOF: JSON-like Compact Object Format

#36

Earlier quoted context omitted.

comets.json: JSON: 51949 bytes JCOF: 37480 bytes (0.721x) JSON ZIPED: 15178 bytes Zipped json wins again.

Now I am curious – how does zipped JCOF turn out? I know that’s not the author’s intention, but I’m curious how it compresses

It's nearly irrelevant, given that I can gzip JSON and send it to literally anything built in the last 10+ years. It's so ubiquitous now that many web servers will just accept gzipped content without even exposing that fact to the back end servers. You can get all the benefits of highly compressed JSON and never have interacted with gzip.

If it could somehow produce a significant reduction with fewer CPU cycles, there may be a really niche use case, but I don't see those often.

Re: JCOF: JSON-like Compact Object Format

#37
JSON isn't mean to be efficient, but to be a good compromise between being human readable/writable, easily generated/parsed by a machine, and familiar. CBOR and BSON make more sense, to be frank, for any use case I could think of using this in.

Re: JCOF: JSON-like Compact Object Format

#38
post #16

Earlier quoted context omitted.

While Oscar Wilde would undoubtedly have something witty to say about that, I guess it's a matter of stress: if you read it as a word and assume stress on the (invisible) first vowel, it's almost inevitable: juh-cof.

But we dont say juh sahn for JSON? Hence why Jcough seemed intuitive.

Language is not very deterministic. An unknown word can remind you of more than one other word, which can influence the way you pronounce it, certainly in English where pronunciation is so irregular. That’s not a fact of course, just a possible factor.

Re: JCOF: JSON-like Compact Object Format

#39
no offense, but this seems pointless tbh.

If I need a more compact no longer at all human readable format I can use a compact binary format. If not I can use JSON which has wide spread support.

or just use a compression (after which the difference between JSON and JCOF should be negligible)

Re: JCOF: JSON-like Compact Object Format

#40

Earlier quoted context omitted.

It might on small files but it doesn't on (some) bigger ones. e.g. I dumped a Minecraft region file into JSON giving 85M. `jcof` turns this into 66M. `gzip` on the original json gives 14M for `-1` and 11M for `-9`. `zstd` also gives 11M. But because the Minecraft JSON is highly redundant, I also tried it on 84M of fake social graph data. `jcof` gave 44M, `gzip -9` gave 19M and `zstd` gave 18M. In summary, neat idea,…

JCOF and gzip are not mutex.

You just blew my mind that “mutex” is a portmanteau of “mutually exclusive.” How have I been programming for 20 years and never realized this?
Post reply on HN