Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

XSLT is a failure wrapped in pain

harmful.cat-v.org

Post reply on HN
Print view View original

41–50 of 157 posts

Re: XSLT is a failure wrapped in pain

#41

Post by sqrt17 »

VMG wrote: post #30
duncanawoods wrote: post #20

I believe the fundamental pain of xslt was... that it was an FP language. When teaching XSLT, the difference between those who said "its elegant" vs. those who said "its pain" - is whether the individual could grok FP. Angle bracket overload, verbosity of end tags, library support, poor whitespace handling, namespace pain were all obstacles too but it was FP that made standard problems feel like math proofs and for d…

> I believe the fundamental pain of xslt was... that it was an FP language. From the post I linked in my other comment > Oh, and the fact that you can call a language functional when it lacks first class functions makes my eye twitch. I'm tempted to upload a video of my eye twitching just to prove it.

That seems like the difference between object-based (early VB) and object-oriented.

XSLT is referentially transparent (no setf for you) but withholds from you most of the goodies that people take for granted in functional or logic programming.

You could see it was written by well-intentioned FP enthusiasts. IMO the best alternative at the time when XSLT was developed would have been XMLPerl - embedding an imperative language in something that deals with the XML-specific parts appropriately. But Perl was never enterprisey enough, and XmlPerl died a painless death.

Re: XSLT is a failure wrapped in pain

#42

Post by robert_tweed »

One quote sums it up:

“XML is simply lisp done wrong.” – Alan Cox

It's not that XSLT isn't useful in some situations. It is. It's not that clean, simple and efficient XSLT is impossible. It is, but it's hard.

The fact that it isn't Turing complete can be a good thing. It can also cause a lot of headaches.

The main problem is that XSLT as designed and as implemented is an over-engineered god-awful mess. XSLT 2 was a huge improvement, but nobody implemented it, or they maybe only implemented bits of it in nonstandard ways (MSXML), so none of the better parts were reliable.

The idea of XSLT was sound and XPATH was pretty nice, but anyone who thinks XSLT is "good" probably has never worked on a large XSLT-based project (one where XSLT files routinely include other XSLT files and XML documents routinely link to other XML documents via xlink).

People say complexity gets out of control with OOP. Those issues pale into insignificance compared with rampant pattern matching split over many files when you have dozens of different schemas and are dealing with massive document graphs (with the occasional cyclic edge for good measure).

Good luck trying to reliably predict results in advance, or add any sort of control-flow logic to deal with edge cases without resorting to hard-coding and unrolling recursion.

Re: XSLT is a failure wrapped in pain

#43

Post by bambax »

crdoconnor wrote: post #24
bambax wrote: post #18

Earlier quoted context omitted.

You're right, it's 230 lines; I updated my post accordingly. I wrote the thing 3 years ago and remembered the number of rules (templates) instead of the number of actual lines. But a line's a line, so I was wrong. "written in a better language" doesn't mean much, however. A better language for what? I'm not picking on JavaScript, which I love and use every day; but templating in JS versus XSLT is crazy. The templatin…

>"written in a better language" doesn't mean much, however. A better language for what? For general purpose programming, which is what transformations eventually end up requiring. XSLT isn't java or javascript. It theoretically can do everything that those two can do, but we both know in practice that once you don anything sufficiently complex in XSLT it will become horrendous. Even the biggest proponents of XSLT won…

> the same pain you felt debugging it

XSLT is "right the first time"; I have had to do corrections and evolutions but very rarely (never?) have I had to hunt for a weird unexplained behavior.

Of course I have seen horrible XSLTs, but horrible is in no way limited to XSLT (the only thing that's XSLT-specific is when people try to do imperative programming in XSLT).

I'm currently trying to make sense of a database model where every. single. property. is a flag in just one table (isClient, isProspect, isActive, isAForeigner, isMale, isFemale, etc. etc.)

No XSLT involved whatsoever. Big pain.

Re: XSLT is a failure wrapped in pain

#45

Post by ilitirit »

boomlinde wrote: post #19
patrickg wrote: post #12

Earlier quoted context omitted.

apples and oranges? There is no other way of encoding structured documents these days than XML. Like it or not, XML is the de facto standard for data exchange (export from databases, product information software,....) XML might be overengeneered (which, except for a few things I don't agree with), but there is currently no alternative for it.

The site in question lists several alternatives, some of which are widely in use especially in cases where XML falls short: brevity, fast to parse, easily readable... Most of all, calling it the de facto standard is either dishonest or clueless.

> Most of all, calling it the de facto standard is either dishonest or clueless

It is in fact the de facto standard in the publishing industry. The "other" format is of course PDF.

Maybe all of this will change when we have more technologies that support formats that can handle mixed content as easily as XML.

Re: XSLT is a failure wrapped in pain

#47

Post by ilitirit »

moonshinefe wrote: post #38
geonik wrote: post #36

Those who rant about XML and XSLT know nothing about what they talk about. 50% of our server's behavior (200,000 Java LOCs) is orchestrated declaratively by a small number of XML files that use around 30 custom namespaces. These are 1. parsed on server startup for setting up persistence, business rules, REST endpoints etc 2. transformed by XSLT to a) produce nice HTML documentation, including DOT class diagrams b) ge…

I'm afraid your argument of "It worked for us" and "it only uses a small number of files with 30 custom namespaces" pretty much is the most unconvincing argument I've ever heard. In fact, the latter point is one of the reasons most people like to avoid XML.

Yeah XML namespaces are a pain to work with, but when it comes to stuff like documentation it's hard to beat XML.

Mixed content in Json is definitely not as simple as it is in XML.

Re: XSLT is a failure wrapped in pain

#49

Post by crdoconnor »

ohyesyodo wrote: post #46

Okay, so what am I supposed to use if I want to transform a XML file from one format to another because two different systems needs XML for input /output and they have different fixed formats?

I would use a language that has a decent XML parser (e.g. python + lxml) for input and a decent templating language (e.g. jinja2) for output.

Assuming it was a simple transformation, the python parsing code could be under 10 lines. Most of what you wrote would be templating. It would be 98% declarative.

If it got complicated though (e.g. you're doing some aggregation or something), the python bit would grow but it probably never end up looking that horrendous, unlike XSLT.

The same pattern could be applied to many other language ecosystems. You just need to make sure you get the best XML parsing library and the best templating language.

Re: XSLT is a failure wrapped in pain

#50

Post by arethuza »

VMG wrote: post #31
raverbashing wrote: post #21

Earlier quoted context omitted.

REALLY? http://en.wikipedia.org/wiki/XSLT#Example_1_.28transforming_...

I want to enter this piece of evidence into the trial: Comma separated string parsing XSLT: http://stackoverflow.com/a/2850181/92493

If you are using XSLT to work on anything other than XML you are doing very strange things.
Post reply on HN