[
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?
Why do you try to bait me into this conclusion? First of all, I said that XSLT's depth of implementatioin is evidence of its goodness. I neither said nor implied that lack of same is evidence that something "sucks". I even contrived a comparison in which Python came out the worse, which, since you and I have had ample discussion in the past, should be ample evidence of my meaning ;-)
BTW, I am surprised if Perl really has only one implementation, and it does make me wonder about it. Python, for instance, has likely 20 or more. Of course, if the "Parrot" initiative to share common run-time between Perl, Python, etc. comes to life, I guess Perl might have as many implementations. (And, yes, for those who missed it, Parrot *started* as an April Fool's joke, but has turned into a very interesting collaboration between the top Python and Perl developers, with some PHP folk pitching in. Seems Eric S. Raymond played mediator to get things rolling.)
> > 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*
And Perl is much older than XSLT. I did make qualification by age, if you noticed.
> 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.
Nah. Something's just wrong with your reasoning about my "metrics". You did manage to beat that straw man to a bloody pulp, though.
> > 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.
I think we'd all be better off if there were far fewer and far better programmers. Call me a snot, but IMHO A programmer who cannot understand the basic divide-and-conquer algorithmic imperatives that are the foundation of computer science, and that are properly enforced by functional programming, should be quarantined from *any* computer language.
> 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'.
Yeah. And they also decided that the good old process, which God intended as the fundamental unit of CPU scheduling, be primped up with the addition of "lightweight" processes (AKA threads).
As Tony Soprano might say, "Whaddaya gonna do?"
And OBTW, who says UNIX pioneers are the "creators" of side-effect-free processing?
> I was *really* surprised to hear that ... in private
> correspondence with one of UNIX gods ... I think the
> world is funny. Isn't it ?
O yeah. BTW, how often do *you* use bi-directional pipes?
> > 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*.
For my purposes, which mostly involve developing forms-based apps and document-based process dispatch systems.
I have a pretty diverse background in programming languages and systems and I am often surprised at how rapidly and effectively I can develop Web-based systems using XSLT.
--
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
|
