> 1) s-expressions also have native symbols whereas JSON has only strings, This is inconsistent with the claim that s-exprs are better because of their simplic

> 1) s-expressions also have native symbols whereas JSON has only strings, This is inconsistent with the claim that s-exprs are better because of their simplicity. Having two very similar string-like things is unnecessarily complex for little (no?) benefit in return. 2) > it is trivial to extend standard s-expression syntax to include a native dictionary serialization Sure, and when you do you get something at about the level of complexity of JSON, so it's not clear what the value proposition is here. > JSON is also very profligate with its use of punctuation, with tons of unnecessary commas and colons all over the place. So I stand by my initial characterization. JSON uses a richer set of delimiters, which provides: 1. Greater brevity. Basic information theory says that it takes fewer characters to encode a given piece of data if your character set is larger. 2. Some level of redundancy. This isn't necessary for data transmission for JSON, but it does make it much easier for parsers to provide good localized error reporting. 3. Easier visual parsing. Most humans have functional eyeballs connected to optical processing neurons dedicated to detecting different shapes. Using characters with a greater variety of shapes to encode structure takes advantage of that. Don't get me wrong, I like Lisps and s-exprs. But it seems like any time any notation comes up for discussion, a lisper appears to claim how s-exprs are clearly superior. This despite the fact that that notation is decades older than almost every other syntax out there and yet still lost the popularity contest.