> Here's one thing that stood out to me in particular: you could encode formatted text in a way that was pretty easy to read even without formatting:
> (Here is a sentence with (i some words) (b emphasized) in (i (b different)) ways.)
That's feels a little like XML, just without attributes and untyped end-tags.
I've never really understood the hate for XML and the preference for stuff like JSON. I'm a little biased towards XML because my company uses it heavily and I got very familiar with it early in my career, but it seems to make good trade offs for most use-cases where you'd want to use structured text.
> That's feels a little like XML, just without attributes
Attributes:
(p :class 'center'
(div ...))
> and untyped end-tags.
The end tags are implied by the start tag. Why do you need an end tag? It's just another way to mess up. The following situation is not possible using S-Expressions:
> The end tags are implied by the start tag. Why do you need an end tag? It's just another way to mess up.
It helps with legibility and error-checking of hand-authored documents (at least in documents with varied tags). It doesn't look like fun to figure out where to insert something in a pages-long document with sections that like like ))))))))))))).
It's not another way to mess up, it's another way to make sure you wrote what you meant.
> It doesn't look like fun to figure out where to insert something in a pages-long document with sections that like like ))))))))))))).
What kind of editor doesn't support jumping between braces? The version of Vi that shipped with 2BSD in 1979, supports that feature[0]. Both Gedit and Notepad++ highlight matching braces. Sure, if you're doing your editing in Notepad, you might have a problem, but pretty much every other editor either highlights, supports jumping between them, or both.
The implementation of XML is a total overcomplicated disaster in many languages (cough cough Java cough cough). The design and implementation of XML namespaces has all the hallmarks of design-by-committee (where everyone in the committee is an "Enterprise Architect'), but in practice I can't tell you the number of times I've wanted to murder the masochists that overcomplicated namespaces. Don't even get me started on the total shit-show that is XML Schema.
Want another example of how XML sucks, just look at all the "XML Canonicalizations" that are necessary in the XML Signature spec because there is so much ambiguity when it comes to the canonical form of a document in XML.
Basically, the early '00s were kind of a wasteland of all these overcomplicated "Enterprise" specs (I feel like the "Java Pet Store" EJB example perfectly highlights the insanity of that period - layers and layers of unnecessary complexity, and BTW your performance is complete shit), and XML is a bit part of that before the industry as a whole realized how unnecessary a lot of that complexity is.
> the industry as a whole realized how unnecessary a lot of that complexity is
The industry didn't, new players did and backed new simpler tech. But that tech itself has, as a result of the same forces in the industry that haven't gone anywhere (and in many cases have some good reasons), progressively had much of the same complication attached to it that XML once had.
> (Here is a sentence with (i some words) (b emphasized) in (i (b different)) ways.)
That's feels a little like XML, just without attributes and untyped end-tags.
I've never really understood the hate for XML and the preference for stuff like JSON. I'm a little biased towards XML because my company uses it heavily and I got very familiar with it early in my career, but it seems to make good trade offs for most use-cases where you'd want to use structured text.