The problem is that XML maps badly to data structures in common programming lang...

wtbob · on July 31, 2016

> S-expressions are good if you work with Lisp like languages, but I don't think they're very readable if you're not into Lisp.

Take a look at https://news.ycombinator.com/item?id=12198581; I think it demonstrates how readable one dialect of S-expressions can be.

> I also can't see how they map easily into datastructures of imperative programming languages

JSON consists of numbers, strings, booleans, objects and arrays; canonical S-expressions consist of bytes and lists. I contend that one can easily encode strings, numbers and booleans alike as bytes, and both objects and arrays as lists. Consider:

    {
        "id": 1234,
        "isEnabled": true,
        "props": ["abc", 123, false],
    }

This could be encoded in canonical S-expressions as:

    (object
     (id "1234")
     (is-enabled "true")
     (props (abc "123" "false")))

Granted, one still must convert the strings "1234," "true," "123," and "false" into the expected types, but with JSON one still must check the expected types anyway; it's not that big a difference.

And I honestly think that the S-expression version is far more attractive.

zyxley · on July 31, 2016

You could do make it more like S-expressions in JS if you really wanted.

    {object: [
      {id: "1234"},
      {isEnabled: "true"},
      {props: ["abc", "123", "false"]}]}

Not quite the same, but nothing keeps you from parsing an array of key/value pairs instead of a hash.

wtbob · on Aug 1, 2016

You may not leave JSON object properties unquoted, so it'd have to read:

    {"object": [
      {"id": "1234"},
      {"isEnabled": "true"},
      {"props": ["abc", "123", "false"]}]}

So you have extraneous quotes, extraneous semicolons, extraneous commas, plus the parsing code is complicated by having to handle all of that rather than atoms & lists (that's not a strong reason, since parsing code is written once and used millions of times).

I really, really don't get the visceral opposition to S-expressions. From my perspective they're both better & simpler.

PeterisP · on July 31, 2016

There is a very big difference - "with JSON one still must check the expected types anyway" is not really true, I can deserialize an arbitrary json and I will know the difference between 123 and "123" even if I don't know what's expected or, alternatively, mixed-type values are expected.

wtbob · on Aug 1, 2016

> There is a very big difference - "with JSON one still must check the expected types anyway" is not really true, I can deserialize an arbitrary json and I will know the difference between 123 and "123" even if I don't know what's expected or, alternatively, mixed-type values are expected.

You will still need, in your code, to handle both 123 & "123" (or handle one, and error on the other). That's really no different from, in your code, parsing "123" as an integer, or throwing an error.

In JSON one must check that every value is the type one expects, or throw an error. With canonical S-expressions, one must parse that every value is the type one expects, or throw an error. There's really no difference.

If one is willing to use a Scheme or Common Lisp reader, of course, then numbers &c. are natively supported, at the expense of more quoting of strings (unless one chooses to use symbols …).

lmm · on Aug 1, 2016

> You will still need, in your code, to handle both 123 & "123" (or handle one, and error on the other). That's really no different from, in your code, parsing "123" as an integer, or throwing an error.

It is different because in the latter case you have to write your own code to do it, while in the former your library will handle it for you.

> If one is willing to use a Scheme or Common Lisp reader, of course, then numbers &c. are natively supported, at the expense of more quoting of strings (unless one chooses to use symbols …).

So this format comes in dozens of partially-incompatible variants? Lovely.