[utnick]

It is a downside, but most of the time I don't care.

If I am sending some big list many times and speed really matters, then I care, but usually I am not. Size and speed are cheap nowadays.

[BrandonM]

It's not just about the amount of markup, though, it's about the unnecessary complexity of the markup. The software that generates and parses S-expressions is much simpler than that which generates and parses XML. Of course, in Lisp, it's just

  (let ((list (read data)))
     ...)

But even in Python, you could easily hack together (not recommended) something like

  list = ", ".join(data.split())
  ...

Of course, that's not robust, but the library which is robust is much simpler than the one that requires the use of a C sax parser just to be usably fast.

If the argument is that XML is more human-readable, that is implying that it's being human-modified, and then XML creates more work since it's so verbose. If the verbosity is not an issue because it's auto-generated, that implies that it's not being read/modified by humans, and the whole point of using XML in the first place is lost. I just can't see any problem that XML solves that S-expressions didn't already solve in a simpler way.

[jamesbritt]

Do sexp, out of the box, have a standard notion of ID and IDREF, transclusion, and schema?

There's more to XML than just annoying angle braces.

[olavk]

S-expressions are nice but not superior to XML for all use cases. S-expression syntax are optimized for lists of names and numbers. XML-syntax is optimized for structured documents. Since XML is used just as much for data as for documents these days, s-expressions would perhaps be just as good as XML for a common data exchange meta format. But that train left the station a decade ago.

I suspect a reason XML catched on and s-expressions didn't (outside of the Lisp-niche) is that XML tackled difficult internationalization issues like different encodings and character sets head on.

[anamax]

And strings, I forgot strings. (For some reason, XML folk often confuse strings with sequences of atoms. They also confuse numbers and numerals.)

And numbers in different bases.

S-expressions predate unicode. However, unicode support was added in. It's not that big a deal.

[anamax]

> S-expression syntax are optimized for lists of names and numbers.

Nope. Structs, tables, vectors, and arrays all work just fine.

And there's also support for dags and circular structures.