S-expressions are very nice, and have the unequalled property of being simple enough to serve as a syntax for an entire programming language, but as a data type it is at best on the level of JSON. If one were to design a new data format for pipes, I would hope one would aim a little higher than that. Going from plain text lines to JSON or sexps would simply not be worth the infrastructure retooling.
What lies above JSON or S-expressions, XML? Or some binary format?
If I had to guess, I'd say the issue with JSON and the like is how to deduce types (and the limited types available) combined with the issue of special characters in names and strings.
XML goes a long way towards fixing that, but at the cost of a lot of extra bloat. A binary format with a nicely defined header might work, but those formats tend to not be so good about inserting stuff.
There is something to be said in favor of plain text. If all solutions suck, go for the simplest and most flexible solution.
The ability to pass whole objects (which would have to be serializable) would certainly qualify as being "above" JSON and sexps, but I’m not convinced objects would be a good idea to use in this way, which is why I didn’t specifically suggest them as an alternative.
Being able to use the same syntax for code and data is no small thing. This aspect alone puts it above JSON. That, and for most LISPS, S-expressions have a broader vocabulary than JSON (symbols, complex numbers, etc.).
JSON also has hash tables (which they confusingly call “objects”), which sexps do not. One may argue that one is or isn’t slightly better than the other, but the point was that they are very close.
S-expressions can express whatever the LISP can express (like Clojure's built-in hash table syntax), or the s-exp could just pass a lambda to generate the data on-the-fly at the next step, and since the lambda itself is a list, the receiver has an easy built-in facility for inspecting/altering/extending passed-in code.
JSON is just arrays, objects, bools, numbers, strings, and null.
If you have to run “eval” on it, it’s not an s-expression. If the “eval” is implied, what you are describing is serialization of data, not actual data.
You could do what you describe with JSON too – it’s just encoding and decoding. Would you therefore be able to claim that JSON is capable of transmitting, say, tabular data? Of course not.
