[
Lists Home |
Date Index |
Thread Index
]
----- Original Message -----
From: "Uche Ogbuji" <uche.ogbuji@fourthought.com>
> 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 sucks.
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 sucks?
> 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 sucks, 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.
|
