This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: No side effects holy cow. ( Re: process order (still...) )
----- Original Message -----
From: David Carlisle
>
> Arguing about language design is almost as fruitless as arguing
> whether Microsoft is an agent of the Evil Empire. (But almost as much
> fun:-)
I'm sorry, I had absolutely no idea to argue about language design.
I was trying to find some rationale behind some statements I found
in W3C documents.
1. The press and W3C sells XSLT as an approach to be used not
by scientists ( who like LISP, Prolog and stuff like that ) but
by 'ordinary people'.
Is that right ? I think it is.
2. 'Ordinary developers' are not very happy when I explain to them
that they have no variables, so they need to re-iterate over the tree
with 'count()' function instead of just incrementing the counter.
Is that right ? I know - it is. Do you disagree ?
3. I'm *not* saying functional programming ( or some-word-here
programming ) is good or bad.
functional programming has it's own problem domain for years
and we can easy see the percent of people who are using finctional
programming paradigms.
Are you saying 'ordinary persons are not happy with variables', that's
why W3C gives them breath of 'good' programming? We know that
they missed that paradigm for long years of LISP and Prolog ignorance ?
4. It may be a sad story that this world is not ideal and people
are still using that stupid-obsolete-whatever concept of persistency
( side-effect ) almost everywhere.
5. I understand that from scientific point of view this is not a big
deal to re-open the connection to the database every time before
executing the query ( no connection pooling - because connection
pooling is side effect. PLEASE, don't get me wrong, explaining
possible workarounds. My point is to illustrate that
probably the concept of persistency ( side effect ) is not that bad
if the *entire* ( current ) IT world has been build with that concept. ).
Unfortunately - XSLT will have to live in the real world. The ugly and
strange world where people ( for some reason ) care about
performace *so* much that Sun is spending millions to fix Java
efficiency by only 20% ( HotSpot numbers reported by Sun ).
That means people *will* use extension functions and
extensions functions *will* have 'side-effects'.
This will result in *real* nightmare when changing the XSLT
frameworks ( lack of unified extension bindings is not a big deal
comparing to such a problem ).
Avoiding use of extensions is simply impossible ( of course,
if we are talking not about using XSLT for typical rendering
of some relatively small document - XSL can do that as-is,
without extensions ).
I bet that there will be many extensions breaking no-side-effect
rule. That'l be not because people who are writing those
evil extensions are stupid.
That's because currently there is no way to go without XSLT
for XML transformations. ( See below ).
> It's not as if its the end of the world if you don't like this style and
> need to transform some documents, there's omnimark, or perl's xml
> modules, or any one of dozens of alternatives.
It is not, of course. Unfortunately in this world where
every kid knows what stock to sell every manager stops
listening you if you are saying something *other* than :
"we have XML - so we should process it with XSL".
Of course it is not *that* crazy yet, but when I'm saying
"perl or omnimark" and another consulter says : "XSL
is a standard for XML transformations" ( with some URL's
and articles at hand ) - I'm placing myself into trouble.
Why should I ?
The only way to protect myself from such a situations
is to collect some URLs to the letters like this, so probably
I'm writing this letter to defend some poor perl developer ;-)
Not that bad, but URL to some publication could help
better... ;-) Unfortunately I hardly remember any publication
loudly explaning what could be a weakness or XSLT.
( Because XSLT is realy a good thing, BTW ;-)
Rgds.Paul.
PS. I wish I make it clear and I don't think I want to participate
in a discussion of different paradigms. There are some limitations
( holy limitations ) which cause some particular problems when
trying to utilize XSLT and I think the benefits from those
limitations are mythical. That was my point and it has nothing
to do with the beauty of functional programming, I think.
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list