JSON's popularity is largely due to it's ability to easily convert to native data structures regardless of what language you happen to be using. In fact, it's less of a data encapsulation format (like XML) and more of a serialization format.
If you need to markup your data, use a markup language like XML or S-Expressions. If you need to serialize data, JSON is an excellent choice.
Did you have a point? Yes, JSON really is the best format for serializing data from any of those; for Tcl/Lisp/ML you might get lazy and use the native object format, but doing so will bite you sooner or later. For C/asm you might prefer ASN.1 but in my experience human-readability is worth the effort, and you can and should use a library rather than your own code for serialization. For Java it really is crystal clear; how else would you do it?
"Packed structs, the fat-free alternative to S-Expressions".
JSON's a nearly-perfect balance between human-readability, ease of generation/parsing, and data size. I'm not going to say that it can't get better, but I feel pretty okay saying that I don't feel a burning need to replace it.
JSON can be more compact if it simply used collapsible spaces to delimit elements within an array and key-value pairs within a dictionary. For example:
[1,[2,3],4,{"a":5,"b":6}] // 25 characters
can be rewritten as:
[1[2 3]4{"a":5 "b":6}] // 22 characters
Also, currently, JSON requires all string literals to be quoted. If we relax that constraint and only quote string literals that contain escape characters, we can achieve even more space savings. The above example can be rewritten as:
[1[2 3]4{a:5 b:6}] // 18 characters
And, in my opinion, the formatted version (with uncollapsed spaces) is just as readable as the original JSON expression:
I guess maintaining compatibility with JavaScript is more important than minor space optimizations. Also, if you really care about such things, you shouldn't use JSON in the first place (see Protocol Buffers etc.)
I not advocating for changing the JSON spec. I'm saying, as a human-readable data format, it could be more compact. Perhaps this observation can be useful to those who are designing a new language.
If this format is intended to be primarily human-readable, why should compactness be so crucial? Looking at your example, I personally think that commas increase readability by visually separating individual elements (at the expense of space they take).
This HN post is a discussion about data expressions leaner than JSON. I believe the points I've made contributes to it and I've never said such compactness is more preferable. It's merely an observation.
For small one-off test cases like these, this looks like a major improvement (28%) but in practice, the network overhead will dwarf the transmission time for 25 bytes and so a reduction to 18 bytes will be neglible. Hell, the HTTP headers alone will be much larger.
If the data set is fairly large, then the markup will contribute much less to the overall size, so the improvement will probably be more like 5-10%. After HTTP compression, the difference might be negligible.
Testing should definitely be done to see if the space saving is worth the additional parsing overhead (relaxing constraints makes the language more complicated).
Same applies to the original post, especially since the examples seem even more contrived. E.g., the author goes from <p></p> in (X)HTML to delimit a paragraph to {"format":"Paragraph","content":[]} in JSON, when one could just as easily contrive <format type="paragraph"></format> in XML versus {"p":[]} to make JSON look better.
These are all the sorts of optimisations that are only really relevant for saving bytes over the wire. Since JSON is usually used over HTTP anyway Gzip/deflate will get 90% of the reduction anyway.
Another issue is serializing binaries. Sometime you just have to pass a binary through. I wish there was a rational way to do that with JSON without having to through base64.
It's about as lispy you can get without being Lisp. The curly braces could be changed to parentheses and it would be rather trivial to write a Lisp macro to parse JSON into a nested set of associative arrays or hash maps.
In fact, if you just remove the JS ':' member notation, you can shove most of JSON into a Clojure repl already, since Clojure supports the convenient {} notation for maps.
There's no reason to make JSON look precisely like Lisp. Given that many people seem to be allergic to Lisp-style nested parentheses once they've been educated that it's Lisp, JSON offers the flexibility of constructing arbitrary sexp trees without people ever noticing they're almost generating and parsing Lisp.
When writing Lisp, it's of course sensible to use sexps instead of JSON for internal marshalling.
The same as in LISP. Code being data and data being code, an 'if' is a function that merely returns/evaluates either second or third argument based on first argument evaluation.
You're correct, the major disadvantage here is the ambiguity not just in this JSON/S-expression translation but in any possible JSON/S-expression translation. Linear arrays and key-value dictionaries in most programming languages are intuitive and meaningful and usually even have a native data type. The conversion is usually very obvious. Not so much with S-expressions.
An even simpler problem is how do you express an empty array and an empty object in S-expressions? Is it () for both?
EDIT: and what about nulls? What about strings that resemble numbers?
Yes, there are certainly more problems. I think the reason why the author thought S-expressions are more compact is because the comparison was made between formatted versions of the expressions (how they would appear in code):
["a", "b", "c"]
("a" "b" "c")
Since people generally put spaces after their commas.
As alluded to by Steve Yegge in a blog post in 2005 (http://sites.google.com/site/steveyegge2/the-emacs-problem), if you are using a Lisp, storing data as sexp means that you can define the appropriate functions, and "execute" the data to transform it however you like.
Of course if you know your dataset and can just use split (or explode) with a single delimiter (ie. |) that's always going to be much much faster and compact.
we just finally got away from XML for good and JSON is great. last thing we need is another alternative. let's try to create standards and stop coming up w/ exotic languages so we can put our efforts into proper development.
Of course.. because a simple list is of course better than arbitrary nested data structures which are then directly translated into nested object structures.
I don't understand how anyone could think that I am not aware of the original expression which I have paraphrased. As others have noted, JSON is a local optima solution to a particular group of problems. Using S-Expressions does not improve on that solution, they in fact are less of a good fit.
The same way that many misunderstand Lisp, thinking that this would be a better fit to the problems JSON addresses, misunderstands JSON (or those problems).
If you need to markup your data, use a markup language like XML or S-Expressions. If you need to serialize data, JSON is an excellent choice.