4 ms·

Show HN: LCON – Ludicrously Compact Object Notation

35 points by ar-nelson 12y ago

jrvarela56 12y ago
For another compact format (exclusive to homogenous collections), checkout JSONH https://github.com/WebReflection/JSONH https://github.com/WebReflection/JSONH
Stratoscope 12y ago
Suggestion: Show both the JSON and LCON representation for the examples. This would help illustrate the difference between the formats.
- ar-nelson 12y ago
  The examples are all LCON versions of JSON documents that are out there on the web. I provided a link to the JSON before each example. Side-by-side JSON and LCON would have been nice, but you can't do floats in Markdown, and putting the JSON and LCON one after the other would have made the overly-long README even longer.
  - tel 12y ago
    Easy fix: just align the JSON examples out to the right of the LCON ones inside of your MD code blocks.
8ig8 12y ago
I love yaml because I can see it, and it (usually) makes sense. Same thing with Markdown. They both visually represent the data/content in a manner that my brain gets. This seems less obvious (or slower to digest) but I've stared at yaml and markdown for a while now.
TazeTSchnitzel 12y ago
This is compact, sure, but I have a hard time reading it. I'll stick with JSON.
- 8ig8 12y ago
  Agreed, but I'll stick with YAML.
- vhost- 12y ago
  I use json when I need to read it and messagepack when I need to send it over the network.
- ar-nelson 12y ago
  Fair enough; this seems to be the most common complaint I've seen here. There's nothing stopping you from including colons, at which point it would look exactly like YAML and CSON, but then I suppose it would have very little added value beyond YAML or CSON. For me, the killer feature is chaining one-element maps on a single line (CSON can do that too, but it doesn't have unquoted strings).
  - TazeTSchnitzel 12y ago
    While that might be convenient, it gives me a hard time comprehending what the actual structure of the map is.
granttimmerman 12y ago
For anybody who wants a little bit more structure than LCON but less clutter than JSON, I'd recommend checking out CSON. https://github.com/bevry/cson https://github.com/bevry/cson
- ar-nelson 12y ago
  This project was partially a response to CSON. CSON was almost (but not quite) good enough for my purposes, so I made something that was.
- stormbrew 12y ago
  There's a few really awkward corner cases that are much clearer in YAML (and, it seems, LCON). The most significant one, to me, is lists of objects, which are perhaps not so common in code literals (hence why people don't tend to run into it in coffeescript), but do tend to come up a lot in structured documents. In JSON they are trivial: [ { "a": "b", "c": "d" }, { "e": "f", "g": "h" }, ] In YAML also trivial and very concise: - a: b c: d - e: f g: h But in CSON (if I remember correctly), I think this looks odd and confusing by comparison: [ a: "b" c: "d" , # <- note dedent, without this it comes out as one object not two e: "f" g: "h" ] Now, in each of these you can just revert back to JSON for the difficult part, but that kind of defeats the purpose. I think YAML-the-syntax strikes a really nice balance between eliminating unnecessary punctuation and having solid structure, and LCON seems like it does as well. CSON errs too far on removing punctuation without a lot of thought put into the remaining structure. If I understand correctly, the above example in LCON would be (at most minimal): . a b c d . e f g h I actually really dislike this use of . and would like to know a rationale for it, to be honest.
  - ar-nelson 12y ago
    This was one of the reasons I designed it the way I did; I think it's a nice middle ground between YAML and CSON. As for the ., I chose it over - or * for the bullet character because I designed LCON as the syntax for a JSON-Lisp programming language, and - or * could conceivably be used as prefix operators for math functions (* [5, 6]), leaving . as the only "bullet-like" ASCII character left. The more I write LCON, the more I realize that the . can be difficult to see (though it's still not as bad as CSON's dedented commas...), so I can see your point, I'm just not sure what other character to use. In an earlier version, I had used :: as a bullet, but that ended up looking ugly.
otterley 12y ago
1. What problem are you solving with this? This really seems like a solution in search of a problem. 2. There's no emitter, just a parser. This suggests to me that there's no such thing as a canonical LCON transformation for a given input. This is bad.
- dgreensp 12y ago
  I guess the canonical JSON could be considered the canonical LCON...
- ar-nelson 12y ago
  1. It's a byproduct of another project I've been working on, a programming language that's essentially JSON Lisp. I tried both YAML and CSON as syntax for the language, and neither worked quite like I wanted. The features that make it useful for the language are: - Easy chaining of one-element maps. `a b c d` = `{a: {b: {c: d}}}}` - Only a few reserved characters, so just about anything can be an unquoted string (symbols, etc.) - Parenthesized maps 2. This is the first version. An emitter will probably be in the next version. The canonical version is essentially "JSON, but with unquoted strings where possible, no colons, and parens instead of braces".
tmityh 12y ago
If you're really looking for efficiency, take a look at baconification ;) http://pastebin.com/RGRfewBY http://pastebin.com/RGRfewBY ...comes in handy for those occasions when the courts order you to hand over some data - especially effective when printed.
vbit 12y ago
I'm waiting for ubjson http://ubjson.org http://ubjson.org which is probably the most compelling json replacement I've seen yet.
jandy 12y ago
How does this compare to JSON when gzipped? I imagine any size benefit of stripping colons and parenthesis is negligible compared to a good compression.
- ar-nelson 12y ago
  The goal is to save keystrokes, not file size.
azeirah 12y ago
I like how this is presented to be ludicrously compact, but it uses double quotes "" instead of single quotes ''. Everybody knows that single quotes take up less space!
deleted 12y ago
[deleted]

35 points by ar-nelson 12y ago

For another compact format (exclusive to homogenous collections), checkout JSONH https://github.com/WebReflection/JSONH https://github.com/WebReflection/JSONH

Stratoscope 12y ago

Suggestion: Show both the JSON and LCON representation for the examples. This would help illustrate the difference between the formats.

ar-nelson 12y ago
The examples are all LCON versions of JSON documents that are out there on the web. I provided a link to the JSON before each example. Side-by-side JSON and LCON would have been nice, but you can't do floats in Markdown, and putting the JSON and LCON one after the other would have made the overly-long README even longer.
- tel 12y ago
  Easy fix: just align the JSON examples out to the right of the LCON ones inside of your MD code blocks.

8ig8 12y ago

I love yaml because I can see it, and it (usually) makes sense. Same thing with Markdown. They both visually represent the data/content in a manner that my brain gets. This seems less obvious (or slower to digest) but I've stared at yaml and markdown for a while now.

TazeTSchnitzel 12y ago

This is compact, sure, but I have a hard time reading it. I'll stick with JSON.

8ig8 12y ago
Agreed, but I'll stick with YAML.
vhost- 12y ago
I use json when I need to read it and messagepack when I need to send it over the network.
ar-nelson 12y ago
Fair enough; this seems to be the most common complaint I've seen here. There's nothing stopping you from including colons, at which point it would look exactly like YAML and CSON, but then I suppose it would have very little added value beyond YAML or CSON. For me, the killer feature is chaining one-element maps on a single line (CSON can do that too, but it doesn't have unquoted strings).
- TazeTSchnitzel 12y ago
  While that might be convenient, it gives me a hard time comprehending what the actual structure of the map is.

granttimmerman 12y ago

For anybody who wants a little bit more structure than LCON but less clutter than JSON, I'd recommend checking out CSON. https://github.com/bevry/cson https://github.com/bevry/cson

ar-nelson 12y ago
This project was partially a response to CSON. CSON was almost (but not quite) good enough for my purposes, so I made something that was.
stormbrew 12y ago
There's a few really awkward corner cases that are much clearer in YAML (and, it seems, LCON). The most significant one, to me, is lists of objects, which are perhaps not so common in code literals (hence why people don't tend to run into it in coffeescript), but do tend to come up a lot in structured documents. In JSON they are trivial: [ { "a": "b", "c": "d" }, { "e": "f", "g": "h" }, ] In YAML also trivial and very concise: - a: b c: d - e: f g: h But in CSON (if I remember correctly), I think this looks odd and confusing by comparison: [ a: "b" c: "d" , # <- note dedent, without this it comes out as one object not two e: "f" g: "h" ] Now, in each of these you can just revert back to JSON for the difficult part, but that kind of defeats the purpose. I think YAML-the-syntax strikes a really nice balance between eliminating unnecessary punctuation and having solid structure, and LCON seems like it does as well. CSON errs too far on removing punctuation without a lot of thought put into the remaining structure. If I understand correctly, the above example in LCON would be (at most minimal): . a b c d . e f g h I actually really dislike this use of . and would like to know a rationale for it, to be honest.
- ar-nelson 12y ago
  This was one of the reasons I designed it the way I did; I think it's a nice middle ground between YAML and CSON. As for the ., I chose it over - or * for the bullet character because I designed LCON as the syntax for a JSON-Lisp programming language, and - or * could conceivably be used as prefix operators for math functions (* [5, 6]), leaving . as the only "bullet-like" ASCII character left. The more I write LCON, the more I realize that the . can be difficult to see (though it's still not as bad as CSON's dedented commas...), so I can see your point, I'm just not sure what other character to use. In an earlier version, I had used :: as a bullet, but that ended up looking ugly.

otterley 12y ago

1. What problem are you solving with this? This really seems like a solution in search of a problem. 2. There's no emitter, just a parser. This suggests to me that there's no such thing as a canonical LCON transformation for a given input. This is bad.

dgreensp 12y ago
I guess the canonical JSON could be considered the canonical LCON...
ar-nelson 12y ago
1. It's a byproduct of another project I've been working on, a programming language that's essentially JSON Lisp. I tried both YAML and CSON as syntax for the language, and neither worked quite like I wanted. The features that make it useful for the language are: - Easy chaining of one-element maps. `a b c d` = `{a: {b: {c: d}}}}` - Only a few reserved characters, so just about anything can be an unquoted string (symbols, etc.) - Parenthesized maps 2. This is the first version. An emitter will probably be in the next version. The canonical version is essentially "JSON, but with unquoted strings where possible, no colons, and parens instead of braces".

tmityh 12y ago

If you're really looking for efficiency, take a look at baconification ;) http://pastebin.com/RGRfewBY http://pastebin.com/RGRfewBY ...comes in handy for those occasions when the courts order you to hand over some data - especially effective when printed.

vbit 12y ago

I'm waiting for ubjson http://ubjson.org http://ubjson.org which is probably the most compelling json replacement I've seen yet.

jandy 12y ago

How does this compare to JSON when gzipped? I imagine any size benefit of stripping colons and parenthesis is negligible compared to a good compression.

ar-nelson 12y ago
The goal is to save keystrokes, not file size.

azeirah 12y ago

I like how this is presented to be ludicrously compact, but it uses double quotes "" instead of single quotes ''. Everybody knows that single quotes take up less space!

deleted 12y ago

[deleted]