5 ms·

> If you have been around long enough you still remember the world that was excited about XML and templating it using XSLT. As a hindsight it was a horrible wor

> If you have been around long enough you still remember the world that was excited about XML and templating it using XSLT. As a hindsight it was a horrible world. I actually really like the idea behind XSLT: machine-friendly, human-tolerable, structured data + declarative rules for turning that data into a display, or a report, or whatever else. The execution was horrible though: incredibly verbose, lots of overcomplication due to XML weirdness/asymmetries (e.g. attributes vs elements vs text, namespaces, ...); mixtures of different languages hidden inside each other (e.g. XPath hidden in attributes); etc. I would really like to see what this could look like if done in a more minimalist, lispy fashion (normal code-is-data stuff in Lisp is similar, but I think term-rewriting is a more appropriate evaluation mechanism for such rules)

pytester 8y ago
XSLT was one in a litany of domain specific languages (ant, apache rewrite rules, latex macros, etc.) that evolved towards turing completeness because that's what the problem space demanded. In most if not all of these cases an existing and well designed turing complete programming language would likely have better served them.
- astine 8y ago
  I don't see a reason that a DSL can't be Turing complete and still a better option than an existing language. If you look at old-school make files, they are little more than shell script with top level rules that you can invoke from the command line. You could theoretically just use shell script but the make scripts still simplify the task quite a bit.
- thanatropism 8y ago
  There was a post on HN a few weeks back to the effect that it's rather easy for Turing completeness to emerge accidentally. I wish I remembered more specifics so I could find it again.
  - chriswarbo 8y ago
    Was it http://beza1e1.tuxen.de/articles/accidentally_turing_complete.html http://beza1e1.tuxen.de/articles/accidentally_turing_complet... by any chance?
- hyperpallium 8y ago
  Less power means less to go wrong. Automatic checks can also be deeper in a simpler system. Your point is valid though, the power seems to end up being needed, sometimes, in some parts, in some cases. Escaping to a full language when needed seems to retain the benefits of both worlds.
- miohtama 8y ago
  I wrote a lot of XMLT in early 2000. The idea behind pure function is nice, but in practice you ended up with hundreds of mini plugins in Java or Python.
hyperpallium 8y ago
The syntactic mistake of XSLT was writing it in XML, XPath was a redeeming feature. Imagine if XPath was also written in XML... jq occupies the same role as XSLT, but for JSON. It can be used for templating but it's not quite as declarative as XSLT (you must pipe things through).
- int_19h 8y ago
  XQuery was halfway between XSLT and XPath in expressiveness - functions, loops, queries with joins etc, but no pattern matching. If it only had the latter, it'd be perfect.
- chriswarbo 8y ago
  > The syntactic mistake of XSLT was writing it in XML, XPath was a redeeming feature. Imagine if XPath was also written in XML... Yes, I didn't mean to imply that XPath itself is bad (although it also has to handle XML quirks like element/attribute/text, etc.). Rather that the reason to write XSLT as XML in the first place is that it's machine readable, we can mix and match elements from different vocabularies, etc. yet most of the heavy lifting ends up as opaque string attributes :( PS: I've done a few projects which make heavy use of jq; it's really nice, but as you say it's more of a pipeline.
- mst 8y ago
  I quite liked SXML + SXSLT back in the day (scheme syntax)
  - hyperpallium 8y ago
    It is more concise. Similarly, I was a fan of using attributes instead of text elements (with their unnecessary close tags), but eventually was won over by neatness. e.g. translating an eg from https://www.gnu.org/software/guile/manual/html_node/SXML.html https://www.gnu.org/software/guile/manual/html_node/SXML.htm... (parrot (@ (type "African Grey")) (name "Alfie")) <parrot> <type>African Grey</type> <name>Alfie</name> </parrot> It's more the one-variable-per-line pretty-printing than the syntax as such, but still.
james_s_tayler 8y ago
I find XSLT intolerable in practice. Thankfully I've only had to touch it a handful of times. I agree the idea behind it is neat but boy is it a headache.

pytester 8y ago

XSLT was one in a litany of domain specific languages (ant, apache rewrite rules, latex macros, etc.) that evolved towards turing completeness because that's what the problem space demanded. In most if not all of these cases an existing and well designed turing complete programming language would likely have better served them.

astine 8y ago
I don't see a reason that a DSL can't be Turing complete and still a better option than an existing language. If you look at old-school make files, they are little more than shell script with top level rules that you can invoke from the command line. You could theoretically just use shell script but the make scripts still simplify the task quite a bit.
thanatropism 8y ago
There was a post on HN a few weeks back to the effect that it's rather easy for Turing completeness to emerge accidentally. I wish I remembered more specifics so I could find it again.
- chriswarbo 8y ago
  Was it http://beza1e1.tuxen.de/articles/accidentally_turing_complete.html http://beza1e1.tuxen.de/articles/accidentally_turing_complet... by any chance?
hyperpallium 8y ago
Less power means less to go wrong. Automatic checks can also be deeper in a simpler system. Your point is valid though, the power seems to end up being needed, sometimes, in some parts, in some cases. Escaping to a full language when needed seems to retain the benefits of both worlds.
miohtama 8y ago
I wrote a lot of XMLT in early 2000. The idea behind pure function is nice, but in practice you ended up with hundreds of mini plugins in Java or Python.

hyperpallium 8y ago

The syntactic mistake of XSLT was writing it in XML, XPath was a redeeming feature. Imagine if XPath was also written in XML... jq occupies the same role as XSLT, but for JSON. It can be used for templating but it's not quite as declarative as XSLT (you must pipe things through).

int_19h 8y ago
XQuery was halfway between XSLT and XPath in expressiveness - functions, loops, queries with joins etc, but no pattern matching. If it only had the latter, it'd be perfect.
chriswarbo 8y ago
> The syntactic mistake of XSLT was writing it in XML, XPath was a redeeming feature. Imagine if XPath was also written in XML... Yes, I didn't mean to imply that XPath itself is bad (although it also has to handle XML quirks like element/attribute/text, etc.). Rather that the reason to write XSLT as XML in the first place is that it's machine readable, we can mix and match elements from different vocabularies, etc. yet most of the heavy lifting ends up as opaque string attributes :( PS: I've done a few projects which make heavy use of jq; it's really nice, but as you say it's more of a pipeline.
mst 8y ago
I quite liked SXML + SXSLT back in the day (scheme syntax)
- hyperpallium 8y ago
  It is more concise. Similarly, I was a fan of using attributes instead of text elements (with their unnecessary close tags), but eventually was won over by neatness. e.g. translating an eg from https://www.gnu.org/software/guile/manual/html_node/SXML.html https://www.gnu.org/software/guile/manual/html_node/SXML.htm... (parrot (@ (type "African Grey")) (name "Alfie")) <parrot> <type>African Grey</type> <name>Alfie</name> </parrot> It's more the one-variable-per-line pretty-printing than the syntax as such, but still.

james_s_tayler 8y ago

I find XSLT intolerable in practice. Thankfully I've only had to touch it a handful of times. I agree the idea behind it is neat but boy is it a headache.