Okay...
> Lisp (and XML) have a uniform syntax.
.. ookay. The rest of the arguments, and the conclusion, can then be equally applied to XML, specifically the:
> I maintain that Common Lisp is the gold standard of DX for macros
Does (s)he also maintain that XML is the gold standard of DX for macros? I guess that'd mean XSLT?
...
Or the article is just trying to be too clever for its own good.
XML and Lisp both have uniformity. What you can express in Lisp, you can express in XML. That's formally true.
But once you've seen S-expressions, XML is so verbose that you want to throw up. You could do what Lisp does in XML, but your fingers would fall off from all the typing, and your eyes would glaze over from reading all the verbiage. You'd fall asleep before you got to the point.
It's really hard to overstate how disgustingly ugly XML is after you've seen the same thing done in S-expressions. I knew XML, and then I learned what S-expressions are (though I don't program in Lisp), and the next time I saw XML I was shocked at how ugly, tedious, and verbose it was.
So, yes, they're equivalent, and no, they're not. The verbosity matters, and it kills the usefulness of XML as a programming language. You could do it, but nobody wants to.
Unless you mean to say you can easily parse XML if you're using an XML parser library, in which case you can just as easily parse any other language using its parser: for example Python using its `ast` module.
XSLT is amazing. And XSLT scripts are really hard to read - just like Lisp is (at least, it is to me).
Xslt itself is complete trash.
- developing an entirely new language in XML was a meh idea, but it was severely lacking making using it difficult unless you were allowed to extend it via custom functions and elements
- the template-as-transform and template-as-function confusion was completely unnecessary and made it much harder to learn and grok than necessary
- but the worst mistake by far was the impliciteness and confusion of `.`, the thing is verbose as all hell, the implicit passing and transformation of the context was completely unwarranted, not unlike Perl’s magical side-effect unless you’re deep in the sauce it makes the entire thing a lot worse, and with even less payout given the general verbosity of XSLT and XML (in perl all the magic provides amazingly terse CLI commands, it’s just a shame people then used that in perl files)
Trying to debug some XSLT right now, every implementation processes the script differently, have reached the point of just declaring that it is broken and using something else.
I should be writing Common Lisp, I get paid for that.
Heh! I haven't touched XSLT for decades. I can't remember it enough to discuss its strengths and weaknesses; all I can remember (weaknesses) was that it dealt badly with namespaces. I think it was invented before XML namespaces came along, and the terseness of XSLT became a horrible mess in the face of namespaces.
I remember being told in about 1996 that XML was the future; the guy that told me was my boss, who was a manager, not a techie. We worked for a document company, and in that sense I think he was right. So I put a fair bit of effort into learning to use XSLT to translate XML data notation into HTML presentation notation.
XML never made the grade as a document notation, and literally nobody I knew wanted to know anything about XSLT.
But yeah, XSLT was a lot like regular expressions - pretty much a write-only notation. Hmm - I just realised that I'm using the past tense, as if it was my dead uncle or something.
I remember now. XSLT was indeed crap, all XML syntactic sugar. But the "XSLT" expressions were XPath, which existed before XSLT came along, and it's XPath that had no support for namespaces. And it's XPath that was concise, and ressembled regexes, and shared with regexes the write-only property.
[Edit] So it's XPath that I think was amazing. Unfortunately it was bound to XML, which wasn't amazing.