Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Bad programmers use recursion, xslt (Offtopic...)
 --- Stefan Tilkov <info@t...> wrote: > On reflection, that sounds like something I did not > want to say. I > meant that the use of recursion is perfectly fine in > languages that > are designed to support it properly. I think there are both cases where using recursion would generally be a bad idea (cases where there are solutions with lower complexity; such as many toy examples used for teaching recursion), and many others were recursion may be a reasonable choice (like typical tree/graph traversing use cases). In latter category, choice has to do with things already mentioned (if and how efficiently language/runtime can optimize tail recursion; are there some extra penalties for deep call stacks etc), as well as clarity of code. But for former category it doesn't really matter: there's no way to fix an algorithmically bad solution to scale well. Recursion solutions are often cleaner, and I do not claim that all uses of recursion are bad. For tree/graph traversal they are usually good starting points. Regarding xslt, what I have always wondered is whether there are many (enough?) cases where having stateful alternative (with real variables or such to store state) would have benefits: it seems as if computing certain things just once (or cumulatively) could yield significant improvements. For example: instead of computing counts of nodes in a node set consisting of all previous siblings of certain element type, keeping track of number of such elements encountered. Keeping track would require bit more code (or new constructs to simplify it), but would seem likely to perform faster. Supporting state would be against XSL as a language (wouldn't it?), and would also reduce many optimization possibilites (document would have to be traversed and processed in a specific order, no parallel processing of sub-trees etc). But for some transformations it'd be much faster, possibly including lower complexity. On one hand, it is certainly true that higher level abstractions give more optimization. But on the other hand, such optimizations can not compete with better algorithmic solutions: that is, even if computing node sets and their counts is as efficient as it could be, it still wouldn't match performance of low-overhead counters. So would there perhaps be also room for other xml transformation approaches, besides dominant functional alternatives? (but above 'wrap your own SAX-based solution' level) Anyone have links to papers on such alternatives? (the one regarding SAX event reuse was a very interesting one) -+ Tatu +- __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com 
|
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
|
|||||||||
