[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: No side effects holy cow. ( Re: process order (still...)

Subject: Re: No side effects holy cow. ( Re: process order (still...) )
From: Paul Tchistopolskii <paul@xxxxxxx>
Date: Thu, 13 Apr 2000 20:01:45 -0700
no side effect
----- 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


Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.