5 ms·

> Also hard not to feel like this is reaching hard to try and recreate xslt. I was never a fan of XML, but XSLT was (is!) a killer redeeming feature of the eco

by wahern 1y ago

> Also hard not to feel like this is reaching hard to try and recreate xslt. I was never a fan of XML, but XSLT was (is!) a killer redeeming feature of the ecosystem. And it's still widely supported in browsers! It was such a shame that XML caught on where it sucked--configuration, IPC, etc--but languished where it shined, as a markup language with an amazing transformation capability in XSLT. I think where XSLT fell over was that it's a real DSL, and a declarative, pure, functional DSL at that. People like to talk a big game about DSLs, but inevitably they're simplistic syntactic exercises that don't actually abstract the underlying procedural semantics of popular host languages. When faced with a well-designed DSL that makes difficult tasks trivial... people can't be bothered to learn.

marcosdumay 1y ago
XSLT is just not a good language. Every single attempt of making XML executables (and there were many) failed badly, always for this one good reason.
wpm 1y ago
I regularly work with APIs in shell that return XML and XSLT is a goddamn super power. I adore it.
eclipticplane 1y ago
It's been a long number of years, but XUL (Mozilla/Firefox's UI layer) combined with XSLT was an incredible stack to build entire applications.
notpushkin 1y ago
I’m a big fan of XHTML (strictness is good) and feel like XSLT could be a great addition, but I hate the syntax. I’d love to build a Jinja to XSLT compiler one day. I also have a simple playground for XSLT: https://xsltbin.ale.sh/ https://xsltbin.ale.sh/
- nine_k 1y ago
  XSLT's weaknesses are the extension of its strengths. It's the first homoiconic, purely functional language that enjoyed widespread adoption among "normal" developers, not type theory wonks. But XML's syntax sucks, and so inevitably does XSLT's, because XSLT is just XML. Were it s-expressions, the syntax could suck slightly less. It was (is!) a small price to generate XSLT using XSLT, which makes XSLT very powerful and expressive if you hold it right, almost like a Lisp. This saved me a few times around year 2000 or so.
  - agumonkey 1y ago
    I barely used xslt, but as a fp head I wanted to try, the most confusing part to me were terminology / semantics / decoupling. Seemed like matching templates could be anywhere making difficult to understand the meaning of a script.
    - nine_k 1y ago
      It's sort of similar to regular pattern-matching, but sadly not built for ergonomics :(
      - agumonkey 1y ago
        The node pattern matching was ok, but as far as i can recall, there could be multiple matching patterns scattered in lots of places (a 180deg turn compared to most FP pattern matching that aim for exhaustiveness ?)
        HelloNurse 1y ago
        Exhaustiveness is only relevant for the compiler-managed pattern matching of a traditional FP type system, where you need to write an implementation (patterns that will be used at matching usage sites) for everything that your types promise. XSLT pattern matching is the plain kind: here is a pattern, look for it in the input and process every match. If some part of the input document is ignored, it's just not useful; if some part of the input document is processed several times, it's perfectly well defined.
geocar 1y ago
> but languished where it shined, as a markup language with an amazing transformation capability in XSLT I choose to look at this a little differently. An XML application using XSLT is so much better (faster load times, faster to write, easier to make correct) than a JavaScript application with a JSON api, that XML is basically a secret weapon. I only care enough that it stays in browsers, but otherwise I'd prefer nobody know about it because it means less competition on things that matter (faster load times, faster to write, fewer bugs, etc). And I've got a half-baked JavaScript-based "renderer" I can finish in case some Google VP asshat goes looking for things to delete...
echelon 1y ago
XSLT was cool. XML needs another syntax that isn't so verbose. Sort of like how OWL has XML, Manchester, Functional, and Turtle syntaxes for the same data structures. XSLT needs a Turtle-style syntax. XML in general (the data structure, not the syntax) needs a Turtle-style syntax.
Mikhail_Edoshin 1y ago
XSLT is not bad, but XML, unfortunately, is normally misused, so XSLT is tainted as it has to be a part of that misuse. The true role of XML are grammar-based notations. These occur in two places: when a human gives data to a machine and when a machine produces data for a human. This is where XML is used despite its often mentioned shortcomings; for example, many notations to describe the user interface are based on XML. This is convenient, because user interfaces are created manually. (I am not mentioning text markup, it is well known.) Yet XML was often used as a notation for machine-to-machine exchange. For example, the ONIX book description standard. Here data are moved between two computers, yet for some reason they have to form grammatically correct phrases according to a set of grammar rules. Computers do not need grammar. They do just fine with non-grammatical data, like a set of tables. It is way simpler for them; parsing or generating grammar, even explicit, is pure overhead for data exchange and is only necessary when data enters or leaves the computed pipeline. So, to your examples: configuration in XML is actually fine, but IPC is not. Configuration is written by hand, IPC happens between machines. IPC specification, on the other hand, is also a good fit for XML. That said, XML and thus XSLT has another flaw: it is way too verbose and has no good way to format it. Conciseness was an explicit no-goal but now we can say it was a mistake.
- connicpu 1y ago
  The XML abuse I've seen at work is truly horrifying. We use protobuf for most of our inter-service IPC, but for one particular team one of their customers demands the use of XML so that it can be run through some XSLT "security" filters, so they have to transform a fairly large protobuf object into XML, run it through said filters, and then convert it back to protobuf :( I weep every time I think about it.
  - taeric 1y ago
    It is probably impossible to find a tech stack that has not seen horrible abuse somewhere. :D Granted, it did seem that XML got more heavily abused than some other options for a while. I am curious if that is just a by product of when it was introduced. That or just the general proliferation of how many front end developers we have. (I hate that I am pushing that to almost be a complaint. I certainly don't mean it that way.)
froh 1y ago
here on HN I dare to out myself as a DSSSL lover, the scheme based predecessor of xslt. I still can't wrap my head around how the neat and clean dsssl syntax, a real programming language, was replaced by an xml notation for the same: for cuntional code and a framework. because semantically, that's what xslt is: a functional language with a framework, geared at transforming xml instances. but that syntax... and of course a much inferior and more obscure language than scheme underneath dsssl.
- striking 1y ago
  Why not implement a DSSSL-to-XSLT compiler?
PaulHoule 1y ago
The thing most people never got about XSLT is that it is really about production rules -- and production rules (e.g. the major path to "expert systems") are one of the most solidly rejected technologies in software engineering. I didn't understand this until I spent a few years going down a rabbit hole asking questions like "why don't people like production rules?" In the case of templating people expect to make a template with a top-down organization that looks like the output, whereas XSLT really wants you build transformations from the bottom-up. On some level the bottom-up part is clear, particularly if you want to code-generate your rules (towards the end I was writing production rules that write production rules) but what is not clear is how the parts all fit together: you can't visually tell between an XSLT that builds the structure you want vs one that doesn't. I think the most fun I ever had with XSLT was when I used an XSLT engine with user-defined procedures and had them create side effects, such as matching certain patterns in an XML document and making SQL inserts, though that was a long time ago when we were still using terrible XML parsing libraries.
stuaxo 1y ago
Its annoying that support stopped at earlier versions, it grew so much more later.

by wahern 1y ago

marcosdumay 1y ago

XSLT is just not a good language. Every single attempt of making XML executables (and there were many) failed badly, always for this one good reason.

wpm 1y ago

I regularly work with APIs in shell that return XML and XSLT is a goddamn super power. I adore it.

eclipticplane 1y ago

It's been a long number of years, but XUL (Mozilla/Firefox's UI layer) combined with XSLT was an incredible stack to build entire applications.

notpushkin 1y ago

I’m a big fan of XHTML (strictness is good) and feel like XSLT could be a great addition, but I hate the syntax. I’d love to build a Jinja to XSLT compiler one day. I also have a simple playground for XSLT: https://xsltbin.ale.sh/ https://xsltbin.ale.sh/

nine_k 1y ago
XSLT's weaknesses are the extension of its strengths. It's the first homoiconic, purely functional language that enjoyed widespread adoption among "normal" developers, not type theory wonks. But XML's syntax sucks, and so inevitably does XSLT's, because XSLT is just XML. Were it s-expressions, the syntax could suck slightly less. It was (is!) a small price to generate XSLT using XSLT, which makes XSLT very powerful and expressive if you hold it right, almost like a Lisp. This saved me a few times around year 2000 or so.
- agumonkey 1y ago
  I barely used xslt, but as a fp head I wanted to try, the most confusing part to me were terminology / semantics / decoupling. Seemed like matching templates could be anywhere making difficult to understand the meaning of a script.
  - nine_k 1y ago
    It's sort of similar to regular pattern-matching, but sadly not built for ergonomics :(
    - agumonkey 1y ago
      The node pattern matching was ok, but as far as i can recall, there could be multiple matching patterns scattered in lots of places (a 180deg turn compared to most FP pattern matching that aim for exhaustiveness ?)
      - HelloNurse 1y ago
        Exhaustiveness is only relevant for the compiler-managed pattern matching of a traditional FP type system, where you need to write an implementation (patterns that will be used at matching usage sites) for everything that your types promise. XSLT pattern matching is the plain kind: here is a pattern, look for it in the input and process every match. If some part of the input document is ignored, it's just not useful; if some part of the input document is processed several times, it's perfectly well defined.

geocar 1y ago

> but languished where it shined, as a markup language with an amazing transformation capability in XSLT I choose to look at this a little differently. An XML application using XSLT is so much better (faster load times, faster to write, easier to make correct) than a JavaScript application with a JSON api, that XML is basically a secret weapon. I only care enough that it stays in browsers, but otherwise I'd prefer nobody know about it because it means less competition on things that matter (faster load times, faster to write, fewer bugs, etc). And I've got a half-baked JavaScript-based "renderer" I can finish in case some Google VP asshat goes looking for things to delete...

echelon 1y ago

XSLT was cool. XML needs another syntax that isn't so verbose. Sort of like how OWL has XML, Manchester, Functional, and Turtle syntaxes for the same data structures. XSLT needs a Turtle-style syntax. XML in general (the data structure, not the syntax) needs a Turtle-style syntax.

Mikhail_Edoshin 1y ago

XSLT is not bad, but XML, unfortunately, is normally misused, so XSLT is tainted as it has to be a part of that misuse. The true role of XML are grammar-based notations. These occur in two places: when a human gives data to a machine and when a machine produces data for a human. This is where XML is used despite its often mentioned shortcomings; for example, many notations to describe the user interface are based on XML. This is convenient, because user interfaces are created manually. (I am not mentioning text markup, it is well known.) Yet XML was often used as a notation for machine-to-machine exchange. For example, the ONIX book description standard. Here data are moved between two computers, yet for some reason they have to form grammatically correct phrases according to a set of grammar rules. Computers do not need grammar. They do just fine with non-grammatical data, like a set of tables. It is way simpler for them; parsing or generating grammar, even explicit, is pure overhead for data exchange and is only necessary when data enters or leaves the computed pipeline. So, to your examples: configuration in XML is actually fine, but IPC is not. Configuration is written by hand, IPC happens between machines. IPC specification, on the other hand, is also a good fit for XML. That said, XML and thus XSLT has another flaw: it is way too verbose and has no good way to format it. Conciseness was an explicit no-goal but now we can say it was a mistake.

connicpu 1y ago
The XML abuse I've seen at work is truly horrifying. We use protobuf for most of our inter-service IPC, but for one particular team one of their customers demands the use of XML so that it can be run through some XSLT "security" filters, so they have to transform a fairly large protobuf object into XML, run it through said filters, and then convert it back to protobuf :( I weep every time I think about it.
- taeric 1y ago
  It is probably impossible to find a tech stack that has not seen horrible abuse somewhere. :D Granted, it did seem that XML got more heavily abused than some other options for a while. I am curious if that is just a by product of when it was introduced. That or just the general proliferation of how many front end developers we have. (I hate that I am pushing that to almost be a complaint. I certainly don't mean it that way.)

froh 1y ago

here on HN I dare to out myself as a DSSSL lover, the scheme based predecessor of xslt. I still can't wrap my head around how the neat and clean dsssl syntax, a real programming language, was replaced by an xml notation for the same: for cuntional code and a framework. because semantically, that's what xslt is: a functional language with a framework, geared at transforming xml instances. but that syntax... and of course a much inferior and more obscure language than scheme underneath dsssl.

striking 1y ago
Why not implement a DSSSL-to-XSLT compiler?

PaulHoule 1y ago

The thing most people never got about XSLT is that it is really about production rules -- and production rules (e.g. the major path to "expert systems") are one of the most solidly rejected technologies in software engineering. I didn't understand this until I spent a few years going down a rabbit hole asking questions like "why don't people like production rules?" In the case of templating people expect to make a template with a top-down organization that looks like the output, whereas XSLT really wants you build transformations from the bottom-up. On some level the bottom-up part is clear, particularly if you want to code-generate your rules (towards the end I was writing production rules that write production rules) but what is not clear is how the parts all fit together: you can't visually tell between an XSLT that builds the structure you want vs one that doesn't. I think the most fun I ever had with XSLT was when I used an XSLT engine with user-defined procedures and had them create side effects, such as matching certain patterns in an XML document and making SQL inserts, though that was a long time ago when we were still using terrible XML parsing libraries.

stuaxo 1y ago

Its annoying that support stopped at earlier versions, it grew so much more later.