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

Re: Re: Keeping a running total?

Subject: Re: Re: Keeping a running total?
From: "Tracey Zellmann" <tracey.zellmann@xxxxxxxxxxx>
Date: Thu, 13 Jul 2006 17:04:30 -0400
tracey adams
Myself - I am still struggling to decipher why this is so important and so difficult for me.

For the declarative case, where is the Dijkstra paper, and is there a spaghetti code analogy?
Those made a lot of sense to me.

(Dijkstra wrote a seminal paper in 1968 "Go To Statement Considered Harmful" which also proved that it was not necessary.)

I feel the situation is very similar to the introduction of goto-less
programming in the 1970s. COBOL and Fortran programmers found it very hard
at first to see how they could write code without a GOTO statement.
Eventually they were forced to learn, and they became better programmers as
a result. It does mean there is a steeper learning curve, but at the top of
it there are broad sunlit uplands!

I think the right solution architecturally is to use a procedural pipeline
processing language which defines the overall control flow of an
application, and which invokes purely functional queries and transformations
written in XSLT or XQuery. For problems like the one in this post, I think
recursive solutions are quite adequate: it takes a while to get the hang of
them, but they're not difficult once the idea is mastered.

Michael Kay

Current Thread


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.
First Name
Last Name
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.