4 ms·

> Before JSON, XML and standard binary formats, there were just CSV/TSV and random binary formats which was a bigger minefield. S-expressions predate both, are

• drawkbox 9y ago
  s-expressions are better than binary for sure but also you end up having to maintain/write parsers for front-end/back-end and more. s-expressions influenced HTML/XML creation. Anything not JSON/XML you end up with formats that don't have massive support on the client and server side and take more work to serialize/deserialize to/from, same with YAML, other formats that have more typing and rules are not as simple and do add some complexity. The big reason that JSON and even XML were so successful is that parsing from front-end to back-end and the direct use in javascript and APIs for instance is such a simple step, JSON being easier than XML but XML being easier than binary and other formats with more requirements/rules/complexity. The basic types, ease of nesting, readability used in both JSON and even XML led to systems that serialize/deserialize to it also influenced the systems to be more simple. CSV/XLS/binary/BER/DER/ASN.1 etc data exchanging all have more mines in the field than JSON and XML has more than JSON. JSON's killer feature is simplicity and forces you into more simple input/output. Simplicity is always good when it comes to exchanging data.
• djur 9y ago
  The S-expression has cleaner whitespace and field names than the JSON, which makes it harder to make an apples-to-apples comparison. But the biggest problem with that S-expression is that I don't know how to parse it. Is SGML a symbol, identifier, a quoteless string? How do I know when parsing the 'entry' field that what follows is going to be a list of key/value pairs without parsing the whole expression? Is 'see-also GML XML' parsed as a list? How do we distinguish between single element lists and scalars? Is it possible to express a list at the top level, like JSON allows? How do you express a boolean, or null? Of the problems outlined in the OP, S-expressions solve one: there's no question of how to parse trailing commas because there are no trailing commas. They do not solve questions of maximum levels of nesting. They have the same potential pitfalls with whitespace. They have exactly the same problems with parsing strings and numbers. They have the same problem with duplicated keys. My point here isn't that you can't represent JSON as S-expressions. Clearly you can. My point is that in order to match what JSON can do, you have to create rules for interpreting the S-expressions, and those rules are the hard part. Those rules, in essence, _are_ JSON; once you've written the logic to serialize the various types supported by JSON to and from S-expressions, you've implemented "JSON with parentheses and without commas".
  • eadmund 9y ago
    > Is SGML a symbol, identifier, a quoteless string? It's a sequence of bytes — a string, if you like. > How do I know when parsing the 'entry' field that what follows is going to be a list of key/value pairs without parsing the whole expression? You wouldn't, and as a parser you wouldn't need to. The thing which accepts the parsed lists of byte-sequences would need to know what to do with whatever it's given, but that's the same issue as is faced by something which accepts JSON. > Is 'see-also GML XML' parsed as a list? (see-also GML XML) is a list. > How do we distinguish between single element lists and scalars? '(single-element-list)' is a single-element list; 'scalar' is a scalar. Just like '["single-element-list"]' & '"scalar"' in JSON. > Is it possible to express a list at the top level, like JSON allows? That whole expression is a list at top level. > How do you express a boolean, or null? The same way that you represent a movie, a post or an integer: by applying some sort of meaning to a sequence of bytes. > They do not solve questions of maximum levels of nesting. They don't solve the problem of finite resources, no. It'll always be possible for someone to send one more data than one can possibly process. > They have the same potential pitfalls with whitespace. No, they don't, because Ron Rivest's canonical S-expression spec indicates exactly what is & is not whitespace. > They have exactly the same problems with parsing strings and numbers. No they don't, because they don't really have either strings or numbers: they have lists an byte-sequences. Anything else is up to the application which uses them — just like any higher meaning of JSON is up to the application which uses it. > They have the same problem with duplicated keys. No, they don't — because they don't have keys. > My point is that in order to match what JSON can do, you have to create rules for interpreting the S-expressions, and those rules are the hard part. My point is that JSON doesn't — and can't — create all the necessary rules, and that trying to do so is a mistake, because applications do not have mutually-compatible interpretations of data. One application may treat JSON numbers as 64-bit integers, another as 32-bit floats. One application may need to hash object cryptographically, and thus specify an ordering for object properties; another may not care. Every useful application will need to do more than just parse JSON into the equivalent data structure in memory: it needs to validate it & then work with it, which almost certainly means converting that JSON-like data structure into an application-specific data structure. The key, IMHO, is to punt on specifying all of that for everyone for all time and instead to let each application specify its protocol as necessary. The reason to use S-expressions for that is that they are structured and capable of representing anything. Ultimately, we can do more by doing less. JSON is seductive, but it'll ultimately leave one disappointed. It does a lot, but not enough. S-expressions do enough to let you do the rest.
• tannhaeuser 9y ago
  Just wanted to share that you can technically parse S-expressions using SGML. [1]: https://web.archive.org/web/19991008044801/http://www.blnz.com/lml/ https://web.archive.org/web/19991008044801/http://www.blnz.c...