5 ms·

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 e

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.

sbennettmcleish 12y ago
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.
- jimfuller2014 12y ago
  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
crdoconnor 12y ago
>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).
- Mikhail_Edoshin 12y ago
  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?
  - crdoconnor 12y ago
    >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.
    - Mikhail_Edoshin 12y ago

sbennettmcleish 12y ago

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.

jimfuller2014 12y ago
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

crdoconnor 12y ago

>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).

Mikhail_Edoshin 12y ago
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?
- crdoconnor 12y ago
  >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.
  - Mikhail_Edoshin 12y ago