There's something magically expressive about S-expressions and processing them. For a linguistic project I was thinking about how to represent sentence syntax as data and then I came across Chomsky's phrase structure analysis[1] which parses spoken language exactly like S-expressions in LISP! It's even illustrated with parenthesis or syntax trees, just like the old SICP vids explain. The phrase structure even uses recursive definitions so processing and inflecting the content of sentences can be done with recursive functions etc, (I did it in TypeScript) like something following a design exercise out of HTDP/SICP. I think the inherent parallel between human language phrase structure and S-expressions is beautiful.
[1]: This book introduces the phrase structure in a shockingly LISP-like way. https://www.amazon.com/Grammar-Frank-Palmer/dp/B000S5VSAS
> There's something magically expressive about S-expressions and processing them.
A downside I see with S-expressions – you often end up with something like (FOO BAR BAZ), where FOO identifies the type of thing, and BAR and BAZ are parameters/slots/etc – but you have to remember the (sometimes quite arbitrary) order that BAR and BAZ go in.
Some Lisp family languages (such as Common Lisp, Clojure, Scheme with SRFI 88/89) support keywords (aka named parameters), so you can do something like (FOO :bar BAR :baz BAZ), which is considered equivalent to (FOO :baz BAZ :bar BAR). However, this is somewhat of a late development in the Lisp tradition, the status of its adoption is mixed, and (arguably) it is moving away (even if only by a little bit) from pure S-expressions. When people say "S-expressions", they normally aren't thinking of CLOS.
I think JSON's model, in which lists and objects are independent first-class entities, with distinct syntax, has something to say for it. The downside of JSON objects, is their keys are strings, not symbols, and they don't have any kind of "class slot" (some people make up conventions here, for example a reserved property name such as "$class", but those conventions are not uniform or standardised). Oh, and we don't need all those commas. I think, if I was designing a LISP-ish language, I'd have a first-class syntax for objects which used different opening and closing characters – maybe (FOO bar baz) for a list, but [FOO :BAR bar :BAZ baz] for an object.
> Extends the code-as-data paradigm to maps and vectors
Basically think of it as a better JSON with non of the issues you brought up.
See: https://github.com/edn-format/edn
And example:
> #myapp/Person {:first "Fred" :last "Mertz"}