Cart
[Home] [By Thread] [By Date] [Recent Entries]
----- Original Message ----- From: "Uche Ogbuji" <uche.ogbuji@f...> > XSLT is a phenomenally well-designed language. > I'm sure I'll hear some gasps from some folks here, but gasp away. If by XSLT you mean a subset of XSLT which is : 1. apply-templates 2. copy-of 3. value-of 4. for-each 5. if ( with no else! gasp) 6. XPath with a few axes Then yes. Some part of XSLT is well-designed. The nice combination of push-pull, suitable for a simple 'hierarchy - hierarchy' or 'hierarchy - flat' transfromations. For flat - hierarchy transfromations XSLT just plain [expletive deleted]. I think that's a common knowledge. > First of all to the superficial indications: XSLT has perhaps the most phenomenal adoption rate of all programming languages of all time. It's always hard to measure this sort of thing from users, so I measure it by actively-developed implementations. Neither C, C++, Java, or even my favorite Python have had anything like the growth of vibrant culture in XSLT development. People like XSLT because it gets its task done very well, and so vendors are anxious to provide XSLT support to users. Perl has just one implementation, so it [expletive deleted]? > This is especially important given one of XML's touted strengths: extensibility. > And speaking of extensibility, the well-considered features for extending XSLT are another key part of its success. The flourishing of projects such as EXSLT so soon after the advent of XSLT 1.0 is quite telling. Telling what? By this metrics - Perl is a clean winner over *any* language, because CPAN is *huge* So by one of your metrics Perl [expletive deleted], but by another metrics it is the winner. I think there should be something wrong with the metrics, that you use. > Even in features suppressed, I think the WG was mostly on the money. The lack of updateable variables enforces a pipe-based approach to processing that is far less error-prone and encourages functional decomposition. The lack of type "safety" is also very important (one of the reasons that I dread the advent of XSLT 2.0). Agree. Pipe-based approach is 'good'. However, somehow, most of computer users ( including developers ) have serious problems, writing UNIX pipes. I'd say that the majority of computer users prefers GUI / OO / event-driven world to pipes-based world. Some people belive that this is the issue of 'education'. I don't think so. Time will tell. The interesting thing is that creators of UNIX have *changed* the pipes in Plan 9 to make them ... bi-directional ! The creators of 'side-effect-free' processing decided that it is 'too limiting' and 'it should be fixed'. I was *really* surprised to hear that ... in private correspondence with one of UNIX gods ... I think the world is funny. Isn't it ? > Anyway, as an XSLT implementor and developer, I have often had cause to curse the XSL WG (decimal-format/format-number, and the lack of dynamic programming features being leading causes), but I'm mostly vehement because of how good the product is overall. Good for *what*. Of course it is good! For some subset of the transformations, with 'no states', no 'flat -hierarchy', no 'loose markup' e t.c. e t.c e t.c. The push-pull combination + XPath ( embryonic regular expressions for trees ) + one-step transformation? XSLT *is* good. This is just not enough for way *too* many real-life cases. What is your point? That the guy who've written the original article does not yet understands what are the real problems with XSLT, so he makes some mistakes? He sure does. At least, he presented the particular case and compared XSLT to some other languages. That was a nice article, I think. Rgds.Paul.
|
