[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...)
----- 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
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|