Earlier quoted context omitted.
My definition of powerful and elegant is lisp XML is just death by overengineering
> My definition of powerful and elegant is lisp Dude, XML is just s-exprs and XSLT is macros.
XSLT is a failure wrapped in pain
21–30 of 157 posts
Re: XSLT is a failure wrapped in pain
#22The point with namespaces leads me to think that the main problem with XML is that on the surface it looks very simple but in fact it's not. It is tempting to take shortcuts to process the XML: for example parsing with regexes, looking at the namespace prefix and not at its definition, producing XML without proper escaping. There are also some gotchas like certain characters being non-representable in XML.
I personally like XML and XSLT (2.0) but to be able to work efficiently you need to spend some time learning which is not obvious on the first sight.
What about the alternatives?
JSON has a big advantage which is its unambiguous automapping to objects. This benefit is not that apparent in languages like Java where you'd still declare a class to represent either the XML or the JSON document. Moreover, there are projects which essentially try to bring schema and namespaces to JSON. JSON-LD is an example of a namespace without an explicit support in the underlying format. There is even a command-line tool jq big part of which is an engine similar to XPath.
S-expressions if used widely would probably go the same path as JSON - recreating a lot of what is considered as bloat in XML.
Another mentioned alternative was a custom text format. I assume the author meant just to design a format from scratch. I wrote that to use XML efficiently, you need to put in some work. But compared to making a backwards (and forwards?) compatible text format which correctly handles malformed and malicious input requires much more effort.
I don't know anything about ndb.
Re: XSLT is a failure wrapped in pain
#23Earlier quoted context omitted.
http://markitdown.medusis.com/xsl/html2mk.xsl It looks like 234 lines of code to me. >This attempt for example https://github.com/domchristie/to-markdown/blob/master/src/t... . Is badly written, but still written in a better language. They're using regexps to parse HTML (omfg!), but that kind of nastiness doesn't excuse XSLT as a language. >There is no better templating language than XSLT Except mako, jinja2, django…
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…
>What I don't understand is why so many people go out of their way to declare their hate of XSLT (and all things XML), especially now that XSLT is all but dead...?
Seriously? It's because we're shocked to find people like you defending it. Incredulously wondering if you've been paying attention to literally any other piece of technology other than XSLT in the meantime.
:(, but, for you.
>and they only work server-side.
I choked on laughter, maybe you can help me take this one seriously, given XSLT and when it was actually even in consideration for being used server-side.
Re: XSLT is a failure wrapped in pain
#24Earlier quoted context omitted.
http://markitdown.medusis.com/xsl/html2mk.xsl It looks like 234 lines of code to me. >This attempt for example https://github.com/domchristie/to-markdown/blob/master/src/t... . Is badly written, but still written in a better language. They're using regexps to parse HTML (omfg!), but that kind of nastiness doesn't excuse XSLT as a language. >There is no better templating language than XSLT Except mako, jinja2, django…
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't argue that you should put business logic in there (I hope, anyway).
>I'm not picking on JavaScript, which I love and use every day; but templating in JS versus XSLT is crazy.
Because?
>The templating languages that you mention are, in my opinion, extremely complex and very unpalatable
What??!? I can get web designers with no coding experience to edit them! Try doing that with xslt. They're that simple! Not only are they conceptually simpler, they are mathematically provably simpler due to their being non-turing complete.
>and they only work server-side.
Am not a client side developer so I don't know what the state of the art is in client side templating languages, but there are a few that look ok (dust, jsrender, handlebars...).
>But that's all a matter of taste, I guess. What I don't understand is why so many people go out of their way to declare their hate of XSLT
Because they have spent time debugging it and know that every second they spent doing that was both painful and unnecessary.
If you don't understand the pain it might mean that you don't even realize that the same pain you felt debugging it wasn't actually necessary.
My sincere hope is that all the people who create business critical XSLT abortions will stop doing it so I won't ever be called in again to fix what they did. That's why I'm passionate in my XSLT (and XML) hate.
Re: XSLT is a failure wrapped in pain
#25I 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…
The FP bit was fine. It's wrapping the functional program in the most obtuse syntax known to man (apart from C++ template syntax which at least has the get-out clause that it was never meant to be a turing complete programming language that programmers took seriously and used to get real work done) that's the problem.
Full disclosure: My last exposure to XSLT was a long, long time ago and I've been carefully avoiding it ever since.
Re: XSLT is a failure wrapped in pain
#26Earlier 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.
I am working for many years in the publishing business (dealing with structured documents, product data etc.). I can tell you, that all of my customers are more open XML than any other document formats (there exist none as suitable for the job).
You can call me clueless or dishonest, I don't care. I can only share my experience with the topic. You don't have to believe me.
Re: XSLT is a failure wrapped in pain
#27The problem with XSLT, XML, SOAP, WS-* is that the community is driven by vendors with deep pockets who use their power to kill interoperability. Imagine LISP, but in the hands of Sauron or Palpatine. That's the XML group of technology.
> Imagine LISP, but in the hands of Sauron or Palpatine.
Common Lisp?
Re: XSLT is a failure wrapped in pain
#28XSLT is one of the most powerful and elegant technologies created in the last 15 years. Those who don't understand it and that's why can't use it, should just do their home work and learn better
The problem is that it's often misused. Using an XSLT that takes 0.5s to run to transform some XML to HTML during web requests on a busy site? Idiotic. Using it for async transformations - html to pdf, customer message format to your message format. Fine.
Using compiled XSLT-translets in Java (XSLTC) has a huge impact on performance, with transformations taking 0.5s the problem seems to be in the way your XSLT is written and pushing or pulling the data, not XSLT itself:
http://xalan.apache.org/old/xalan-j/xsltc_usage.html
Re: XSLT is a failure wrapped in pain
#29I 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. When teaching XSLT, the difference between those who said "its elegant" vs. those who said "its pain" - is whether the individual could grok FP.
I've heard this before, but I don't find it to be true for me anyway. XSLT has never really clicked for me, while I really like Clojure and OCaml. Maybe the FP is part of the problem, but I also think XSLT is just a particularly obtuse functional language. XSLT makes it hard to figure out how to express even moderately complex algorithms (e.g. a map-reduce function is literally just that in Scheme, while I'm not sure I could write one correctly without several tries in XSLT) — and once you do express them, they're buried under an impenetrable mound of XML boilerplate that makes them hard to maintain or understand later.
Re: XSLT is a failure wrapped in pain
#30I 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.