[
Lists Home |
Date Index |
Thread Index
]
> Dare sends
>
> "the following article by Tom Moertl is a succint summary of the
> issues with XSLT that I've heard developers voice and that I've had myself"
>
> http://www.kuro5hin.org/story/2002/1/13/223854/606
>
> which summarizes:
>
> "If there is a lesson to be learned, it's that domain-specific language design is hard. The XSLT designers created a language that lacked much of the nuts-and-bolts functionality necessary to make it genuinely suited for its intended purpose. While the designers doubtless left this functionality out of the spec on the grounds that XSLT isn't intended to be a general-purpose programming language, they failed to realize that even simple document transformations often require a little nuts-and-bolts programming. Leaving out the nuts and bolts made XSLT a broken language.
>
> Lesson: Next time, don't forget the nuts and bolts."
This is a "broken" conclusion, and I don't have time yet to read it, but I would guess therefrom that it is a "broken" article.
XSLT is a phenomenally well-designed language. I'm sure I'll hear some gasps from some folks here, but gasp away.
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.
But more importantly, the fundamental merits. XSLT has succeeded in large part because of its modesty. It won a small victory (enabling tree-to-tree XSLT transforms) very convincongly in part because it deferred on some of the "nuts and bolts".
The general purpose facilities that it *did* provide were weighted with surprising cleverness for expressive power with minimal semantic footprint. For example, template dispatch is more general than popular opinion allows, and is a smart use of declarative processing. I know that I've seen a lot of declarative school developers roll their eyes when I teach/advocate template-based approaches. They tend to carp for the good old set up string variable, add to variable in loop, and print string result. However, my unscientific analysis is that developers quickly become much more productive, and write far more maintainable code once they learn the idiom.
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.
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).
<rant>
Regardless of what the learned Jonathan Robie and cohort say, I have no confidence that the sorts of rigid type systems OO and SQL DBMS folks trumpet have *anything* to do with reducing programmer errors. "integer", "string", "float" is a criminal nonsense. Programs don't fail because someone passes a float when a string is expected. They fail because someone passes a non-prime number when a prime is expected, because of some boundary condition in the declarative code that coverage testing missed.
This is one area where Fabian Pascal gets it right (as far as I follow him): in current computer processing, the only constraint system that works is a declarative one based on an idiom with full expressive power over the problem space. Bertrand Meyer made a rightful step in this direction in the design of Eiffel. Many of us who watched C++ become wertchedly unusable in large part because of all the typing magic ANSI had to add to the language to keep it somewhat consistent wish that Stroustroup had been watching Meyer more closely. I fear that XQuery, XPath/XSLT 2.0 and the like will do the same damage to the most important XML processing tools.
</rant>
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.
--
Uche Ogbuji Principal Consultant
uche.ogbuji@fourthought.com +1 303 583 9900 x 101
Fourthought, Inc. http://Fourthought.com
4735 East Walnut St, Boulder, CO 80301-2537, USA
XML strategy, XML tools (http://4Suite.org), knowledge management
|
