3 ms·

Yep, everyone hates XML and then gets excited over "microformats" or "components" :) These hundreds of languages have no pattern matching but all have mutable

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
  How could you miss components, the new web revolution? :) Here it is being presented by Google: https://www.youtube.com/watch?v=2toYLLcoY14 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.)

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
How could you miss components, the new web revolution? :) Here it is being presented by Google: https://www.youtube.com/watch?v=2toYLLcoY14 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.)