Hacker News Reader

Comment by intrasight | Hacker News Reader

First, I don't understand what's with the complaints about the syntax. It's just a flavor of XML. If you work with XML all day, then XSLT looks just fine. But even if you don't like the syntax, so what - there aren't any alternatives to XSLT.

Those of you that know and love XSLT will understand when I say I wish I could be cast into an alternative universe where XSLT continued to be mainstream.

I'll continue to leverage this power-tool (and get paid handsomely by by clients for wielding such power) for the rest of my career.

View on HN

>First, I don't understand what's with the complaints about the syntax. It's just a flavor of XML.

People who hate XSLT are not usually fans of XML either.

>But even if you don't like the syntax, so what - there aren't any alternatives to XSLT.

There are hundreds. Simply use any normal programming language (javascript, python, perl, ruby, etc.) with a templating language (handlebars, jinja2, etc.).

The results will be much cleaner, easier to debug, and will remain cleaner as your transformations get ever more complex (code has a habit of doing that).

Yep, everyone hates XML and then gets excited over "microformats" or "components" :)

These hundreds of languages have no pattern matching but all have mutable state; XSLT is declarative and this removes a ton of complexity. If you had a bunch of related tables would you process them as Python dicts and arrays or rather load them in an RDBMS and write SQL instead? Especially as the transformations get more complex?

>Yep, everyone hates XML and then gets excited over "microformats" or "components" :)

The 'exciting' thing about microformats was that it got you slightly higher positioning in SERPs. I don't know if that's true any longer. That was hardly a benefit of the language design.

I've never heard of components.

>These hundreds of languages have no pattern matching but all have mutable state

There are hundreds of bad languages. I wouldn't defend any of them. Most widely used languages have some form of decent pattern matching, though.

Mutable state can cause headaches, but if you want to use a functional language to help solve that - these days you're spoilt for choice. Most modern languages can be written in a functional style also, if that's your thing.

>XSLT is declarative and this removes a ton of complexity.

The OP made this claim by comparing it favorably to a javascript program that parsed HTML using regular expressions. Which makes me wonder (and shudder about) just what you and the rest of the XSLT defenders are actually comparing it to. And also why you seemingly haven't seen or used any good parsers or templating languages.

>If you had a bunch of related tables would you process them as Python dicts and arrays or rather load them in an RDBMS and write SQL instead

That would depend entirely upon what I was doing and why. I have done both in different contexts because they had different trade offs.

>Especially as the transformations get more complex?

SQL is capable of handling a great deal of complexity (more than xslt certainly), and its declarative nature certainly nets you a lot of things for free (less code, faster queries, no deserialization/serialization overhead), but it still has its limits. Yes, for really complex transformations I would probably write them in python and not SQL.

How could you miss components, the new web revolution? :) Here it is being presented by Google:

https://www.youtube.com/watch?v=2toYLLcoY14

It's basically custom HTML tags like:

  <tabs>
    <tab>Alpha</tab>
    <tab>Bravo</tab>
    <tab>Charlie</tab>
  </tab>

and some JavaScript library ("a new type of library for the Web") that processes these custom tags to display tabs on a web page.

I'm talking about pattern matching for templating rules; e.g. I want to handle a "value" token differently depending on whether the parent is a "field" or a "value-list" With XSLT I do this with a pattern: "field/value" vs "value-list/value". It's very clear and very efficient behind the scenes (about as speedy as a regex). I'm not sure I can do it in Python as easily.

As for parsers: parsers are a good thing, certainly, but look at what they do: they take an unstructured sequence of symbols and try to recover the hidden structure of it using a set of grammar rules. The end result is a tree that still contains the original sequence but dissects it into a hierarchy of discovered non-terminals.

Doesn't this look familiar? It's an XML document. XML documents are basically preparsed sequences or serialized parse trees. Maybe they have been parsed already by a specialized parser; or maybe the structure was added there manually when we marked up a text in a natural language; or maybe the sequence was generated by a machine in the first place and we just retained the original structure. What XML does is that it saves the result so there's no need to parse the same sequence again.

(Well, there is; we still need to deserialize the XML document and to interpret certain sequences as strings and another as numbers or dates and this is also parsing; but the serialization notation is much simpler than the grammars that were involved to parse or build the original tree.)

This is why parsing HTML is a waste of time regardless of whether we do this with regular expressions, recursive descent, Earley, LALR, Tomita, PEG, or whatever parsing technology we like :) It has been parsed already; we only need to deserialize it, and this is a trivial task that has been solved long time ago. (Well, maybe not with HTML, because somehow it's important to accept broken HTML and this may require a full-fledged parser and then some.)

Agree 100%. I've been using XSLT very extensively in my current role for at least two years now and I love it!

However, I can say with certainty that I'm the only one within my team that shares this view.

Using it for transformation of XML to HTML, semantic validation (does my XML contain A and B when C='Individual'?) and mapping from one XML flavour to something JAXB friendly. Implementing much of this stuff in Java or other would be a nightmare and/or unproductive process with a LOT more code required.

yes, its a typical scenario ... XSLT is one of those languages where people either love it or hate it ... I think its to do with the fact that it takes a bit longer to become productive or useful in XSLT, most developers are expected to just immediately start writing code that 'does stuff' these days.

Anyhow, I see most of developers pain with XSLT is because they never learned the basics of the language and thrash about ... perhaps thats the biggest fault of the language, in that its difficult to tell its story with an analogy to where people start from. Anyhow, learning any fp language tends to improve a developer as a programmer

Reply on news.ycombinator.com